我正在重构一个可怕的交织在一起的数据库模式,这并不是说它过于规范化;只是随着时间的推移变得丑陋,布局也不是很好。
有几个表(论坛、论坛帖子、想法帖子、博客条目)共享几乎相同的数据结构和组成,但只是因为从应用程序的角度来看,它们代表不同的“对象”而被分开。我最初的反应是将具有相同数据结构的所有内容放到同一个表中,并在执行select操作时使用"type“列来区分数据。
我采用这种“全部合一”的方法,并且(潜在地)允许应用程序的许多部分访问同一个表,这是在为自己做准备吗?仅供参考,我认为这个数据库在未来一年左右不会超过20MB……
发布于 2010-02-16 16:58:08
我过去不喜欢这种“一体化”的方法,但在几年前我被迫在一个复杂的项目中使用它后,我成了它的粉丝。如果您对表进行了正确的索引,那么性能应该是正常的。例如,您需要在类型列上建立索引,以加快按类型排序的操作。
我现在通常建议您使用单个表来存储相似的对象。那么,唯一的问题是,您是否希望使用子表来存储特定于特定类型对象的数据?这个问题的答案实际上取决于每种对象类型的结构有多不同,以及您将拥有多少对象类型。如果您有50个结构差异很大的对象类型,您可能需要考虑仅将一致的对象部分存储在主表中,并为每个对象类型创建一个子表。
但是,在您的示例中,我认为只需将所有内容放入一个表中即可。
欲了解更多信息,请访问此处:http://www.agiledata.org/essays/mappingObjects.html。
发布于 2010-02-16 17:14:58
在关系数据库中存储对象继承层次结构基本上有三种方法。每种方法都有自己的优缺点。请参见:
The book也很棒。幸运的是,第3章-“映射到关系数据库”- is available freely as a sample chapter。你可以在那里阅读更多关于权衡的内容。
发布于 2010-02-16 17:35:03
不要过于依赖于“应用程序视角”,它往往会随着时间的推移而变化。通常,数据库也会被不同的应用程序访问,而且它通常比所有应用程序都更持久……
当相似的对象存储在不同的表中时,原因可能是它们实际上表示相同的域对象,但处于不同的状态,或者处于工作流中的不同步骤。因此,将它们保存在一个表中并添加一些简单的属性来标记状态通常是有意义的。如果工作流发生了变化,那么更改数据库和应用程序也会更容易,您可能不需要添加更多的表或类。
https://stackoverflow.com/questions/2271556
复制相似问题