Можно ли иметь таблицу SQL с более чем миллионом столбцов?

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, или есть другая СУБД, которая может обрабатывать такое большое количество столбцов таблицы?

Обновление

Обратите внимание, что во всех столбцах будут значения для всех строк.

Answer 1

Не.

Событие, если вы можете заставить его работать, оно будет очень медленным и громоздким.

Вместо этого вы должны создать отдельную таблицу со столбцами для PatientID,Feature и Value.
Эта таблица будет содержать по одной строке для каждой ячейки в предложенной вами таблице.

Она также позволяет добавлять дополнительную информацию о каждой паре пациент-признак.

Answer 2

Попробуйте переставить ваш стол на:

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

Answer 3

Обычно вы разделяете (нормализуете) таблицы:

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

Базы данных SQL не могут обрабатывать много столбцов, но могут обрабатывать много строк.

Answer 4

На самом деле это вариант использования для Модель-атрибут-значение-значение (EAV), и он может на самом деле лучше подходить для не RDBMS / SQL-решений в некоторых интенсивных средах.(Реляционная база данных - это рабочие лошадки, хотя ... она могла бы использовать одну, пока ее явно недостаточно) -)

Из статьи в Википедии:

Entity-attribute-value-valueмодель (EAV) - это модель данных для описания объектов, где количество атрибутов (свойств, параметров), которые могут использоваться для их описания, потенциально огромно, но число, которое фактически будет применяться к данному объекту, относительно скромно.В математике эта модель известна как разреженная матрица.

Счастливое кодирование.

Answer 5

Что ж, с новой информацией о том, что это плотный массив однородных числовых (двойных) значений, и запросы важны (то есть я не буду обращать внимание на денормализацию в BLOB-объекты / XML и использование специальные UDF), я предлагаю следующее:

Разделить каждый результат на несколько записей, где каждая запись имеет вид:

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

Значение q является произвольным, но его следует выбирать в зависимости от конкретной реализации базы данных (например, попытаться вписаться в размер записи 8k в SQL Server) из соображений производительности / эффективности.

Каждый результат будет затем разбит на записи так, что SEGMENT относится к сегменту. То есть «абсолютный индекс» данной функции равен n = SEGMENT * q + x, а функция n будет найдена в записи, где SEGMENT = n / q. Из этого следует, что первичный ключ - (ID, SEGMENT).

Таким образом, запрос по-прежнему прост - единственным изменением является преобразование в / из сегмента - с единственным дополнительным требованием SEGMENT (этот столбец также может участвовать в индексе).

(Отдельная таблица может использоваться для сопоставления объектов с SEGMENT/x или другим способом. Таким образом, она аналогична модели EAV.)

Таким образом, несмотря на то, что в некоторых отношениях он похож на полностью нормированную форму, он использует преимущества упакованной / однородной / статической особенности исходной матрицы для значительного сокращения количества записей - в то время как 2 миллиона записей - возможно небольшая таблица и 20 миллионов записей - это всего лишь таблица среднего размера, 200 миллионов записей (результат 200 чипов x 1 миллион функций на чип, если каждая функция приводит к записи) начинает устрашать. При той же сложности, q из 200 уменьшит количество записей до 10 миллионов. (Каждая сжатая запись также намного более эффективна с точки зрения соотношения данных / структуры.)

Удачного кодирования.

---

Хотя вышеизложенное является одним из предварительных предположений «что если» с моей стороны, я бы рекомендовал более подробно изучить проблему - в частности, точные требуемые схемы доступа к данным. Я не уверен, что это «типичное» использование стандартной СУБД, и СУБД может даже не быть хорошим способом решения этой проблемы.