Дизайн базы данных: хранить данные из бумажных форм в базе данных

Question

Вопрос дизайна базы данных для всех вас. У меня есть форма (например, вид бумаги), которая имеет несколько точек входа для данных. Эта форма изменилась, и ожидается, что она изменится с годами. Он превращается в компьютерное приложение, чтобы мы могли, помимо прочего, перестать тратить бумагу. (И второстепенные вещи, такие как хранение всех данных в одном центральном хранилище, к которому можно обращаться, и т. Д.) Я хотел бы сохранить все данные форм в базе данных и сделать их довольно независимыми в отношении изменений.

Первоначально я просто рассматривал каждое поле как строку - и у меня была таблица примерно такая:

FormId int (FK)
FieldName nvarchar(64)
FieldValue nvarchar(128)

... что-то в этом роде. На самом деле это было немного больше 3NFy в том, что FieldName было в другой таблице, связанной с искусственным ключом, так что имена полей не были продублированы повсюду.

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

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

Я мог бы расширить таблицу выше примерно так:

FormId int (FK)
FieldName nvarchar(64)
FieldValueType int -- enum as to which of the columns below are valid (or just let nulls imply that)
FieldValue nvarchar(128)
FieldValueInt int

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

Какой-нибудь совет по StackOverflow? Я использую MSSQL, но это действительно более общий вопрос.

Answer 1

Вы можете иметь отдельную таблицу для каждого типа данных.

т.е. чтобы получить всю форму, вы должны выполнить N-way соединение, используя идентификатор формы, где N - это количество различных типов данных, которые вы поддерживаете (+ возможно, дополнительные в зависимости от информации, которую вы хотите - например, выпадающие значения, вероятно, будут храниться в другой таблице / поиск вашего поля / etc.)

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

Answer 2

Используйте Nulls. Правильный дизайн базы данных - сложная тема; Вы можете преуспеть, чтобы найти хороший справочник и провести некоторое исследование всего этого (я понимаю, , это хорошая книга по этой теме). В общем, это звучит так, как будто вам будет хорошо, если вы начнете с одной таблицы, которая инкапсулирует все поля в вашей форме, а затем проведете ее через процесс нормализации. И да, используйте null и НЕ используйте int для перечисления, какие столбцы имеют допустимые значения; это именно то, для чего нужны нули.

Answer 3

Я бы настоятельно рекомендовал не иметь "общую таблицу", как вы описываете.

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

Просто создайте таблицу (таблицы) со столбцами для полей данных, и если форма не имеет поля, пусть оно будет нулевым.

Или, возможно, даже лучше, иметь «базовую таблицу» (поля в каждой форме) и присваивать обновленным формам имена / номера версий, а также новую таблицу для новых столбцов, добавляемых этой версией, затем использовать синтетический ПК для присоединения этих новых таблиц к вашей базовой таблице.

т.е:.

base table: id(numeric,PK), name, birthday, town

addresstable1: street, number, postal code, country, base_table_id (foreign key)

addresstable2: po box no, po box code, base_table_id (FK)

и т. Д.

Таким образом, вы избегаете множества пустых полей; ваши таблицы не такие широкие (всегда желательно), а ваши записи неявно версионированы, потому что список таблиц, в которых есть записи, принадлежащие записи в вашей базовой таблице, сообщает вам, какие поля была в исходной форме, и, следовательно, какая форма была используется первоначально.

Answer 4

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

Сначала я подумал - какая хорошая идея! Создайте свою собственную систему описания таблиц с учетом совместимости!

Но потом я подумал - я слишком глуп, чтобы делать это самостоятельно. Должна быть система баз данных, способная сделать это.

Итак, я, не будучи экспертом по БД, определю правильные значения по умолчанию для «новых полей» в новых версиях формы. Обработайте проблему совместимости в своей бизнес-логике.