船舶管理数据库结构讨论（应该非规范化？）答案

【问题标题】：Ship management database structure discussion (should denormalize?)船舶管理数据库结构讨论（应该非规范化？）
【发布时间】：2010-10-07 01:46:25
【问题描述】：

我的软件几天前投入生产了，现在我想谈谈数据库结构。

软件收集船舶数据，目前每艘船有174个详细信息，每个详细信息可以是文本值、长文本值、数字（指定长度，有或没有指定小数位数）、日期、带时间的日期、布尔字段、包含许多值的菜单、数据列表等等。

我用下表解决了问题

船： - ID - smallint，自动增量标识 - IMO - int，一个在船舶寿命期间不会改变的数字 ShipDetailType: - ID - smallint，自动增量标识 - 描述 - nvarchar(200)，字段包含的值的描述 - Position - smallint，字段在数据输入表单中的位置 - ShipDetailGroup_ID - smallint，数据输入表单中字段所属组的键 - 类型 - varchar(4)，字段的类型如上所述 ShipDetailGroup - ID - smallint，自动增量标识（剪断……） ShipMenuPresetValue - ID - smallint，自动增量标识 - ShipDetailType_ID - smallint，值所属详细信息的键 - Value - nvarchar(100)，菜单类型详细信息中预设的值 ShipTextDetail - ID - smallint，自动增量标识 - Ship_ID - smallint，详细信息所属船舶的密钥 - ShipDetailType_ID - smallint，值的详细类型的 Key - 文本 - nvarchar(500)，包含详细信息值的字段 - 修改日期 - 小日期时间 - User_ID - smallint，用户表的键船舶文本详细历史（剪断……）此表与 ShipTextDetail 相同，包含对详细信息的所有更改。列表详细信息类型的其他表，每个表都包含列表所需的指定字段，...

我刚刚读到这篇文章：http://thedailywtf.com/Articles/The_Inner-Platform_Effect.aspx 和 http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:10678084117056

文章说这不是处理问题的正确方法。

我的客户在更改详细信息描述并添加更多详细信息时拥有详细信息和组的管理 GUI。

数据输入表单是通过从DetailGroups和DetailTypes中读取结构动态构建的，每个详细类型生成一个指定的输入控件。

cmets 建议解决此问题的另一种方法是从表中动态创建和删除列。

你怎么看？

图表截图：http://img24.imageshack.us/my.php?image=66604496uk3.png

【问题讨论】：

你有数据架构图吗？
我发布了数据架构的屏幕截图
"数据输入表单是动态构建的" 因为我还不能编辑帖子："数据输入表单是动态构建的"
建议更好的标题？

标签： database database-design normalization denormalization

【解决方案1】：

从性能的角度来看，任何一种方法都可以。可能有多少艘船？所有数据都将适合任何服务器上的 RAM。

【讨论】：

我认为会少于200艘

【解决方案2】：

如果：

您的客户投诉了
您发现了一些不起作用的东西
您发现代码无法处理你知道会发生的改变未来。

您记得编写允许您重构的单元测试，对吧？

*就你那里的结构而言，我以前见过类似的结构。这有点麻烦，但在很多地方都是标准的。要记住的一件事是，虽然可以从数据库中动态添加和删除列，但数据库的内部存储机制并不一定希望您连续添加和删除这些列。但我认为与上述几点相比，这不是很相关，归结为：*它有效吗？

【讨论】：

是的，它确实运作良好，但我喜欢质疑自己，培养新的能力并扩展我的知识。

【解决方案3】：

我以前见过这种方法，一旦数据量增加，它就会出现大量性能问题。当您需要返回多个项目并在 where 子句中使用多个条件时，您会遇到这种问题。您在 Ship 和 ShipTextDetail 之间来回加入以获得所有选择的列 - 也许您必须这样做 10/20 次？然后你对你的标准做同样的事情可能 2-3 次。现在您有一个包含如此多连接的查询，它的运行速度非常慢。接下来，您“预煮”一些数据以提高性能，即将常用数据拖到固定表结构中 - 啊，您已经返回到半规范化模型。

我的建议是这样 - 您知道 174 个字段的信息，这些字段是您的核心属性。您的客户可能会添加到该列表中，并且可能会更改字段的描述，但这仍然是一个非常好的起点。围绕这些创建一个适当的 DataModel，然后构建一个可扩展性机制，就像您已经完成的那样，但仅适用于新字段。元数据 - 字段的描述，可以位于另一个表中，或者可能位于资源文件中（对国际化有用吗？），这为现有字段提供了一些灵活性。

我同意 Joe 的观点，如果您的数据库很小，即

祝你好运。

【讨论】：

【解决方案4】：

我做过类似的事情，但是这个具体的实现有几个问题：

您将数字、布尔值、日期等存储为字符串。这可能不太理想。另一种方法是为不同的数据类型实现单独的类（从基类继承），然后将它们存储在为其数据类型创建的表中。
您跟踪的属性是否经常更改？每个油轮有不同的设置吗？如果没有，最好制作对象而不是属性包来存储所有数据。然后可以将这些对象持久化到数据库中。

【讨论】：

我决定以简单的方式存储它们，因为存储在文本列中的数据不需要由过程计算。仅显示和编辑数据。现在，客户每天都在进行更改。客户希望自己管理物业。您认为 180 列的表格可以吗？
每艘油轮都有相同的属性集。但并非所有属性都已设置。