Question

我正在为微阵列数据构建数据库。每个患者样本都有超过1,000,000个功能，我希望将患者样本作为行存储在SQL表中，每个功能都作为一列。

                 HuEX Microarray Data
+----+----------+----------+-----+------------------+
| ID | Feature1 | Feature2 | ... | Feature1,000,000 |
+----+----------+----------+-----+------------------+
| 1  |   2.3543 |  10.5454 | ... |          5.34333 |
| 2  |  13.4312 |   1.3432 | ... |         40.23422 |
+----+----------+----------+-----+------------------+

我知道大多数关系数据库系统都限制了表中的列数。

+------------+-----------------+
|       DBMS | Max Table Col # | 
+------------+-----------------+
| SQL Server |  1,024 - 30,000 |
|      MySQL |    65,535 bytes |
| PostgreSQL |     250 - 1,600 |
|     Oracle |           1,000 | 
+------------+-----------------+

显然，这些限制对我的任务来说太低了。反正有没有增加SQL数据库表可以拥有的列数，还是有另一个DBMS可以处理如此多的表列？

更新

请注意，所有列都包含所有行的值。

Answer 1

别。

如果你能使它发挥作用，那将是非常缓慢和笨拙的事件。

相反，您应该创建一个包含PatientID，Feature和Value列的单独表格。
对于您建议的表格中的每个单元格，此表格将有一行。

它还可以添加有关每个患者特征对的其他信息。

Answer 2

您通常会拆分（规范化）表格：

Sample: ID, PatientID
Feature: ID, Name
SampleFeature: SampleID, FeatureID, value

SQL数据库无法处理很多列，但它们可以处理很多行。

Answer 3

尝试重新排列表格：

CREATE TABLE MicroarrayData (
    SampleID  INTEGER,
    FeatureID INTEGER,
    Value     REAL,
    PRIMARY KEY (SampleID, FeatureID)
);

Answer 4

这实际上是Entity-Attribute-Value Model（EAV）的用例，在某些激烈的环境中实际上可能更适合非 RDBMS / SQL解决方案。（关系数据库虽然是......但也可以使用一个，直到它证明是不够的; - ）

来自维基百科的文章：

实体 - 属性 - 值模型（EAV）是一种数据模型，用于描述可用于描述它们的属性（属性，参数）数量可能很大但实际应用于给定数量的实体实体相对适度。在数学中，这个模型被称为稀疏矩阵。

快乐的编码。

Answer 5

好吧，继续使用新信息，这是密集数组的同源数值（双精度）值和查询很重要（也就是说，我将忽略去规范化为blobs / XML和使用特殊UDF），我提出以下建议：

将每个结果拆分为多个记录，其中每个记录的格式为：

ID, SEGMENT, IDx ... // where x is [0, q]

q的值是任意的，但应根据特定的数据库实现（例如，尝试适应SQL Server中的8k记录大小）来选择，以提高性能/效率。

然后将每个结果拆分为记录，以便SEGMENT引用该段。这就是给定功能的“绝对索引”n = SEGMENT * q + x，功能n将在SEGMENT = n / q的记录中找到。然后，主键为(ID, SEGMENT)。

因此查询仍然很容易 - 唯一的变化是转换到/来自细分 - 唯一的额外要求是SEGMENT（此列也可能参与索引）。

（可以使用单独的表格将要素映射到SEGMENT/x或其他。这样就类似于EAV模型。）

因此，虽然在某种程度上类似于完全规范化的形式，但它利用了初始矩阵的打包/同质/静态特征性质来显着减少记录的数量 - 而200万条记录是一个可以说是小的表而2000万条记录只是一个“中型”表，2亿条记录（200个芯片的结果x每个芯片100万个功能，如果每个功能都有记录）开始变得令人生畏。虽然相同的复杂性，q为200，但记录数量将减少到仅为1000万。（就数据/结构比而言，每个压缩记录也更高效。）

快乐的编码。

虽然以上是我的一个暂定的“假设”建议，但我鼓励更多地探讨这个问题 - 特别是所需的确切数据访问模式。我不确定这是标准RDBMS的“典型”用法，而RDBMS甚至可能不是解决此问题的好方法。

是否有可能拥有超过一百万列的SQL表？

5 个答案: