Database design SimpleStats项目的数据库模式

背景：

我有一个cvs文件的文件层次结构，用于多个位置，这些位置的名称是按日期命名的，具体来说是按月份命名的。文件夹中的每个cvs文件都以位置命名

例如‘’， 文件夹名称：2010年2月

包含： 位置1.csv 位置2.csv

每个CSV文件都保存以下记录：

2010-06-28, 20:30:00 , 0
2010-06-29, 08:30:00 , 0
2010-06-29, 09:30:00 , 0
2010-06-29, 10:30:00 , 0
2010-06-29, 11:30:00 , 0

记录列和列名的含义：

Date, time, # of sessions

我有一个perl脚本，可以从混乱中提取数据，最初我打算将其存储为json文件，但我认为从长远来看，数据库可能更合适……比较每年的趋势……像这样有趣的东西

第2部分-我的问题：

所以我现在有了一个REST服务，它通过一个测试数据库输出json。我的问题是[我在数据库设计方面很差劲]，如何最好地为此设计一个数据库后端

我认为下面的表格就足够了，并且保持简单：

Location: (PK)location_code, name 
session: (PK)id, (FK)location_code, month, hour, num_sessions

我需要能够在给定的一个月或几个月内，除了一周中的几天之外，在一周中的几天内平均每小时的会话数加上最小值和最大值。我一直在使用perl哈希来实现这一点，并试图决定如何最好地用数据库实现这一点

您认为应该使用存储过程吗

至于数据库，根据这里收集的信息，它将是postgresql或sqlite。 如果没有令人信服的理由支持postgresql，我将坚持使用sqlite

如何以及在何处将数据与运行小时数进行比较。我在储存时间 在yaml文件中的操作。我目前将数据中的小时与yaml中的哈希进行“匹配”，以完成此操作。数据库会打开更简单的方法吗？我想我会像现在一样进行比较，然后插入数据。可通过以下方式召回：

SELECT hour, num_sessions FROM session WHERE location_code=LOC1

由于目前只有几个小时的手术时间，我不必担心。 我是否应该像现在一样计算所有结果，然后将其存储为一个统计表 不同的‘报告’？这，而不是按需处理？这看起来怎么样

不管怎样，我在闲逛

谢谢你的阅读

---

Bubnoff

从我对SQLite的了解来看，它提供了进行分析所需的函数，如sum、avg等，看起来您将在自己的api级别上进行分析，而不是允许最终用户通过接口自己进行分析。因此，对于您拥有的简单设计+小数据集，我将考虑将所有数据导入SQLite。我还将它放在SQLite可以理解的本机格式中，这样您就可以使用它的SQL函数，而无需首先转换任何内容，也无需创建特殊的函数来在SQL中进行转换

除此之外，除了月份和小时字段外，您的设计对我来说很好。我会将它们保留为完整的日期和时间字段，或者如果有合适的SQLite数据类型，可以将它们合并为一个日期和时间字段，并将完整的日期/时间数据放在其中，以备以后需要。然后使用SQLite时间函数从完整的日期/时间字段中酌情提取月份和小时。为了方便起见，如果SQLite支持，您可以在会话表中创建月份和小时的计算字段，这将允许您立即从查询中返回要查找的数据，而不是在每个需要一个月或小时的查询中显式调用时间提取函数

---

另外，不要忘记在查询中设置条件的字段上放置索引。您可能没有注意到小数据集之间的差异，但随着数据库变得更大，它们可能会产生巨大的差异。

由于数据库无知/幼稚，我可能会产生误解。我决定将时间和月份分开，因为不管是哪个月，都需要平均每个小时的会话。我还需要平均他们在一个月内，也具体天或至少考虑到可能性。通过像这样分离时间-日期，我认为这比稍后解析出来然后处理要容易。我需要做更多的研究来得到你所描述的——计算字段。在数据库方面，我是一个认真的noob。我将不得不考虑如何使用它，而不是将其解析出来并单独存储。那么我的预设统计表的想法呢？计算字段将允许您从已有的完整日期和时间数据中分割出月份和小时，同时允许您在以后需要时保留该数据。如果你确定你不想要/不需要完整的日期和时间，那么你当然可以坚持你现有的设计。我个人的观点是，对我来说，在以后重新移植原始数据通常比计划每周/每月使用脚本将其带过来，让计算字段为我自动拆分数据要多。计算字段是定义公式的字段，当查询从表中请求该字段时，DB将运行该公式。例如，您可以将您的全职数据放入它自己的名为time的字段中，并创建一个

---

定义为公式strftime“%H”，[time]的名为hour的计算字段。现在，SELECT HOURE FROM session将自动为您运行该公式，并为您提供返回的每一行的小时数。一个月的计算量是一样的。我不会考虑用预制统计表，直到性能无法接受地缓慢计算结果。大多数常规报告工具对原始数据的处理都非常出色。此外，如果你制作了一个预加工统计表，你很可能很难将这些数据连接到标准的报告工具中，因为它们通常希望根据原始数据进行计算。如果您有Microsoft Access或Excel，请深入了解它们的数据透视表功能，因为它们可以在ODBC连接上进行很多类型的分析，我相信SQLite为ODBC连接提供了驱动程序。