|
|
|
Представление номенклатуры
|
|||
|---|---|---|---|
|
#18+
Всем доброго здоровья. Итак имеется следующая проблема. Необходимо хранить в реляционной базе данных список товаров. Эти товары имеют список аттрибутов и их значения. Изначально список аттрибутов не определен. Аттрибуты могут быть сложные и иметь список значений (варианты альтернатив). Рассмотрим пример (все эти товары должны хранится в одной структуре): 1) джинсы. аттрибуты (сложные) размер (46, 48, XL - размеры также должны хранится в отдельной таблице), цвет (синий, темносиний, черный ...), и аттрибуты (просты) на молнии или пуговицах, и т.д.; 2) чайные наборы: аттрибут спискок расцветок (китай, детские ...) Ломаю голову как это все запихнуть в одну структуру, что бы гибко можно было настраивать список аттрибутов и список значений аттрибутов. И еще, что бы пользователю показывать только те значения аттрибутов, которые относятся только к этому аттрибуту. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 09:18 |
|
||
|
Представление номенклатуры
|
|||
|---|---|---|---|
|
#18+
здесь этот вопрос многократно обсуждался... воспользуйтесь поиском.. ну а если в 2-х словах -используйте принцип связи "много-к-много"... С уважением, Petr[@]Chulkov.NET ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 10:06 |
|
||
|
Представление номенклатуры
|
|||
|---|---|---|---|
|
#18+
EAV ищите. Много раз обсуждалось. Здесь на форуме известна также как модель по Тенцеру. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 10:09 |
|
||
|
Представление номенклатуры
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 10:13 |
|
||
|
Представление номенклатуры
|
|||
|---|---|---|---|
|
#18+
ModelREAV ищите. Много раз обсуждалось. Здесь на форуме известна также как модель по Тенцеру. да херня эта - а не модель. Толя тогда или водки паленой перепил, или травы обкурился, для студентов может и "крута" выглядит, в реальной жизни - абсолютно не применимо ни под каким соусом. однозначно забить конечное количество полей. практикой доказано - статично по 32 поля трех типов. на клиенте - рулить видимостью-невидимостью-позициями полей в гриде и контролов на форме: целое - для ссылок плавающее - размеры строка - наименования типология номенклатур. - с описанием подсправочников и форматов наименований, процедур и пр. +разумная избыточность. все хранить в избыточном виде - конечные наименования считать и хранить по формулам. поисковые поля отдельно - 32 штуки. в UpperСase или еще как. первые поисковые поля (часто используемые в поиске) - загнать в составные индексы. остальные по отдельности загнать в компрессированные индексы. запрос анализировать - если есть возможность пользовать составной индекс, то использовать связанные (bind) параметры. если нет - то использовать литеральные параметры - что-бы можно было дать CBO оптимизатору использовать гистограммы (Oracle). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 22:24 |
|
||
|
Представление номенклатуры
|
|||
|---|---|---|---|
|
#18+
grexhide Толя тогда или водки паленой перепил, или травы обкурился, Не он один. Мы тоже пользовали еще дцать лет назад на Clipper, даже не зная ни его статьи ни западного слова EAV. И получалось. grexhide однозначно забить конечное количество полей. практикой доказано - статично по 32 поля трех типов. целое - для ссылок плавающее - размеры строка - наименования 32 наверное многим хватит. А типов маловато будет - еще Даты по крайней мере. grexhide типология номенклатур. - с описанием подсправочников и форматов наименований, процедур и пр. +разумная избыточность. все хранить в избыточном виде - конечные наименования считать и хранить по формулам. поисковые поля отдельно - 32 штуки. в UpperСase или еще как. первые поисковые поля (часто используемые в поиске) - загнать в составные индексы. остальные по отдельности загнать в компрессированные индексы. запрос анализировать - если есть возможность пользовать составной индекс, то использовать связанные (bind) параметры. если нет - то использовать литеральные параметры - что-бы можно было дать CBO оптимизатору использовать гистограммы (Oracle).Вот это уже алхимия, и выйдет ли перестраивать индексы под меняющийся поток запросов дешевле EAV - вопрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2006, 10:25 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33569788&tid=1545394]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
169ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
35ms |
get tp. blocked users: |
1ms |
| others: | 237ms |
| total: | 483ms |

| 0 / 0 |
