我有一个表格，用于存储所有客户共有的客户（姓名，地址等）的一般信息。我有一个名为CustomerType（类型列表）的字段，它驱动我需要捕获的其他字段。因此，如果他们是政府客户，那么他们将看到一组不同于非营利客户的自定义字段。我需要创建每个不同CustomerType将填写的表单。在SQL方面，我需要找出存储数据的最佳方法，这样当我报告时很简单。我不知道解决这个问题的最佳方法。
答案 0 :(得分：0)
首先，看看有关数据库设计和对象关系建模（ORM）的一些好的教程A beginner's guide to SQL database design
我个人对您的设计的建议是创建一个表来存储所有客户，以及某种独特的客户ID和CustomerType。接下来为每个CustomerTypes创建一个单独的表，并为属于该类型的每个用户创建一个单独的表，将该用户唯一ID与其客户类型特定字段一起存储在该列中。
答案 1 :(得分：0)
在SQL方面，我需要找出存储数据的最佳方法 当我做报告时很简单。我不知道攻击它的最好方法 问题
有许多可能的方法各有不同的优点和缺点，这里有一些想法：
为每个客户类型创建单独的客户明细表，每个客户类型包含特定于该客户类型的字段。每个明细表都以客户ID为主。客户类型不必是详细信息表的属性，只能是父Customer表的属性。
（+）正确规范化的解决方案（尽管您可能会遇到尴尬的情况 其中属性对于客户类型的子集是通用的）。这些表格相当容易维护。
（ - ）报告更难写 - 您可能会发现自己使用了大量的联合或外部联接。针对此模式的开发更复杂，在特定客户类型的正确表中插入/更新属性的额外逻辑必须在某处进行编码。如果您有许多客户类型，或者您经常添加/更改它们，这可能会变得无法管理。
展开客户表，以包含所有客户类型所需的超级列，并以客户ID为键。
（+）简单，易于报告，简单的编程逻辑。
（ - ）客户类型特定字段仅部分依赖于客户表的密钥（客户ID） - 它们实际上取决于customerId / customerType的组合。 如果有许多额外的字段，并且如果客户类型之间的字段很少，那么这种非规范化可能会导致一个非常宽的表，其列数无法管理。这可能是维护的噩梦 - 每次添加/更改新客户类型时都必须修改表。 如果每种客户类型所需的唯一字段数量很少而且它们不经常更改，并且编程和报告的简易性是最重要的考虑因素，那么您可能会发现这是一个很好的解决方案。
将客户特定值作为名称/值对存储在通用客户详细信息表中，键入customerId / customerType / key。
（+）维护非常简单 - 无需更改数据模型即可添加新的客户类型。
（ - ）非关系型，使纯SQL报告几乎不可能，并且使得完整性约束很难添加。您可能会在专业用例中看到这种情况，例数据只会作为JSON使用，直接报告永远不会是必需的，或者在某些企业环境中，如果数据库更改很难实现，那么数据可能很有吸引力。