2012-01-16 4 views
3

Мне нужно хранить разные типы одинакового значения. Значение может представлять DATE, INT, BOOLEAN, DOUBLE и любой другой тип. Мне интересно, возможно ли не использовать несколько таблиц - каждый для разных типов (я полагаю, что это значительно усложнит использование сохраненных значений (главным образом, поиск, фильтрация)). Будет ли это большой дисконт и ухудшение производительности при хранении нескольких столбцов таблицы, в основном значения NULL в строке?(my) База данных SQL - хранение разных типов одинакового значения

Я думаю, таблицы с такими например колоннами, из которых будет заполнен только один столбец значения:

id valueVarchar valueDate valueBoolean valueInt valueDouble 

Если такой подход явно не так, пожалуйста, просветите меня.

Я создаю приложение JSF, используя MySQL (InnoDB) (база данных не является большой проблемой, ее можно изменить при необходимости) и JPA.

редактировать:

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

+2

** Почему ** вам нужно хранить то же значение, что и несколько разных типов - чего вы надеетесь достичь, сделав это? Почему конкретное значение потенциально может иметь несколько разных типов? –

+0

Немного смущает; если вы пытаетесь сделать это из-за различных типов, это одно значение может быть, тогда я бы предложил использовать VarChar; поскольку существуют функции преобразования, которые существуют для преобразования его в другие типы данных. –

+0

@MarkBannister: у меня на голове: у предприятия могут быть приложения/контексты, которые используют разные значения для pi, например. как плавающий и фиксированный десятичный знак. Также возможно различные алгоритмы округления, например. усеченный при 3 д.п., округление банкира до 3 д.п. и т. д. – onedaywhen

ответ

0

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

2

Если вы используете EclipseLink, вы можете использовать @TypeConverter для преобразования любого типа данных в String. Вы также можете иметь два столбца для значения и один для типа значения, вы можете сопоставить это с помощью сопоставления @Transformation.

С помощью общей JPA вы можете преобразовать тип с помощью методов get/set, используя доступ к свойствам.

+0

Спасибо за предложение. Я познакомлюсь с ним. –

+0

Я бы подумал, что оригинальный дизайн OP немного лучше, чем этот. Хранение различных типов данных в одном столбце не является хорошим использованием БД. –

1

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

Для этого есть название: оно называется Entity-Attribute-Value model, или EAV для краткости.

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

Проведено исследование несоответствующей реализации базы данных EAV here.

Одна из наиболее очевидных целей, для которых EAV может использоваться, заключается в сохранении данных объекта из проектов OO в реляционных базах данных. Если вы хотите это использовать, я настоятельно рекомендую вам вместо этого рассмотреть Object-Relational Mapping (ORM для краткости).

Вопросы, связанные с EAV, можно найти на SO, используя тег eav.