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