Несколько возможных типов данных для одного и того же атрибута: пустые записи, EAV или сохранить как varchar? - PullRequest
Новая
       36

Несколько возможных типов данных для одного и того же атрибута: пустые записи, EAV или сохранить как varchar?

0 голосов
/ 12 июля 2019

Я создаю базу данных для экспериментов сгорания. Каждый эксперимент имеет некоторые научные метаданные, которые я называю «подробностями». Например («Топливо», «C2H6») или («Давление», 120). Поскольку одни и те же имена деталей (например, «Топливо») часто появляются, я создал таблицу только для хранения имен и единиц измерения. Вот упрощенная версия: 

CREATE TABLE properties (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(50) NOT NULL,
    units NVARCHAR(15) NOT NULL DEFAULT 'dimensionless',
);

Я также создал таблицу под названием «детали», которая сопоставляет «свойства» со значениями. 

CREATE TABLE details (
    id INT AUTO_INCREMENT PRIMARY KEY,
    property_id INT NOT NULL,
    value VARCHAR(30),
    FOREIGN KEY(property_id) REFERENCES properties(id)
);

Это не идеально, потому что атрибут value - это иногда химическое имя, а иногда и число с плавающей точкой. В будущем могут даже появиться новые записи с целочисленными значениями. Хранение всего в VARCHAR кажется расточительным. Поскольку потом будет трудно измениться, я хочу принять правильное решение сейчас.

Я искал это часами и рассмотрел четыре варианта:

  1. Храните все как varchar под value (проще всего разработать)
  2. Используйте модель EAV (сложнее всего разрабатывать).
  3. Создать столбец для каждого типа и иметь множество записей NULL. value_float, value_int, value_char
  4. Используйте тип данных JSON.

Глядя на каждого, кажется, что они все плохие по-разному. (1) плохо, так как занимает дополнительное место, и мне нужно выполнить дополнительные операции для разбора строк в числовые значения. (2) плохо из-за огромного увеличения сложности (четыре дополнительные таблицы и намного больше операций соединения), плюс я слышал, что EAV следует избегать. (3) является средним уровнем сложности, но для каждой записи таблицы будет два значения NULL. (4) похоже на (1), и я не уверен, как это может быть лучше или хуже.

Я не ожидаю значительного роста этой базы данных или миллионов записей. Это просто должно быть быстро и доступно для поиска исследователей. Я желаю иметь больше внутренних сложностей для лучшего / более быстрого взаимодействия с пользователем.

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

РЕДАКТИРОВАТЬ : добавлен JSON в качестве опции.

...