涉及动态字段的数据库结构

Question

我正在做一个项目。它主要用于学习目的，我发现实际上尝试一个复杂的项目是掌握基础知识后学习语言的最佳方式。数据库设计不是一个强项，我开始阅读它，但它处于早期阶段，我仍在学习。

这是我的 alpha 架构，我真的只是想记下我能想到的所有内容，看看是否有任何问题跳出来。 http://diagrams.seaquail.net/Diagram.aspx?ID=10094#

我想就我的一些担忧提出反馈意见：

注意区域等核心属性，例如，为了简单起见，这些区域是厨房、卧室、花园、浴室和客厅。对于可能是主页、联系页面、about_us、启动屏幕的另一个客户。可以是2个区域，也可以是100个，没必要限制。

我为默认值创建了单独的表，每个表都链接到一个错误。后来我遇到了自定义字段的问题，例如，如果有人想标记错误适用于哪个主题，我们没有，可能还有 100 其他东西所以我想坚持一组核心属性和自定义字段给予人们灵活性。

但是，当我进入自定义字段时，我知道我遇到了问题，我不能为每个自定义字段创建一个表，所以我改为使用 2 个表。自定义字段和 custom_field_values。这个想法是每个字段（包括默认值）都将存储在此表中，并且每个字段都将链接到值表，该表将具有类似的内容

custom_fields table
id            project_id        name
01            1                 area(default)
12            2                 rooms(custom)
13            4                 website(custom)

custom_field_values table
id            area           project_id    sort_number
667           area1          1             1
668           area2          1             2
669           area3          1             3
670           area4          1             4
671           bedroom        2             1
672           bathroom       2             2
673           garden         2             3
674           livingroom     2             4
675           homepage       4             1
676           about_us       4             2
677           contact        4             3
678           splash page    4             4

这看起来是一种处理此类动态字段的有效方法还是有其他替代方法？

默认值将被硬编码，因此您可以使用它们或替换为您自己的，或者我可以创建另一个表以允许用户编辑将链接到他们的项目的默认值的名称。欢迎提供任何反馈，如果方案中存在非常明显的问题，请随时批评。

Answer 1

您重新发明了一个名为Entity-Attribute-Value 的旧反模式。表中自定义字段的想法在逻辑上与关系数据库确实不兼容。 relation 具有固定数量的字段。

但即使它不是适当的关系，我们有时仍然需要这样做。

有几种方法可以模仿 SQL 中的自定义字段，但其中大多数都违反了规范化规则。有关示例，请参阅：

• Product table, many kinds of product, each product has many parameters 在 StackOverflow 上
• 我的演讲Extensible Data Modeling with MySQL
• 我的书SQL Antipatterns: Avoiding the Pitfalls of Database Programming

Answer 2

我在搜索类似的东西时发现了这一点，因为客户可以提交自定义字段以供以后使用。

当被问到这个问题时，我决定使用我欣赏的数据类型 JSON 不可用。