хранение различных типов данных в базе данных (postgresql) - PullRequest
1 голос
/ 18 января 2012

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

Как бы наиболее эффективно хранить эти свойства в реляционной базе данных?

Я прочитал Хранение различных типов значений в базе данных , и я очарован единственным ответом, но я совсем не уверен, что это идеальное решение.Есть ли плюсы / минусы, использующие подход отдельных таблиц к типу по сравнению с другими решениями?Кто-нибудь имеет реальный опыт в этой области, и умы расскажут о лучшем подходе?

Ответы [ 2 ]

3 голосов
/ 18 января 2012

Использовать столбец тип данных текст .

Каждый тип данных в PostgreSQL имеет текстовое представление - иначе простой pg_dump не будет работать. Кроме того, как пользователь будет вводить значение в первую очередь?

У меня было несколько таких случаев уже пару лет. Нет проблем. Вы можете дополнительно сохранить фактический тип данных и при необходимости привести текстовое представление.

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

Вас также может заинтересовать новый тип данных hstore в PostgreSQL 9.0 . (Модуль существует дольше, но в 9.0 он был значительно улучшен.)


Дополнительный ответ на вопрос в комментарии

PostgreSQL чрезвычайно универсален с индексацией. Я бы разрешил случай, подобный тому, который вы упомянули в комментарии, с частичным индексом для выражения :

CREATE INDEX tbl_col_propx_idx ON tbl (cast(col AS int))
WHERE  prop_type_id = 23;  -- 23 signifying "propertyX"

И prop_type_id будет внешним ключом для справочной таблицы (со ссылкой на внешний ключ):

CREATE TABLE prop_type(
   prop_type_id int PRIMARY KEY,
   prop_type text NOT NULL);

prop_type_id также может быть enum типа . Обработка перечислений была значительно улучшена в последней версии.

Тогда такой запрос будет очень быстрым:

SELECT *
FROM   tbl
WHERE  prop_type_id = 23   -- 23 signifying "propertyX"
AND    col::int BETWEEN 50 AND 100

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

1 голос
/ 18 января 2012

Мой предпочтительный способ - это одиночная таблица с ключом и значением, являющимся varchar и / или текстом.

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

Наследование таблиц (но все же с таблицей на тип) могло бы стать еще одним способом, и ИМХО, это жестоко типо-безопасныйсовместимы с концепциями postgres и ORM:

CREATE TABLE key_values(user_id integer references users(id), key varchar(255), type varchar(255), CONSTRAINT UNIQUE(user_id, key));
CREATE TABLE key_values_int(value integer) INHERITS (key_values);
CREATE TABLE key_values_string(value varchar(255)) INHERITS (key_values);
and so on...

Это идеально соответствует JPA.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...