MySQL с использованием NULL/NOT NULL VARCHAR вместо TINYINT

Question

Я записываю данные формы у пользователя и сохраняю эти данные в базе данных MySQL. Многие вопросы - это вопросы «Да/Нет». После небольшого исследования я решил пойти с TINYINT для типа данных. Теперь, если для одного из вопросов потребуется текстовый ввод, если ответ «Да», но нет ввода текста, если ответ «Нет», очевидно, мне понадобится VARCHAR для этого ввода.

CREATE TABLE `UserResponse` (
    `question1` TINYINT NOT NULL,  # 0="No", 1="Yes" 
    `question1Details` VARCHAR(45) NULL 
) 

Так что мой вопрос ... Так как VARCHAR всегда будет NULL, когда TINYINT является 0, будет ли это иметь больше смысла, чтобы просто иметь VARCHAR и забыть о TINYINT для «Да»/«Нет» ?

CREATE TABLE `UserResponse` (
    `question1` VARCHAR(45) NULL  # NULL="No", !NULL="Yes" + details 
) 

Мои мысли: Использование двух столбцов может засорять базу данных, если есть много примеров такого рода вопрос (может означать 40 столбцов, а не 20, к примеру). Что касается пространства ... VARCHAR требуется независимо, и его значение не влияет на использование TINYINT или нет. Поэтому, если мы удалили TINYINT, он сохранил бы 1 байт за экземпляр за строку. Единственное, что я вижу с этим, это интерфейсный код, который читает/изменяет таблицу, будет немного более сложным и менее читаемым, поскольку должен интерпретировать NULL/NOT NULL для получения данных по 2 вопросам из одного и того же столбца вместо имея простую связь 1 столбец за вопрос.

В любом случае это может быть сделано, и в любом случае все будет нормально работать. Но какова лучшая практика? Если вы столкнулись с любым методом во время работы с базой данных, разработанной кем-то еще, для вас было бы важно, чтобы они использовали этот метод, а не другой?

Answer 1

Это действительно довольно необязательно. Я хотел бы иметь только один столбец и тестирование для NULL s. В противном случае вам нужно подумать о том, как сохранить два значения в синхронизации.

К сожалению, MySQL не поддерживает ни ограничения, ни вычисленные столбцы, поэтому поддерживать согласованность сложнее, чем должно быть.

С другой стороны, у вас, вероятно, должна быть таблица с одной строкой на пользователя и на вопрос. Это гораздо более гибко, чем добавление вопросов в виде столбцов. Фактически, дизайн опроса является чем-то вроде науки для себя, но вы должны учитывать, что вопросы добавляются, удаляются и изменяются с течением времени.