有可能拥有一个超过一百万列的SQL表吗？

我正在为微阵列数据建立一个数据库。每个患者样本都有超过1000000个功能，我想将患者样本作为行存储在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可以处理如此多的表列

更新

请注意，所有列都将具有所有行的值。

不要

如果你能让它工作，它将是非常缓慢和笨拙的

相反，您应该为

PatientID

、

Feature

和

Value

创建一个单独的表
此表中的每个单元格都有一行

它还可以添加关于每个患者特征对的附加信息。

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

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

---

SQL数据库不能处理很多列，但可以处理很多行。

尝试将表重新排列为：

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

---

这实际上是（EAV）的一个用例，可能更适合于某些密集环境中的非RDBMS/SQL解决方案。（不过，关系数据库是工作马……在证明不足之前，最好使用关系数据库；-）

维基百科文章：

实体属性值模型（Entity attribute value model，EAV）是一种用于描述实体的数据模型，其中可用于描述实体的属性（属性、参数）数量可能非常多，但实际应用于给定实体的数量相对较少。在数学上，这种模型称为稀疏矩阵

---

愉快的编码。

好吧，根据新的信息，这是同质数字（双）值的密集数组，查询很重要（也就是说，我将不考虑对blob/XML的反规范化和特殊udf的使用），我提出以下建议：

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

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

q

的值是任意的，但出于性能/效率的考虑，应根据特定的数据库实现进行选择（例如，尝试适应SQL Server中的8k记录大小）

然后将每个结果拆分为记录，以便

段

引用该段。即给定特征的“绝对指数”为

n=SEGMENT*q+x

，特征

n

将在

SEGMENT=n/q

的记录中找到。然后，主键是

（ID，段）

因此，查询仍然很容易——唯一的变化是与段之间的转换——唯一的附加要求是

段

（此列也可能参与索引）

（可以使用单独的表格将特征映射到

段/x

或其他位置。这样，它与EAV模型类似。）

因此，虽然在某些方面与完全规范化的形式类似，但它利用了初始矩阵的压缩/同质/静态特性，显著减少了记录的数量——200万条记录可以说是一个小表，2000万条记录只是一个“中型”表，2亿条记录（200个芯片x每个芯片100万个功能的结果，如果每个功能产生一个记录）开始变得令人望而生畏。虽然相同的复杂性，

q

为200会将记录数量减少到仅1000万条。（每个压缩的记录在数据/结构比方面也更有效。）

快乐编码

---

---

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

我曾想过这样做，但这似乎是个坏主意。首先，它不那么容易使用，其次，如果我想查询我的一个数据集中所有患者的所有特征，我将得到80000000行。我猜会的非常慢。你认为呢？@Nixuz:这应该比你的模型更快、更容易操作。@Nixuz:但是在80M+行表中运行查询之前，检查你必须添加哪些索引。你真的收集了每个患者的一百万个数据点，还是更像是你正在寻找的一百万个数据点中的几百个对于@Conrad，我正在使用每个阵列（芯片）有超过一百万个ProbeSet的人类表达微阵列。这有点技术性，但基本上这意味着我们的样本有超过一百万个特征，所有特征都有值（数字双精度）。@Nixuz如果不是稀疏数据（我最初假设是这样！），可能只是将数据存储在适当的非规范化形式中，具体取决于访问要求。例如，单个blob、按块范围的blob、XML（可在某些数据库中查询、fsvo查询），预提取的统计数据，等等。此外，由于这是如此专门化，RDBMS可能不是存储它的最佳方式——同样，这取决于访问要求。@Nixuz我认为不一定会有一种简单的方式——我首先要确定所需的访问/查询用例，然后看看如何以最少的数量实现它t的痛苦；-）一个杂交可能是分割每个结果在多个记录，例如，1000个同质值连同段数。（每个CPU只有一个1000条记录，而不是1000000条，并且应该是相对可查询的——只包括段号。）