Лучший способ хранить данные в базе данных, когда Вы не знаете тип
У меня есть таблица в моей базе данных, которая представляет поля данных в пользовательской форме. DataField дает некоторое представление, какого вида из управления он должен быть представлен с, и какой тип значения он должен взять. Упрощенный можно сказать, что у меня есть 2 объекта в этой таблице - Текстовое поле, берущее любую строку и Текстовое поле, только берущее числа.
Теперь мне сохранили различные значения в отдельной таблице, сославшись на определение поля данных. Что лучший способ состоит в том, чтобы сохранить значение данных здесь, когда тип отличается?
Одно возможное решение состоит в том, чтобы иметь таблицу FieldValue, содержат одно поле на возможный тип значения. Теперь это, конечно, было бы избыточно, но по крайней мере я сохраню значение в его правильной форме - упрощение запросов позже.
FieldValue
----------
Id
DataFieldId
IntValue
DoubleValue
BoolValue
DataValue
..
Другая возможность просто хранит все как Строку и бросает это в запросах. Я использую .NET с NHibernate, и я вижу, что по крайней мере здесь существует Проекции. Бросок, который может использоваться, чтобы бросить, например, представить в виде строки к интервалу в запросе.
Так или иначе в этих двух решениях я должен знать, какой тип использовать при выполнении запроса, но я буду знать, что от DataField, так, чтобы не была проблема.
Так или иначе; я не думаю, что любое из этих решений звучит хорошим. Они? Или существует ли лучший путь?
4 ответа
Третьего «волшебного» варианта не существует: ваша конкретная ситуация определяет, как вы хотите действовать.
По моему опыту, решение, состоящее только из строк, имеет смысл с такими вещами, как настройки приложения. Обычно мне не нужно использовать такие данные в запросах напрямую, поэтому меня не сильно беспокоит их строковая форма.
Я не уверен, но похоже, что вы расширяете объект с помощью настраиваемых атрибутов, что похоже на то, что в какой-то момент вы можете захотеть произвести некоторую обработку в базе данных. В этом случае вы также можете использовать подход с несколькими столбцами и заполнить только столбец правильного типа. Это не будет красиво, но может упростить запросы.
Как я уже сказал, это зависит от того, какие запросы вам нужно запускать, какая производительность вам нужна и т. Д.
Если у вас есть только 2 текстовых поля, в которые пользователь может вводить значения, и это будет либо строка, либо число, вам действительно нужно уметь различать int и double, не можете ли вы просто сохранить все это как подходящий числовой тип (в зависимости от БД). В результате у вас будет всего 2 разных типа, а затем возможным решением будет иметь 2 таблицы, по одной для каждого из двух типов.
В целом, однако, когда я вижу, что трудно понять, какой тип данных что-то будет, я начинаю беспокоиться, что проект пытается стать универсальным, что имеет тенденцию становиться довольно беспорядочным.
Заимствовав идею из многопользовательского хранилища данных, вы можете использовать идею «Пара имен», как описано в MSDN . Мне почему-то кажется, что эта статья будет полезнее, если не считать отмеченного конкретного раздела.
Фактически, чтобы сделать это масштабируемое решение, вам нужно будет определить типы данных для вашей пользовательской формы, используя таблицу метаданных, в которой вы определяете фактический тип данных, которые вы хотите сохранить (например, bool, text, int , дата и время). Вы также можете рассмотреть возможность сохранения типа .Net, поскольку это может помочь вам, когда дело доходит до проверки ввода и т. Д. Другие детали, которые также могут быть сохранены, - это имена полей, которые вы ожидаете, чтобы они отображались на ваша индивидуальная форма. Используя этот подход, вы создаете настраиваемую форму на основе сохраненных метаданных.
Я успешно использовал этот подход, и он отлично работает. В качестве дополнения мы также использовали таблицу метаданных, чтобы определить, предоставляется ли ожидаемое значение для настраиваемого поля пользователем (например, имя, дата рождения) или предварительно определенное системное значение в раскрывающемся списке (например, список городов, стран ). Для поддержки этого у нас есть дополнительная таблица, которая содержит параметры для списка, который связан с таблицей метаданных.
Прежде чем высказать свое мнение ... Я бы сказал, что вам, возможно, придется вернуться к доске ER. Я полагаю, что CustomForm имеет много полей и что эти поля имеют разные типы (текст, данные, возможно, даже поведение и стиль), а не обобщают концепцию Поле , возможно, вместо этого стоит подумать о создании одной таблицы для каждого типа поля. Например. DateField, UserNameField и т. Д. Это сделает тип значения ровно одним ненулевым столбцом с правильным типом. Я также готов поспорить, что это упростит ваш код (меньше условий для проверки, база данных дает вам всю информацию).
Тем не менее, вы не сможете вернуться к доске ER или могут быть основополагающие веские причины для применяя подход с несколькими столбцами на тип. Вот несколько плюсов и минусов такого подхода.
Плюсы
- все в одной таблице, могут оказаться быстрее (хотя помните, что корень всего зла ...)
Минусы
- БД не может обеспечить указание не более одного значения (дополнительный код для проверки исключений)
- БД не может обеспечить, чтобы хотя бы одно не было NULL (дополнительный код для проверки значений FieldValues без какого-либо значения)
- добавление поддержки нового типа данных требует изменения всех существующих данных (добавления значения NULL в столбцы).
Если вы застряли с CustomForm > Поле -> FieldValue , я бы предложил создать одну таблицу для каждого FieldValue . например
IntFieldValue
-------------
Id
DataFieldId
Value
DecimalFieldValue
-------------
Id
DataFieldId
Decimal
DateFieldValue
-------------
Id
DataFieldId
Date
С помощью вышесказанного вы все еще можете создать представление, которое выбирает из приведенных выше таблиц. Представление может быть создано так, чтобы предлагать один столбец для каждого типа значения и гарантировать , что один и только один из них не равен NULL. Это также легче расширить (добавить новую таблицу, изменить представление, но это не требует обновления каких-либо существующих данных с помощью нулевых значений для столбца нового типа).