Лучший способ сохранить значение, которое может быть нескольких типов

Я хотел бы повторно задать вопрос более прямым и общим способом:

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

В моем случае значения обеспечивают диагностику события. Пример: Событие произошло -> Хранить показания нескольких ПЛК, которые содержат соответствующую информацию о событии. ПЛК может контролировать любой тип данных.

Некоторые примеры, которые я могу придумать:

Создайте столбец для каждого возможного типа и создайте другой столбец, чтобы указать, какой столбец использовать
- Пример: Cols: IntVal, StrVal, BoolVal, Тип. Vals: null, null, True, "BOOL"
Храните значения независимо от того, что как varchar

sql-server database-design

— Джаред Бич
источник

Казалось бы, вам уже сказали, что вы сбиваетесь с пути к модели EAV . Посмотрите на изображение здесь, почему модель EAV следует избегать практически любой ценой.

Билл Карвин, автор, отвечающий за изображение выше, написал книгу «Антипаттерны SQL: предотвращение ловушек программирования баз данных» и посвятил первую главу анти-шаблону EAV. Он также большой нападающий в этой группе и большой в StackOverflow (для проблем с базой данных).

Мой совет - иметь таблицу для каждого типа результата, а затем использовать VIEWs, чтобы объединить их при необходимости.

В качестве примера вы могли бы иметь

CREATE TABLE char_result
(
  question_id INT,
  user_id INT,
  cresult CHAR,
  result_correct BOOLEAN (or equivalent in your RDBMS)
  ..
  <other stuff>
  ..
);

Сделайте то же самое для num_result, за исключением замены nresult INT (FLOAT ... что угодно) на cresult - та же идея для VARCHAR & c.

Затем создайте VIEWs для разных таблиц результатов result_correct(и других полей - number_of_attempts... & c. - какими бы ни были ваши другие поля). В этом случае вы сравниваете подобные вычисления с одинаковыми, а не производящими, что эквивалентно добавлению населения к высоте согласно веселому изображению, указанному выше!

— Verace
источник

В противовес Биллу я написал в пользу EAV здесь: sqlblog.com/blogs/aaron_bertrand/archive/2009/11/19/…

— Аарон Бертран

Я не думаю, что наличие нескольких возможных типов для одного логического столбца составляет EAV. Я думаю, что он ищет тип «вариант / объект». Это гораздо проще сделать с несколькими столбцами, чем с одной таблицей для каждого типа. Это звучит очень неудобно. И после создания представления это действительно то же самое, что и создание типов в одной таблице.

— USR

@usr Мне было бы интересно увидеть ваше решение.

— Джаред Бич

Мне кажется, что только один столбец для каждого типа подходит. Я делал это в прошлом. Это наименее плохое решение. Вот еще один аргумент: что если бы было два столбца с переменной типизацией. Решение этого ответа требует квадратичного числа таблиц. Можно разбить его на основную таблицу плюс еще N * M таблиц ... Это не так.

— USR

@usr - это не одна проблема с вашим решением, которой не может быть ни один из этих столбцов NOT NULL? Лично я верю в то, что когда-либо у меня будет NOT NULLконсистенция .

— Верас

Я думаю, что если бы это было абсолютно необходимо для хранения значения таким образом в реляционной базе данных, я бы использовал решение, такое как столбцы JSON в Microsoft SQL Server .

— Джаред Бич
источник