我想知道以下数据库架构是否会在以后产生影响。假设我正在写一个地方实体。我不确定place的哪些属性将存储在数据库中。我正在考虑制作两个表：一个用于保存所需（或常见）信息，另一个用于保存其他信息。
表1 - 地点
表2 - PlaceData
使用情景
我希望某些访问者能够输入关于某个地点的自定义字段。例如，餐馆是可能具有以下字段的地方：HasParking，HasDriveThru，RequiresReservation等等......但是汽车经销商也是一个地方，这些字段对于汽车经销商。
我想支持任何类型的地方，从单个表格（好吧，第二个表格有自定义字段），因为我不知道最终会添加的地方的类型的数量到我的网站。
总体目标
在我的asp.net MVC（C＃/ Razor）网站上，我显示place，它将显示属性，作为填充的无序列表：SELECT * FROM PlaceData WHERE PlaceId = @0。
这样，我就不需要在视图上显示空字段名称（或者对每个字段进行string.IsNullOrWhitespace()检查。如果每个属性都是一个列，我将被强制执行。表
我假设这种情况很常见，但是有更好的方法吗？特别是从表现的角度来看？这种架构的主要缺点是什么？
答案 0 :(得分：6)
您的想法被称为实体 - 属性 - 值表，并且通常是RDBMS中的坏消息。 RDBMS适用于高度结构化的数据。
总体选项是：
在RDBMS中对数据库进行进一步建模，如果有人拒绝您的规范，则很有可能。
坚持使用RDBMS，使用XML列作为结构可变的数据。如果您的数据存储架构的相对较小部分是半结构化或非结构化的，则这是最有意义的。从MS SQL Server的角度来看，可以对这些数据建立索引，并且可以执行检查，确保数据符合XML模式定义。
转移到非关系数据库，如MongoDB，Cassandra，CouchDB等。这就是许多社交网站和我怀疑博客网站运行的原因。此外，如果您需要，可以使用RDBMS和非关系商店的组合。
EAV变得一团糟，因为您在数据库中创建数据库并失去RDBMS可以提供的所有好处（外键，数据类型实施等）以及重构对象所需的SQL代码从睫毛膏到意大利宽面条，再到意大利面。
鉴于已添加到问题中的信息，似乎非常适合在Place表中创建XML类型的PlaceDetails列。如果性能要求允许，您还可以将该列拆分为另一个具有1：1关系的表。
这样做的好处是，您可以使用非常简单的SQL代码检索数据，甚至使用xml数据类型的方法来搜索数据。但是这种方法还允许你在C＃中进行更复杂的面向表示的数据解析，这比T-SQL更适合于这个目的。
答案 1 :(得分：2)
在任何给定时间，您都可以向数据库中添加新列（始终关注third normalization rule），因此您应该选择所需的内容，并且只在需要时创建第二个表，或者如果这些列中断任何一个normal forms
答案 2 :(得分：2)
如果您希望应用程序能够创建自己的自定义字段，这是一个很好的模型。 Mantis Bugtracker也使用它来允许管理员向他们的故障单添加自定义字段。
如果在任何情况下，程序员将要创建字段，我必须同意pst，这更像是一个不成熟的优化。