假设我有很多时间可以浪费，并决定创建一个数据库，其中信息不存储为实体，而是存储在表示INT、VARCHAR、DATE、TEXT等类型的单独的相互关联的表中。
再也不需要设计数据库结构将是一场革命，除非其他人没有这样做，这可能表明这不是一个好主意：p
那么为什么这是一个糟糕的设计呢？这违反了哪些原则？从关系数据库的实际角度来看，它会导致什么问题？
PS：这是为了学习练习。
问问题
77 次
1 回答
2
为什么不应该根据数据类型从表中分离出字段？好吧，有两个原因，一个是哲学的，一个是实际的。
从哲学上讲，你正在打破规范化
一个适当规范化的数据库将为不同的事物提供不同的表，每个表都具有该特定“事物”所需和唯一的所有字段。如果在我的 CarCollectionDatabase 中查找给定汽车的品牌、型号、颜色、里程、制造日期和购买日期的唯一方法是在按数据类型标记的三个表上加入无意义的键，那么我的数据库的可发现性几乎为零，并且没有真正的凝聚力。
如果您设计了这样的数据库，您会发现编写查询和调试语句会非常烦人。这就是您首先使用关系数据库的原因。
（而且，真的，这将使编写查询变得更加困难。）
实际上，数据库不是这样工作的。
我见过的每一个数据库引擎或数据存储机制根本不适合用于那种抽象级别。无论您使用哪种引擎，我都不知道您将如何解决基本上将数据设计与字段加倍的问题。随着行数增加五倍，您的索引大小将大幅增加，以至于一旦您获得几百万行，您的索引实际上将无济于事。
如果您尝试设计一个这样的数据库，您会发现即使您不介意头疼的问题，最终性能也会变慢。而不是 1,000,000 行和 20 个字段，您将拥有一个包含同样多字段的表，以及大约 5-6 个额外的表，每个表包含 1,000,000 多个条目。即使您优化了它，您的索引也会更大，并且更大的索引运行得更慢。
当然，这两个仅适用于您实际上在谈论数据库时。例如，没有理由应用程序不能序列化为某种文本文件（JSON、XML 等）并且永远不会写入数据库。
并且仅仅因为您的应用程序需要存储 SQL 数据并不意味着您需要存储所有内容，或者不能使用同构和通用表。允许用户定义自己的“表”的类似 Access 的应用程序很可能将每个字段保留在不同的行上……尽管在这种情况下，您的数据库的东西将是那些表及其字段。（而且它的运行速度不如本地编写的数据库。）
于 2013-06-18T02:53:29.043 回答