Дизайн таблицы базы данных для хранения ответов «да», «нет» и количественных ответов на вопросы

Question

У меня есть таблица, в которой хранятся ответы на вопросы контрольного списка, где контрольные списки имеют формат yes, no, not applicable, or resolved.

 Table: CHECKLIST_ANSWER
        ATTRIBUTE_ID PK, FK
        CHECKLIST_INSTANCE_ID PK, FK
        TOGGLE_VALUE (1=yes, 2=No, 3=n/a, 4=was a no then it was resolved)
        FAIL_REASON

ATTRIBUTE_ID - это внешний ключ к таблице вопросов, т. Е. Was the part measured within some tolerance?

Теперь я хочу смоделировать контрольный список, в котором будут храниться количественные ответы, например How many incorrect dimensions were found on the drawing?

Я уверен, что могу хранить эти вопросы в той же таблице, что и тип yes / no / naатрибуты, но я могу использовать ту же таблицу для хранения значения количества?Должен ли я добавить новый столбец, скажем QUANTITY_VALUE?И тогда либо QUANTITY_VALUE, либо TOGGLE_VALUE будут равны нулю в зависимости от атрибута.

 Table: CHECKLIST_ANSWER
        ATTRIBUTE_ID PK, FK
        CHECKLIST_INSTANCE_ID PK, FK
        TOGGLE_VALUE (1=yes, 2=No, 3=n/a, 4=was a no then it was resolved)
        QUANTITY_VALUE
        FAIL_REASON

Цель этого приложения базы данных - перевести бумажные и контрольные списки Excel в режиме онлайн и записать их в Oracle, чтобы обеспечить более эффективный сбор метрик и, следовательно, лучшую агрегацию входных данных.Я прошу проблемы в будущем, смешивая два в один стол?Или я должен создать таблицу, CHECKLIST_QTY_ANSWER

Answer 1

Если я правильно понимаю ваш вопрос, вы ищете совет о том, как сохранить новый тип ответов в вашей схеме?

Поскольку это новый тип ответа, вам необходимо обозначить, чтоформат данных теперь отличается от вашего типа ответа y / n / na.Вы можете сделать это, добавив еще одну таблицу CheckListAnswerType и FK в свою таблицу CHECKLIST_ANSWER.

Однако ваш CHECKLIST_INSTANCE_ID может легко указать, что это тип контрольного списка, который следует за определенным ответомшаблон.Я не уверен в том, что в остальной части вашей покупки схемы у вас может быть таблица CHECKLIST_INSTANCE, в которой указан тип ее ответа ...

Ваш TOGGLE_VALUE может следовать числовой схеме для ваших новых типов ответов и супомянутое выше CheckListAnswerType вы можете и должны всегда учитывать это при запросе данных, чтобы убедиться, что вы не выбрали неправильный тип ответа, учитывая контекст вопроса, чтобы вы не получили значение Да при поискеHow many incorrect dimensions were found on the drawing? ответ.

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

TL; DR: Если вы используете тот же тип данных для ответов, тогда вы можете повторно использовать существующую схему (столбец), добавляя путь кскажите ответ или вопрос / ответ, наберите отдельно для точного запроса.Если вы хотите хранить другие типы данных в TOGGLE_VALUE, создайте для этого новые объекты схемы.Не пытайтесь форсировать другие типы данных в текущей схеме, если вы можете избежать этого.Также, если вы сделали это, рассмотрите возможность переименования TOGGLE_VALUE, поскольку оно больше не представляет Toggle.answerValue может лучше соответствовать новому дизайну.

Answer 2

Я не вижу проблем с добавлением нового столбца в существующую таблицу. Я бы включил проверочное ограничение, которое требовало, чтобы либо TOGGLE_VALUE, либо QUANTITY_VALUE было равно нулю (но не оба).

Нет веских причин для создания второй, почти идентичной таблицы, в которой изменяется только один столбец. По моему опыту, это приводит к большему количеству проблем, чем решение с одной таблицей (это практически приглашение использовать динамический SQL).

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

Answer 3

Если у вас много вариантов, вы обычно создаете отдельную таблицу, только с идентификатором и описанием (или именем). Чтобы соединить эти две таблицы, вы вставляете поле в CHECKLIST_ANSWER-Table и определяете его как внешний ключ, который ссылается на id (первичный ключ) новой таблицы, о котором я упоминал первым.

Надеюсь, это понятно:)