SQL - данные опроса, дизайн схемы таблицы для циклических вопросов опроса
a = 1;
alert(!a) // -> false : a is not not defined
alert(!!a) // -> true : a is not not defined
Для !a он проверяет, не определено ли a, а !!a проверяет, определена ли переменная.
!!a совпадает с !(!a). Если определено a, a - true, !a - false, а !!a - true.
2 ответа
Вариант А лучше, даже если вы его сейчас не видите.
Хранение нескольких значений в одной «ячейке» базы данных является ошибкой при любом взгляде на нее (хотя, к сожалению, это очень распространенная ошибка), не говоря уже о том, что это нарушение первой нормальной формы , в которой конкретно говорится что каждый столбец может содержать только одно атомарное значение в каждой строке (хотя исходное правило использует другую терминологию).
Недостатки многочисленны, и некоторые из них являются критическими, в том числе (но не ограничиваясь ими):
- Вы теряете возможность использовать правильный тип данных - два целых, хранящихся вместе, должны храниться как тип данных, отличный от типа int.
- Вы можете потерять возможность проверить, что ваши данные на самом деле верны, или что разные части могут быть преобразованы в правильный тип данных (в настоящее время большинство баз данных поддерживают проверочные ограничения, но не все (Да, MySql, я указывая пальцем на вас!))
- Вы теряете возможность навязывать уникальность каждой части данных в отдельности.
- Вы не можете использовать разные части данных в качестве основы для ограничений внешнего ключа
Список можно продолжать и продолжать - но я думаю, что каждый должен получить картину сейчас - столбец базы данных следует использовать для хранения одного значения для каждой строки - каждый раз.
Первый вариант предпочтительнее, на мой взгляд. Это облегчает поиск ответов на различные вопросы для одного бренда и на один и тот же вопрос по брендам.
Поиск идентификатора вопроса кажется плохой заменой. С одной стороны, это исключает простые отношения внешнего ключа с таблицей questions и таблицей brands. Я большой поклонник явных внешних связей.
Конечно, чтобы сделать эту работу, вам понадобится метод для хранения «нет бренда» или «бренд не имеет отношения». Одним из способов является использование NULL для таких ответов.