有效的方法来存储多个Excel文件在数据库中？
我们正在开发一个大型的内部项目，使用户可以上传excel文件，并最终对从这些excel中收集的所有数据进行search。 在开始devise之前，我正在做我的功课，并提出最好的解决scheme。
要求是 –
-
用户可以根据自己的需要上传一个带有尽可能多列的excel文件，这样excel就没有预定义的结构 。
-
与第一点相反，我们假设用户有几个字段。 例如 – 名字，姓氏。 这些colums不一定存在。
- search选项将如下工作 – 当用户search时，他可以search特定的列 – 预定义的那些，我们期望他的Excel文件。 （在我们的例子中 – 名字和姓氏）。 他还可以search“其他”字段下的所有其他列。
关于其他search字段的另一个字 – 此字段将遍历所有不符合预定义列的excel文件中的所有列。 IE – 一个文件有一个年龄栏，另一个有一个出生地栏，“其他”栏将search所有这些栏。
什么是最好的方法来做到这一点？
-
dynamic地创build一个新的Django模型为每个上传的excel，所有列的Excel？
-
dynamic地为每个文件创build一个新的Django模型，包含所有预定义的列（如果它们存在！）和一个“其他”文本字段，它将连接所有不相关的字段？
-
有一个大django模型（意味着我的数据库中只有一个表），它具有我所有的预定义字段（也可以为空），还有一个名为“others”的字段将连接所有不相关的列？
-
我可以让我的主表具有所有预定义的列，而另一个表具有到主表的外键，其中每行表示一个“其他”字段。
第四种解决scheme的示例 –
+----+--------+--------+--------+ | id | field1 | field2 | field3 | +----+--------+--------+--------+ | 1 | val1 | val1 | val1 | | 2 | val2 | val2 | val2 | | 3 | val3 | val3 | val3 | +----+--------+--------+--------+ 和维度表 –
+----+------+------+ | fk | key | val | +----+------+------+ | 1 | key1 | val1 | | 1 | key2 | val2 | | 1 | key3 | val3 | | 2 | key4 | val4 | +----+------+------+
至于缩放 – 我们预计最终不会有超过1500个excel文件，每个文件包含100到大约。 100,000行（我们可能会限制每个excel文件的行数为100k）。 我们从专家的统计数据来看，我们不会超过3000万行。
我们将使用Django与MySQL或PostgreSQL 。
我希望我的问题是明确的，不是太不透明。
谢谢！
编辑：当你改变你的问题。 我在模型4上添加了一小段。
我强烈build议不要dynamic创build表。 这是混乱的，我怀疑它会performance不错。 您的数据库将为您要查询的每个数据库表创build一个访问path，所以如果您创build多个数据库文件，则需要search所有这些文件。
你可能需要你的模型3的变种。
这意味着您使用一个表，而是使用每个字段的列，您创build两个列为Excel列名称和一个为它的值。 您还需要一些额外的条目来确定哪个excel列和值属于哪个excel电子表格。
所以在概念上，而不是build模：
field1 field2 field3 field4 other ------------------------------------ xyza etc=xyz
你可以像这样build模：
sheet fieldname value ------------------------------------ key field1 x key field2 y key field3 z key field4 a key etc xyz
这种模式的优点是，编程您的search变得更容易。 您可以将任何searchbuild模为select * from data where fieldname='%s' and value='%s' 。 如果你在fieldname上创build了一个数据库索引（并且可能是你用来识别Excel表的索引），那么对于模型3原来的想法应该没有性能损失。
你的模型4也可以工作。 它的优点是，对于预定义的字段，用户的查询语句将很容易映射到SQL select语句。 它的缺点是你需要处理你的“其他”列与用户的其他search条件不同。 您还表示，用户有时不会input您希望在那里的列。 这意味着你必须使这些列可以为空，这增加了存储需求。
总体而言，我认为我的build议方法比选项4更好，因为它在概念上更简单。 你表示你认为这会造成太多的行。 事实上，这将创造更多的行，但MySQL和PostgresSQL可以很容易的行数。 PostgresSQL可以存储无限数量的行。 MySQL可以存储4千万行（如果需要的话，可以用–big-tables编译MySQL）。
就performance而言，只要你有一个领域的指数，你的表格就没有多大的区别。