具有多个NULL的数据的表结构
我目前正在尝试建模一个动态数据对象，该对象可以拥有或丢失一些属性(属性名是已知的当前需求)。还不知道以后是否会添加新的属性(但几乎可以肯定)。所建模的对象是沿着这条线进行的：
int id PRIMARY KEY NOT NULL;
int owner FOREIGN KEY NOT NULL;
Date date NOT NULL;
Time time NOT NULL;
Map<String,String> properties;属性可以是任意类型( int、bool、string、.)
我不知道应该如何在SQL数据库中建模这个对象。有两种方法，我可以这样做，我想有一些输入，这将是更好的选择，从开发人员的“工作”(维护)，内存消耗和性能。作为侧信息:属性几乎总是空的(不存在)
(1)我将有一个大表，它将id、所有者、日期、时间和每个属性作为列，而对一行缺少的属性则建模为NULL。例如：
TABLE_X
id|owner|date|time|prop_1|prop_2|prop_3|...此表将具有大量的空值。
如果应该添加新属性，那么我将执行ALTER，并为每个新属性插入一个新列。
在这里，我会做一个“平常的”
SELECT * FROM TABLE_X ...(2)我将有一个主表，其中包含所有非空数据：
TABLE_X
id|owner|date|time然后为每个属性设置一个单独的表，如下所示：
TABLE_X_PROP_N
foreign_key(TABLE_X(id))|value这里根本没有空值。属性要么有一个值并且在其相应的表中，要么它是空的，然后它就不会出现在它的表中。
要添加新属性，只需添加另一个表即可。
这里是做一个
SELECT * FROM TABLE_X LEFT JOIN TABLE_X_PROP_1 ON ... LEFT JOIN TABLE_X_PROP_2 ON ...重复这个问题(所以你不必向上滚动)：在维护(为开发人员工作)、内存消耗(磁盘上)和性能(每秒更多的查询)方面，这两种处理问题的方式中哪一种更好？也许你对如何处理这件事也有更好的想法。提前感谢
回答 3
Stack Overflow用户
发布于 2016-12-08 23:37:08
如果选择2，我认为您需要3张表：
TABLE_HEADER
id_
TABLE_PROPERTY
id_名称
TABLE_PROPERTYVALUE
id=headerID(FK)\x\x{e76f}_
易于添加新属性可以使您具有更大的灵活性和更快的迭代速度。属性的数量也会产生影响(例如，如果您有500个属性，您将不需要一个包含500列的表！)。主要的缺点是，如果您需要附加复杂的业务逻辑，使用属性作为一个更复杂的结构来导航，那么它将变得很难看，而且您不能对特定字段强制数据完整性，比如null。如果您真的想要一个像您在对象结构中建模的属性包，那么这个映射非常容易。喜欢一切，它取决于您的环境，什么是最合适的。
Stack Overflow用户
发布于 2016-12-08 23:23:36
解决方案2.但是为什么每个属性没有单独的表。把所有东西放在一张桌子上：
properties(
foreign_key(TABLE_X(id))
property_name,
value);Stack Overflow用户
发布于 2016-12-08 23:41:14
听起来你想在这里实现一个实体属性值(经常被视为反)模式。你熟悉他们吗？以下是一些参考资料：
https://softwareengineering.stackexchange.com/questions/93124/eav-is-it-really-bad-in-all-scenarios
http://www.dbforums.com/showthread.php?1619660-OTLT-EAV-design-why-do-people-hate-it
就我个人而言，我对RDBMS中的这种设置非常谨慎。我倾向于认为NoSQL文档风格的数据库更适合这些类型的动态结构，尽管我自己对NoSQL的实际经验相对较少。
https://stackoverflow.com/questions/41050498
复制相似问题
腾讯云开发者
