Alexey_Gawrilow
Advanced Member | Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
xteam2005
Первый вопрос - какая база?
Второе - вы должны понимать, что это... не совсем правильно..
Если вы идете на осознанную денормализацию и усложнение, тогда возможны варианты.
Всеми сценариями можно пользоваться, взвесив за и против, тк везде вы получите:
- увеличение накладных расходов
- увеличение сложности поиска/обновления информации
- увеличение бардака в данных
1) хранить в поле длинной строки или (c|b)LOB в структурированном виде: xml, json.
- csv не пойдет - потеряете информацию о структуре.
- пойдет, если только хранить будете, и вся обработка средствами приложения.
- на строне сервера БД тоже можно парсить/обновлять, но скажем так, при заметном падении производительности.
2) вынести данные этого столбца в EAV шаблоне.
http://www.sql.ru/forum/833365/eav-eto-vyvorachivanie-relyacionnoy-modeli-naiznanku
http://lmgtfy.com/?q=eav+%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD+site%3Awww.sql.ru
3) для ORACLE есть встроенная поддержка, вложенных в строку таблиц/массивов.
Это сахар, реально она их все также в дочерней таблице(для Nested Tables) или BLOB'е хранит(для) массивов.
Введена эта возможность была одновременно с поддержкой XML и объектных типов в PL/SQL и именно для них.
Из существенных минусов - не все библиотеки доступа поддерживают данные возможности/типы.
Под библиотеками понимается не только Delphi библиотеки - наборы компонент, но и прочие платформы.
А мы должны стараться быть совместимыми. 
4) модные нынче NoSQL - рещения.
Это даже могут быть сразу документные базы.
В общем - думать и обосновывать.
Уменьшение числа сущностей/аттрибутов не является достаточным/существенным условием, и не должно приниматься вами в расчет - это не повод.
Согласно закону сохранения сложности вы просто перенесете ее(сложность) в другое место.
|
