Дилемма дизайна таблицы базы данных, много флажков?

Question

Я хочу начать с Спасибо, ребята, вы были добры ко мне.

Я сразу перейду к вопросу.

Иметь таблицу с более чем 400 столбцами - это плохо?

У меня есть веб-формы, которые в основном состоят из вопросов, требующих ответов на флажки. Общее количество флажков может быть до 400, если не больше.

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

Так что я где-то читал, что некоторые люди используют функцию сериализации, чтобы сохранить группу флажков в виде текста в столбце.

Я просто хочу знать, что это был бы лучший способ сохранить эти флажки.

О, и еще немного информации, я буду использовать cakephp orm с этими таблицами.

Еще раз спасибо заранее.

Моя база данных выглядит примерно так

Таблица: пациенты, Таблица: admitForm, Таблица: SomeOtherFOrm

каждая таблица формы будет иметь PatientId

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

поэтому я прочитал кое-что, где сериализация флажков для вопроса была бы хорошей идеей

Так что я спрашиваю, это был бы хороший подход.

Answer 1

Для вопросов с несколькими вариантами просто добавьте другую таблицу.

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

Вот мое представление о схеме.

Answer 2

Обычно 400 столбцов означает, что ваши данные можно нормализовать лучше и разбить на несколько таблиц.400 столбцов могут быть подходящими, в зависимости от варианта использования.Примером, где это может быть уместно, является то, что вам нужны эти поля в каждом отдельном запросе И вам нужно фильтровать записи, используя эти столбцы (т. Е. Использовать их в предложении WHERE) ... в этом случае SQL-соединения, вероятно, будут более дорогимичем наличие малонаселенной "широкой" таблицы.

Если вам никогда не нужно использовать SQL для фильтрации записей, основанных на этих "флажках" (я предполагаю, что это булевы / крошечные значения типа "тип"), тогдасериализация является правильным подходом.Я бы пошел по этому пути, если бы мне нужно было использовать значения флажков большую часть времени, когда я запрашиваю таблицу, но не нужно использовать их в предложении WHERE.

Если вам не нужны эти значения флажков,или вам нужно лишь небольшое их подмножество, при большинстве запросов к вашей таблице, вероятно, вам следует разбить вашу таблицу на несколько таблиц.Один из подходов заключается в том, чтобы иметь таблицу со значениями флажков (id, record_id, checkbox_name, checkbox_value), где record_id - это id вашей записи первичной таблицы.Это подразумевает связь «один ко многим» между вашими первичными записями и значениями ваших флажков.

Answer 3

== Редактировать # 3 == Обновлена ​​ERD с возможностью хранения ответов в свободной форме, а также привязана Patient_reponse_option к таблице question_option_link, так что ответ пациента будет сохранен с правильным контекстом опции (мы знаем, на какой вопрос ответ тоже). Я скоро отправлю несколько запросов.

== Редактировать # 2 ==

Обновлен ERD с данными формы

== Редактировать # 1 ==

Короткий ответ на ваш вопрос - нет, 400 столбцов - неправильный подход. В качестве альтернативы, проверьте следующую схему:

== Оригинал ==

Согласно вашему недавнему редактированию, вы захотите включить сводную таблицу. Сводная таблица разбивает отношение M: M между «пациентами» и «вариантами», например, у многих пациентов может быть много вариантов. Чтобы это работало, вам не нужна таблица с 400 столбцами, вам просто нужно включить вышеупомянутую сводную таблицу.

Пример схемы:

// patient table
tableName: patient
id: int(11), autoincrement, unsigned, not null, primary key
name_first: varchar(100), not null
name_last: varshar(100), not null

// Options table
tableName: option
id: int(11), autoincrement, unsigned, not null, primary key
name: varchar(100), not null, unique key

// pivot table
tableName: patient_option_link
id: int(11), autoincrement, unsigned, not null, primary key
patient_id: Foreign key to patient (`id`) table
option_id: Foreign key to option (`id`) table

С помощью этой схемы вы можете иметь любое количество «опций», не добавляя новый столбец в таблицу пациентов. Который, если у вас есть большое количество строк, разрушит вашу базу данных, если вам когда-нибудь понадобится выполнить команду alter table add column.

Я добавил идентификатор в сводную таблицу, поэтому, если вам когда-нибудь понадобится обрабатывать отдельные строки, с ними будет проще работать, против необходимости знать значения Patient_id и option_id.

Answer 4

Я думаю, я бы разделил это на 3 таблицы.Одна таблица, представляющая любую сущность, отвечает на вопросы.Вторая таблица, содержащая сами вопросы.Наконец, третья таблица соединений, которая будет заполняться первичным ключом первой таблицы и идентификатором вопроса из второй таблицы всякий раз, когда сущность из первой таблицы устанавливает флажок для этого вопроса.