日志数据评估的数据库设计

时间:2014-09-19 18:02:18

标签: sql database-design relational-database

我的任务是开发一个评估日志文件的工具,我正在寻找合适的数据库设计。有几十个应用程序以CSV格式生成日志文件,但每个应用程序都有不同的列和数据类型。在启动时,每个应用程序都会将其当前日志文件发送到服务器,该服务器将新行插入SQL Server数据库。

到目前为止,我想出了以下设计。从我在其他帖子中看到的内容来看,强烈建议不要使用EAV设计,这并不能说服我必须将所有数据存储为字符串。因此,我提出的唯一选择是每个应用程序有一个表。

还有其他我尚未考虑的选择吗?如果您遇到类似的情况,您选择哪种设计?

1。)每个应用程序一个表

ApplicationA(A, B, C, D, E)
ApplicationB(B, E, H, J)
ApplicationC(C, P, N, X, Y)

优点:

  • 简单设计

缺点:

  • 很多桌子
  • 每当引入新项目时,都必须创建相应的表
  • 如果文件格式发生变化,则必须更改表定义

2.。)EAV模型

Applications(AppId, Name)
DataTypes(DTypeId, Name)
Properties(PropId, Name, DTypeId)
ApplicationProperties(AppId, PropId)
Values(ValueId, AppId, PropId, Value)

优点:

  • 无需添加新表或列

缺点:

  • 所有值都存储为字符串
  • 由于大量的连接和强制转换,SQL查询更加复杂

1 个答案:

答案 0 :(得分:0)

在我看来,性感并不总是更好。每个应用程序设计的简单1表格为简单起见。添加表的维护应该不是什么大问题。没有其他设计浮现在脑海中。

但是,您需要一个不同的查询来获取每个应用程序的数据。因此,如果您正在谈论大量应用程序,那么如果您使用EAV设计,它将为您节省大量时间来开发应用程序以获取数据,因为您可能能够创建一个将检索日志的函数通过发送不同的参数来确定任何应用程序的信息。

祝你的申请顺利。