|
|
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Нужно хранить данные о контрагентах. Часть атрибутов (например название, адрес, телефон) - существует всегда, но также нужно дать возможность пользователю (администратору системы) определять свой набор атрибутов для контрагента. Два варианта: 1. Постоянные атрибуты хранить все вместе в одной таблице, где каждый атрибут - столбец. Для пользовательских атрибутов определить две таблицы: перечень_атрибутов(id,название_атрибута); данные(контрагент_id,атрибут_id,данные); 2. Абсолютно все атрибуты хранить в двух вышеуказанных таблицах. В первом случае невозможно одним нормальным запросом (без извратов) выбрать все атрибуты. Зато во втором случае сложнее делать запросы с выборкой по нескольким атрибутам. Как это сделано у вас или как бы вы это сделали ?! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2005, 20:22 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Будут ли осуществлятся выборки по атрибутам которые сделал пользователь? Если нет, то вполне может хватить поля "Примечание". Пусть пишут туда все, что хотят. Если да, то я применяю способ 1. Проблемы с "разворачиванием" по горизонтали решаю на клиенте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2005, 21:15 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Cat2Будут ли осуществлятся выборки по атрибутам которые сделал пользователь? Если нет, то вполне может хватить поля "Примечание". Пусть пишут туда все, что хотят. Нет, одно поле точно не катит. Дело в том, что по данным из таблицы контрагенты создается документ с реквизитами контрагента. Суть создания документа в том, что имя атрибута вида %[Количество_машин]% заменяется на значение этого атрибута у конкретного контрагента. Кроме того, в далеком будущем планирую сделать создание пользовательских фильтров для выборки, в том числе, по пользовательским атрибутам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2005, 22:34 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Ugnich Anton Количество атрибутов - конечно. Не лучше ли на этапе проектирования выявит ВСЕ нужные атрибуты и занести в таблицу полями? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2005, 22:43 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Cat2Ugnich Anton Количество атрибутов - конечно. Не лучше ли на этапе проектирования выявит ВСЕ нужные атрибуты и занести в таблицу полями? Ха ! :) Если бы все было так просто, я бы не спрашивал. Система пишется не под конкретного заказчика и даже не под какую-либо отрасль промышленности/народного хозяйства. Поэтому я никак не могу знать, какие атрибуты может захотеть добавить пользователь (админ) системы. Все-таки больше склоняюсь ко второму варианту, потому как все атрибуты хранятся по единому образу и подобию. Что же касается сложности выборки по многим атрибутам, то эту проблему прийдется решать так или иначе. А там уже одним атрибутом больше, одним меньше... Как считаете ? Можно согласиться ?! :) З.Ы. Маленький анонс: все труды по этой теме собираюсь выложить в открытом виде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2005, 23:10 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Ugnich Anton . Ну Вы замахнулись ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2005, 00:00 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Cat2Ugnich Anton . Ну Вы замахнулись Сочту за комплимент. :) Но все же, возвращаясь к subj. Есть ли у приведенной выше схемы какие-либо явные недостатки ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2005, 20:36 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
> 2. Абсолютно все атрибуты хранить в двух вышеуказанных таблицах. Это вообще единственно приемлемый вариант. Потому как: 1. позволяет поддерживать локализацию; 2. позволяет регистрировать особенности (языковые, национальные и пр.) атрибутов; 3. позволяет поддерживать версионность и хронологию изменений; 4. позволяет поддерживать ограничение доступа. > Что же касается сложности выборки по многим атрибутам, то эту проблему прийдется решать так или иначе. А в чем здесь, по-Вашему, сложность? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2005, 21:14 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
guest_20040621> 2. Абсолютно все атрибуты хранить в двух вышеуказанных таблицах. Это вообще единственно приемлемый вариант. Потому как: ... Единственно приемлемый... но нерабочий вариант :) Сложность с фильтрацией, отчетностью, агегатными фунциями, проблемы при вставке-изменении данных. И главное скорость... В таком случае я бы смотрел в сторону ООБД ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 12:41 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Estets смотреть можно куда угодно - вот будет ли толк? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 12:52 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
заметки бездельника - реализация "в лоб" Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Если показать все данные на одной таблице: Код: plaintext 1. 2. 3. 4. Q1: фильтрация Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Q2: получение данных Код: plaintext 1. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Q3: агрегирование Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Итого, как мне кажется, все не так чтобы аж совсем просто (ну, а кому щас легко?), но особых-то сложностей нет Не думаю, что в ООБД эдакий изврат проканал бы проще и на порядки быстрее. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 14:00 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
funikovyuri Estets смотреть можно куда угодно - вот будет ли толк? Честно говоря я имел ввиду наличие некоторого гимороя как в использовании ООБД так и в попытках написать решение " на все случаи жизни ". См. примеры любезно предоставленные нам " дураг с инецеативой ". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 15:39 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Что же касается сложности выборки по многим атрибутам, то эту проблему прийдется решать так или иначе. А в чем здесь, по-Вашему, сложность? Все познается в сравнении. Один SELECT или четыре-пять, есть ведь разница ?! :) Но это так, к слову. В общем, выбираю второй вариант. Всем спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 15:42 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Ugnich Anton guest_20040621> Что же касается сложности выборки по многим атрибутам, то эту проблему прийдется решать так или иначе. А в чем здесь, по-Вашему, сложность? Все познается в сравнении. Один SELECT или четыре-пять, есть ведь разница ?! :) Но это так, к слову. В общем, выбираю второй вариант. Всем спасибо! На Вашем месте я бы сделал пилотный проект, и посмотрел насколько сложно и насколько быстро возможна обработка данных, я думаю множество вопросов сами по себе отпадут... Но еще раз могу сазать свое мнение три раза джойнить одну таблицу что бы собрать ФИО это несколько странно. А проблемы со вторым вариантом могут быть такие: для предприятия обычно указываются по крайней мере два адреса (юридический и почтовый), а может быть и несколько если предприятие имеет отделения, представительства. Очень желательно что бы адреса соответствовали КЛАДР (особенно для физических лиц) а эту уже почти 10 атрибутов. Лицо может иметь несколько расчетных счетов в банках, опять это не один атрибут а несколько наборов. И т.д.... Если вопрос касается только контрагентов, то это еще пол беды, их редко бывает больше 1000 (если конечно Вы пишете не для СберБанка или МТС), но обычно аналогичный вопрос возникает и по поводу номенклатуры товаров и остальных сущностей БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 16:12 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Раньше только Лисоводы лезли во все дыры, предлагая Fox-решения как панацею. А теперь еще и фанаты ООБД суют свой нос куда попало. Правда, в отличии от Лисоводов они не могут представить ни одного конкретного решения. Я скоро начну любить Лисоводов. Они хотя бы делают работающие базы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 17:20 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Я проблему с атрибутами решил так, (убил двух зайцев) Администратор или суперпользователь определяет набор артибутов объекта и перегенерит таблицу. Все это просто и наглядно. Пользователь может и не знать что это таблица. Соотвественно атрибуты являются метаданными для построения пользовательских запросов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 17:20 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Вот похожая ситуация (контрагенты или товары - суть одна) . Но есть одна проблема. Помогите решить. Вообщем говоря: Посмотрите вложение, там картинка с фрагментом из базы. Таблицы: Products - собственно товары ProductGroups - товарные группы с наследованием/иерархией (по ParentID) GroupParams - здесь заводим типы параметров для каждой товарной группы (опять же с наследованием - ParentID) ProductParams - собственно здесь хранятся значения параметров для каждого товара. Далее: Возникла необходимость, чтобы тип параметра (в ProductGroups) имел свои опции, т.е. состоял из набора данных Создаем таблицу ParamOptions И вот теперь не могу решить, как лучше (по науке) привязать эту таблицу к ProductParams , чтобы хранить в ней значение из ParamOptions ? Если просто создать дополнительный столбец в ProductParams и сослаться на него из ParamOptions ? А если решать по другому, то как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 17:44 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Old NickАдминистратор или суперпользователь определяет набор артибутов объекта и перегенерит таблицу. При добавлении нового атрибута к объекту (типу документа) автоматом добавляется поле в таблице (причем нужного типа, в отличии от подхода №2), так работают большинство универсальных систем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 17:47 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
EstetsНа Вашем месте я бы сделал пилотный проект, и посмотрел насколько сложно и насколько быстро возможна обработка данных, я думаю множество вопросов сами по себе отпадут... Но еще раз могу сазать свое мнение три раза джойнить одну таблицу что бы собрать ФИО это несколько странно. Уже. :) 8000 контрагентов, примерно 10 атрибутов. Вот только работают с этой базой всего 3 оператора и самое сложное действие (кроме обычных выборок для интерфейса) - поиск по одному из атрибутов. Пока претензий нет никаких. Что касается расчетных счетов, для этого дела выделил отдельную таблицу. Для того, чтобы хранить номер счета, bank_id, currency_id. Насчет адресов: если возникнет реальная потребность с ними много работать, думаю, можно будет сделать что-то похожее. А до тех пор, пока адрес - это обычная информация для, например, документов, будет так, как сейчас. Old NickАдминистратор или суперпользователь определяет набор артибутов объекта и перегенерит таблицу. Все это просто и наглядно. Пользователь может и не знать что это таблица. Соотвественно атрибуты являются метаданными для построения пользовательских запросов ALTER TABLE ? :) Я об этом думал, но мне показалось слишком экстремальным. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 17:50 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Ugnich Anton wrote: > Estets > На Вашем месте я бы сделал пилотный проект, и посмотрел насколько сложно > и насколько быстро возможна обработка данных, я думаю множество вопросов > сами по себе отпадут... Но еще раз могу сазать свое мнение *три* раза > джойнить одну таблицу что бы собрать ФИО это несколько странно. ~500.000 контрагентов, 31 аттрибут, ~50 операторов. даже не жюжжить. Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 18:05 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Ugnich Anton 8000 контрагентов, примерно 10 атрибутов. Вот только работают с этой базой всего 3 оператора и самое сложное действие (кроме обычных выборок для интерфейса) - поиск по одному из атрибутов. Гм, а чем тогда хуже таблица из 10 полей? Такой подход имеет смысл только если написан полностью универсальный интерфейс, когда пользователь может ввести в настройке новый атрибут, напимер "Код ОКПО", и система автоматом покажет эту колонку в списке, позволит сортировать и фильтровать по этому полю, включать это поле в отчетность. Если для добавления атрибута требуется вмешательство администратора в серверную или клиентскую часть, то смысла в этом я не вижу. Тогда Ugnich AntonALTER TABLE ? :) очень даже оправданный подход, позволяющий (если конечно позволяет клиентская часть) автоматом генерить списки на клиенте, с сортировкой и фильтрацией. Упростить или автоматизировать создание форм для ввода. Подлючать отчетные системы типа БизнесОбжектс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 18:21 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
locky ~500.000 контрагентов, 31 аттрибут, ~50 операторов. даже не жюжжить. А если не секрет, как вы решили вопрос с типми атрибутов? Все в строке или три поля datetime, money, varchar(255)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 18:26 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Для фанатов экстремальной универсализации - возможен еще и гибридный подход - в течение некоторого времени система работает по варианту 2, накапливая список всех возможных атрибутов - а потом переходит на схему ALTER TABLE, соответсвенно оптимизируя запросы :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 18:31 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
Ugnich Anton EstetsНа Вашем месте я бы сделал пилотный проект, и посмотрел насколько сложно и насколько быстро возможна обработка данных, я думаю множество вопросов сами по себе отпадут... Но еще раз могу сазать свое мнение три раза джойнить одну таблицу что бы собрать ФИО это несколько странно. Уже. :) 8000 контрагентов, примерно 10 атрибутов. Вот только работают с этой базой всего 3 оператора и самое сложное действие (кроме обычных выборок для интерфейса) - поиск по одному из атрибутов. Пока претензий нет никаких. Что касается расчетных счетов, для этого дела выделил отдельную таблицу. Для того, чтобы хранить номер счета, bank_id, currency_id. Насчет адресов: если возникнет реальная потребность с ними много работать, думаю, можно будет сделать что-то похожее. А до тех пор, пока адрес - это обычная информация для, например, документов, будет так, как сейчас. Old NickАдминистратор или суперпользователь определяет набор артибутов объекта и перегенерит таблицу. Все это просто и наглядно. Пользователь может и не знать что это таблица. Соотвественно атрибуты являются метаданными для построения пользовательских запросов ALTER TABLE ? :) Я об этом думал, но мне показалось слишком экстремальным. :) не ALTER TABLE, а sp_rename 'tablename', '_old_tablename' create tablename ( ... ) insert tablename ( ... ) select ... from _old_tablename ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 18:32 |
|
||
|
Хранение атрибутов сущности - как лучше ?
|
|||
|---|---|---|---|
|
#18+
EstetsГм, а чем тогда хуже таблица из 10 полей? Такой подход имеет смысл только если написан полностью универсальный интерфейс, когда пользователь может ввести в настройке новый атрибут, напимер "Код ОКПО", и система автоматом покажет эту колонку в списке, позволит сортировать и фильтровать по этому полю, включать это поле в отчетность. Именно универсальный интерфейс ! :) Я уже говорил, что пишу это не под конкретного заказчика. Захотелось сегодня хранить данные, например, о дне рождения фирмы-контрагента (не важно), юзер добавил поле и везде, где вводится/выводится информация, это поле автоматом показывается. Пользователь (не админ) может добавлять/удалять атрибуты, причем очень легко. Самая вкуснятина - вывод на печать. Есть шаблон документа, в котором есть слова, например, %[День рождения фирмы]%. И система автоматом заменяет в тексте это название атрибута на значение. С варинтом "ALTER TABLE" это было бы сложнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2005, 18:33 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33193327&tid=1542732]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
149ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
66ms |
get tp. blocked users: |
1ms |
| others: | 245ms |
| total: | 500ms |

| 0 / 0 |
