我正在研究一个项目。它主要用于学习目的，我发现实际上尝试复杂的项目是掌握基础知识后学习语言的最佳方式。数据库设计不是一个强项，我开始阅读它，但它的早期和我仍在学习。
这是我的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
这看起来像处理这样的动态字段的有效方法还是有其他替代方法？
默认值将是硬编码的，因此您可以使用它们或替换为您自己的默认值，或者我可以创建另一个表以允许用户编辑将链接到其项目的默认名称。任何反馈都是受欢迎的，如果计划中有一些非常明显的问题，请随意批评。
答案 0 :(得分：18)
你重新发明了一个名为Entity-Attribute-Value的旧反模式。表中自定义字段的概念在逻辑上与关系数据库不兼容。 relation具有固定数量的字段。
但即使它不是正确的关系，我们有时仍需要这样做。
有一些方法可以模仿SQL中的自定义字段，但大多数方法都会破坏规范化规则。有关示例，请参阅：
答案 1 :(得分：0)
我发现这是在寻找与客户可以提交自定义字段以供以后使用的类似内容。
我同意使用JSON数据类型，当提出此问题时，我不知道该数据类型不可用。