Нормализовать базу данных с тысячами столбцов - рекомендации по дизайну

Справочная информация. Лаборатория, в которой я помогаю, будет принимать небольшие образцы слюны у мышей. Каждой мыши будет назначен номер пациента (первичный ключ на 1-й таблице), и конкретная информация, относящаяся к каждой мыши, будет сохранена в этой таблице (возраст, пол и т. Д.).Нормализовать базу данных с тысячами столбцов - рекомендации по дизайну

Каждому образцу слюны будет присвоен уникальный номер (первичный ключ, вторая таблица), будет указывать номер пациента и сканировать 1000 раз с помощью своего оборудования. Мне поручено записывать и хранить значения (удваивания) для каждого скрининга слюны каждого пациента, каждый раз, когда пациент отбирается (несколько раз в неделю).

Мы теоретически хотели бы, чтобы все образцы слюны находились в одном столе (я думаю). Это позволит легко генерировать средние значения населения и часто обновляться. Это также помогло бы определить дельт между данным пациентом и соответствующими средними показателями населения (аналогичный возраст, пол и т. Д.).

Моя очевидная забота: 1000+ столбцы не являются хорошей практикой в MySQL или любой другой базе данных. Я изо всех сил пытаюсь придумать хороший способ структурирования этих данных. (Возможно, каждый пациент может иметь свою собственную таблицу показаний образца, но, казалось бы, генерируя средние против всего населения будет проблематично.)

Редактировать Я не уточнил, но каждый скан имеет определенную длину волны света поэтому каждая запись в области сканирования должна ссылаться на ее конкретную длину волны в дополнение к уникальному номеру сканирования.

источник

2016-08-14 David_A

Я не вижу 1000 столбцов в вашем описании. Я вижу 1000 строк. – Solarflare

Каждый образец представляет собой строку, а не столбец. –

Ваш последний абзац говорит «1000+ столбцов». Не делай так. –

Проблема с вашим дизайном заключается в том, что таблица образцов содержит данные для всех сканирований (1000+ из них). Вот где вы столкнулись с проблемами.

Вам нужно 3 стола. Один для пациентов, о котором вы описали. Второй - для образцов, а третий - для сканирования.

Таблица сканирования, в которой будут сканироваться данные сканирования. В этой таблице должно быть 4 столбца ScanId (первичный ключ). SampleId (внешний ключ для ссылки на строку в таблице образцов), номер последовательности, поэтому вы можете поместить все сканирование для образца в хронологическом порядке (при необходимости) и значение сканирования.

В таблице образцов теперь имеются только значения данных, которые встречаются один раз за образец, например, пример даты.

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

источник

2016-08-14 19:16:55

Именно поэтому я понимаю, что в этом случае каждый новый экземпляр сканирования добавит ~ 1000 записей в эту таблицу (сканирование), причем каждая запись ссылается на Образец, и каждый образец ссылается обратно на пациента (но в образцах Таблица). Таблица сканирования в этом сценарии будет иметь место где-то в сотнях тысяч (если не миллионы) строк, но при достойной производительности индексации не должно быть слишком плохого попадания, и я избегаю непристойного количества строк , Является ли это точной оценкой того, что вы описывали? –

Это выглядит правильно. –

-1

Почему бы не использовать MongoDB для этого? У каждой мыши будет документ с данными сканирования.

Затем вы можете использовать встроенную аналитику MongoDB (или использовать что-то вроде Apache Spark), чтобы нарезать и нарезать ваши данные по своему усмотрению.

источник

2016-08-14 14:15:51

Нормализовать базу данных с тысячами столбцов - рекомендации по дизайну

ответ

Смежные вопросы