Question

我正在开发一个应用程序，它接受任何上传的CSV数据，将其与之前上传的其他数据集一起存储，然后根据用户选择要返回的列/值来生成输出（CSV或HTML）。数据库将自动扩展，以根据需要处理新的/不同的列和数据类型。这优先于实体 - 属性 - 值模型。

示例 - 将这两组上传到空白数据库：

数据集A：

name  | dept  | age   
------+-------+------
Bob   | Sales | 24
Tim   | IT    | 32

数据集B：

name  | dept  | age  | salary
------+-------+------+--------
Bob   | Sales | 24   | £20,000
Tim   | IT    | 32   | £20,000

将以编程方式更改“数据”表，以便导入数据集A可以生成3个新创建的列（名称，部门，年龄）。导入数据集B会生成1个新创建的列（薪水）。目前，忘记记录集是否应该合并，并且没有规范化。

我遇到的问题是某些列也会有查找值 - 让我们说Dept列在将来的某个时刻会有相关的值，这些值会给出该部门的地址和电话号码。对于Salary列，查询税收分组等也是如此。

这个大表中的列数不应该太高（几百个），但要高到足以让用户通过管理面板管理查找表结构和值，而不是每次都要让开发人员参与

问题是对每列使用单独的查找表（值，描述），还是引用列（列，值，描述）的组合查找表。通常我会选择单独的查找表，但是这里应用程序需要自动创建它们（例如lookup_dept，lookup_salary），然后在主SQL语句中添加一个新的连接。这将在用户请求时完成，而不是在添加列时（以避免数百个空表）。

另一方面，组合查找表需要多次连接到数据表上，每次都选择列名称。

单个查找似乎对我有意义，但我可能会完全咆哮错误的树。

Answer 1

我同意个人表更可取。它更具可扩展性，更适合查询优化。此外，如果将来用户希望在特定查找上有更多列，则可以添加它们。

是的，应用程序必须自动创建表和约束：我通常不会这样做，但是这个应用程序已经在改变现有表并向它们添加列，我通常也不会这样做！

Answer 2

啊，“One true lookup table”的想法。我同意Celko先生的罕见时刻之一。 Google search too

每次都有个别表格。它在数据库意义上是“正确的”。

我的理由（请不要规范化）：表中的每一行只存储一个实体。例如水果名称，汽车品牌，手机品牌。混合它们是无稽之谈。我可以拥有一个名为“Apple”的手机品牌。呃......等一下......

Answer 3

你说，

这优先于实体 - 属性 - 值模型。

但在我看来，这正是你所需要的。

考虑使用RDF三元组，并使用SPARQL进行查询。

忘记SQL，这是RDF的工作。