Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Хранение атрибутов сущности - как лучше ? / 25 сообщений из 40, страница 1 из 2
30.07.2005, 20:22
    #33192949
Ugnich Anton
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
Нужно хранить данные о контрагентах. Часть атрибутов (например название, адрес, телефон) - существует всегда, но также нужно дать возможность пользователю (администратору системы) определять свой набор атрибутов для контрагента.
Два варианта:
1. Постоянные атрибуты хранить все вместе в одной таблице, где каждый атрибут - столбец. Для пользовательских атрибутов определить две таблицы:
перечень_атрибутов(id,название_атрибута);
данные(контрагент_id,атрибут_id,данные);
2. Абсолютно все атрибуты хранить в двух вышеуказанных таблицах.

В первом случае невозможно одним нормальным запросом (без извратов) выбрать все атрибуты. Зато во втором случае сложнее делать запросы с выборкой по нескольким атрибутам.

Как это сделано у вас или как бы вы это сделали ?!
...
Рейтинг: 0 / 0
30.07.2005, 21:15
    #33192958
Cat2
Модератор форума
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
Будут ли осуществлятся выборки по атрибутам которые сделал пользователь? Если нет, то вполне может хватить поля "Примечание". Пусть пишут туда все, что хотят.
Если да, то я применяю способ 1. Проблемы с "разворачиванием" по горизонтали решаю на клиенте.
...
Рейтинг: 0 / 0
30.07.2005, 22:34
    #33192975
Ugnich Anton
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
Cat2Будут ли осуществлятся выборки по атрибутам которые сделал пользователь? Если нет, то вполне может хватить поля "Примечание". Пусть пишут туда все, что хотят.
Нет, одно поле точно не катит. Дело в том, что по данным из таблицы контрагенты создается документ с реквизитами контрагента. Суть создания документа в том, что имя атрибута вида %[Количество_машин]% заменяется на значение этого атрибута у конкретного контрагента.
Кроме того, в далеком будущем планирую сделать создание пользовательских фильтров для выборки, в том числе, по пользовательским атрибутам.
...
Рейтинг: 0 / 0
30.07.2005, 22:43
    #33192977
Cat2
Модератор форума
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
Ugnich Anton Количество атрибутов - конечно. Не лучше ли на этапе проектирования выявит ВСЕ нужные атрибуты и занести в таблицу полями?
...
Рейтинг: 0 / 0
30.07.2005, 23:10
    #33192988
Ugnich Anton
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
Cat2Ugnich Anton Количество атрибутов - конечно. Не лучше ли на этапе проектирования выявит ВСЕ нужные атрибуты и занести в таблицу полями?
Ха ! :) Если бы все было так просто, я бы не спрашивал.
Система пишется не под конкретного заказчика и даже не под какую-либо отрасль промышленности/народного хозяйства. Поэтому я никак не могу знать, какие атрибуты может захотеть добавить пользователь (админ) системы.

Все-таки больше склоняюсь ко второму варианту, потому как все атрибуты хранятся по единому образу и подобию. Что же касается сложности выборки по многим атрибутам, то эту проблему прийдется решать так или иначе. А там уже одним атрибутом больше, одним меньше...
Как считаете ? Можно согласиться ?! :)

З.Ы. Маленький анонс: все труды по этой теме собираюсь выложить в открытом виде.
...
Рейтинг: 0 / 0
31.07.2005, 00:00
    #33193000
Cat2
Модератор форума
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
Ugnich Anton . Ну Вы замахнулись
...
Рейтинг: 0 / 0
31.07.2005, 20:36
    #33193327
Ugnich Anton
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
Cat2Ugnich Anton . Ну Вы замахнулись
Сочту за комплимент. :)
Но все же, возвращаясь к subj. Есть ли у приведенной выше схемы какие-либо явные недостатки ?
...
Рейтинг: 0 / 0
31.07.2005, 21:14
    #33193349
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
> 2. Абсолютно все атрибуты хранить в двух вышеуказанных таблицах.

Это вообще единственно приемлемый вариант. Потому как:
1. позволяет поддерживать локализацию;
2. позволяет регистрировать особенности (языковые, национальные и пр.) атрибутов;
3. позволяет поддерживать версионность и хронологию изменений;
4. позволяет поддерживать ограничение доступа.

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

А в чем здесь, по-Вашему, сложность?
...
Рейтинг: 0 / 0
01.08.2005, 12:41
    #33194121
Estets
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
guest_20040621> 2. Абсолютно все атрибуты хранить в двух вышеуказанных таблицах.
Это вообще единственно приемлемый вариант. Потому как:
...
Единственно приемлемый... но нерабочий вариант :)
Сложность с фильтрацией, отчетностью, агегатными фунциями, проблемы при вставке-изменении данных. И главное скорость...

В таком случае я бы смотрел в сторону ООБД ;)
...
Рейтинг: 0 / 0
01.08.2005, 12:52
    #33194149
funikovyuri
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
Estets

смотреть можно куда угодно - вот будет ли толк?
...
Рейтинг: 0 / 0
01.08.2005, 14:00
    #33194358
Хранение атрибутов сущности - как лучше ?
заметки бездельника - реализация "в лоб"

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
 att_list(att_id, att_name) -- перечень_атрибутов(id,название_атрибута)
 agent_info(agent_id, att_id, data) -- данные(контрагент_id,атрибут_id,данные)
-- типа примерные данные
 att_list( 1 , 'name')
 att_list( 2 , 'phone')
 att_list( 3 , 'address')
 att_list( 4 , 'country')
 att_list( 5 , 'sex')

 agent_info( 1 ,  1 , 'John Smith')
 agent_info( 1 ,  2 , '000')
 agent_info( 1 ,  3 , 'The Matrix')
 agent_info( 1 ,  4 , 'USA')

 agent_info( 2 ,  1 , 'John Dow')
 agent_info( 2 ,  2 , '555-4545')
 agent_info( 2 ,  4 , 'USA')
 agent_info( 2 ,  5 , 'male')

Если показать все данные на одной таблице:
Код: plaintext
1.
2.
3.
4.
 ID name        phone    address     country  sex
 ----------------------------------------------------
  2 : John Smith   000       The Matrix  USA      /UNUSED/
  3 : John Dow     555 - 4545  /UNUSED/    USA      male

Q1: фильтрация
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
-- фильтр по агентам, эквивалент запроса к таблице, где есть все возможные поля:
-- select agent_id from agent_universal_info where "phone" like '555%' and "country" = 'USA' and not "sex" = 'female' or "name" like 'John%'
 select agent_id from agent_info where att_id =  3  and data like '555%'
 intersect -- AND
 select agent_id from agent_info where att_id =  4  and data = 'USA'
 except  -- AND NOT
 select agent_id from agent_info where att_id =  5  and data = 'female'
 union   -- OR
 select agent_id from agent_info where att_id =  1  and data like 'John%'

Q2: получение данных
Код: plaintext
1.
 select agent_id , att_id, att_data from agent_info where agent_id in ( Q1 )
Q2-1: Отображение - на совести приложения-клиента:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
 class ReportTable {
  void SetAttList(attList) - список всех возможных полей
  void AddRecord(agentId, attID,data) - вызывает agentList.SetAgentData(agentId, attId, data)
  DataType[] getAgentData(id) - данные о данном агенте или null, если такого еще не было
  DataType[] AddAgent(id) - добавление агента
  void SetAgentData(agent_id, att_id, data) { // заносит в массив данных агента значение атрибута
        DataType[] ag_data=getAgentData(agent_id)
        if(ag_data==null) ag_data=AddAgent(id)
        ag_data[att_id].data=data
        ag_data[att_id].used=true
        glob_data_use[att_id]=true // массив использованных атрибутов
  }
  void ShowReport(ADisplayClass display) - показать сводную таблицу, исключая неиспользованные ни одним агентом атрибуты
}

Q3: агрегирование
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
-- select "country", max("item_count"), sum("year_income") from agent_info where :CRITERIA: group by "country"
--
-- att_list(6, 'item_count')
-- att_list(7, 'year_income')
select country, max(item_count), sum(year_income)
from
 (select r1.agent_id as agent_id, r1.data as country, int(r2.data) as item_count, float(r3.data) as year_income
  from agent_info r1
  join agent_info r2 using (agent_id)
  join agent_info r3 using (agent_id)
  where r1.att_id =  4  and r2.att_id =  6  and r3.att_id =  7  and r1.agent_id in ( CRITERIA_LIKE_Q1 )
 ) as fictive_table
group by country

Итого, как мне кажется, все не так чтобы аж совсем просто (ну, а кому щас легко?), но особых-то сложностей нет
Не думаю, что в ООБД эдакий изврат проканал бы проще и на порядки быстрее. :)
...
Рейтинг: 0 / 0
01.08.2005, 15:39
    #33194633
Estets
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
funikovyuri Estets
смотреть можно куда угодно - вот будет ли толк?
Честно говоря я имел ввиду наличие некоторого гимороя как в использовании ООБД так и в попытках написать решение " на все случаи жизни ". См. примеры любезно предоставленные нам " дураг с инецеативой ".
...
Рейтинг: 0 / 0
01.08.2005, 15:42
    #33194640
Ugnich Anton
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
guest_20040621> Что же касается сложности выборки по многим атрибутам, то эту проблему прийдется решать так или иначе.

А в чем здесь, по-Вашему, сложность?
Все познается в сравнении. Один SELECT или четыре-пять, есть ведь разница ?! :) Но это так, к слову.

В общем, выбираю второй вариант. Всем спасибо!
...
Рейтинг: 0 / 0
01.08.2005, 16:12
    #33194734
Estets
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
Ugnich Anton guest_20040621> Что же касается сложности выборки по многим атрибутам, то эту проблему прийдется решать так или иначе.

А в чем здесь, по-Вашему, сложность?
Все познается в сравнении. Один SELECT или четыре-пять, есть ведь разница ?! :) Но это так, к слову.

В общем, выбираю второй вариант. Всем спасибо!
На Вашем месте я бы сделал пилотный проект, и посмотрел насколько сложно и насколько быстро возможна обработка данных, я думаю множество вопросов сами по себе отпадут... Но еще раз могу сазать свое мнение три раза джойнить одну таблицу что бы собрать ФИО это несколько странно.

А проблемы со вторым вариантом могут быть такие: для предприятия обычно указываются по крайней мере два адреса (юридический и почтовый), а может быть и несколько если предприятие имеет отделения, представительства. Очень желательно что бы адреса соответствовали КЛАДР (особенно для физических лиц) а эту уже почти 10 атрибутов. Лицо может иметь несколько расчетных счетов в банках, опять это не один атрибут а несколько наборов. И т.д....

Если вопрос касается только контрагентов, то это еще пол беды, их редко бывает больше 1000 (если конечно Вы пишете не для СберБанка или МТС), но обычно аналогичный вопрос возникает и по поводу номенклатуры товаров и остальных сущностей БД.
...
Рейтинг: 0 / 0
01.08.2005, 17:20
    #33194902
Cat2
Модератор форума
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
Раньше только Лисоводы лезли во все дыры, предлагая Fox-решения как панацею. А теперь еще и фанаты ООБД суют свой нос куда попало. Правда, в отличии от Лисоводов они не могут представить ни одного конкретного решения. Я скоро начну любить Лисоводов. Они хотя бы делают работающие базы.
...
Рейтинг: 0 / 0
01.08.2005, 17:20
    #33194903
Old Nick
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
Я проблему с атрибутами решил так, (убил двух зайцев)

Администратор или суперпользователь определяет набор артибутов объекта и перегенерит таблицу. Все это просто и наглядно. Пользователь может и не знать что это таблица. Соотвественно атрибуты являются метаданными для построения пользовательских запросов
...
Рейтинг: 0 / 0
01.08.2005, 17:44
    #33194964
Gorden
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
Вот похожая ситуация (контрагенты или товары - суть одна) . Но есть одна проблема. Помогите решить. Вообщем говоря:

Посмотрите вложение, там картинка с фрагментом из базы.

Таблицы:
Products - собственно товары
ProductGroups - товарные группы с наследованием/иерархией (по ParentID)
GroupParams - здесь заводим типы параметров для каждой товарной группы (опять же с наследованием - ParentID)
ProductParams - собственно здесь хранятся значения параметров для каждого товара.

Далее: Возникла необходимость, чтобы тип параметра (в ProductGroups) имел свои опции, т.е. состоял из набора данных Создаем таблицу ParamOptions

И вот теперь не могу решить, как лучше (по науке) привязать эту таблицу к ProductParams , чтобы хранить в ней значение из ParamOptions ? Если просто создать дополнительный столбец в ProductParams и сослаться на него из ParamOptions ?

А если решать по другому, то как?
...
Рейтинг: 0 / 0
01.08.2005, 17:47
    #33194981
Estets
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
Old NickАдминистратор или суперпользователь определяет набор артибутов объекта и перегенерит таблицу.
При добавлении нового атрибута к объекту (типу документа) автоматом добавляется поле в таблице (причем нужного типа, в отличии от подхода №2), так работают большинство универсальных систем.
...
Рейтинг: 0 / 0
01.08.2005, 17:50
    #33194987
Ugnich Anton
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
EstetsНа Вашем месте я бы сделал пилотный проект, и посмотрел насколько сложно и насколько быстро возможна обработка данных, я думаю множество вопросов сами по себе отпадут... Но еще раз могу сазать свое мнение три раза джойнить одну таблицу что бы собрать ФИО это несколько странно.
Уже. :)
8000 контрагентов, примерно 10 атрибутов. Вот только работают с этой базой всего 3 оператора и самое сложное действие (кроме обычных выборок для интерфейса) - поиск по одному из атрибутов.
Пока претензий нет никаких.

Что касается расчетных счетов, для этого дела выделил отдельную таблицу. Для того, чтобы хранить номер счета, bank_id, currency_id.
Насчет адресов: если возникнет реальная потребность с ними много работать, думаю, можно будет сделать что-то похожее. А до тех пор, пока адрес - это обычная информация для, например, документов, будет так, как сейчас.

Old NickАдминистратор или суперпользователь определяет набор артибутов объекта и перегенерит таблицу. Все это просто и наглядно. Пользователь может и не знать что это таблица. Соотвественно атрибуты являются метаданными для построения пользовательских запросов
ALTER TABLE ? :)
Я об этом думал, но мне показалось слишком экстремальным. :)
...
Рейтинг: 0 / 0
01.08.2005, 18:05
    #33195029
locky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
Ugnich Anton wrote:
> Estets
> На Вашем месте я бы сделал пилотный проект, и посмотрел насколько сложно
> и насколько быстро возможна обработка данных, я думаю множество вопросов
> сами по себе отпадут... Но еще раз могу сазать свое мнение *три* раза
> джойнить одну таблицу что бы собрать ФИО это несколько странно.

~500.000 контрагентов, 31 аттрибут, ~50 операторов. даже не жюжжить.
Posted via ActualForum NNTP Server 1.2
...
Рейтинг: 0 / 0
01.08.2005, 18:21
    #33195066
Estets
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
Ugnich Anton
8000 контрагентов, примерно 10 атрибутов. Вот только работают с этой базой всего 3 оператора и самое сложное действие (кроме обычных выборок для интерфейса) - поиск по одному из атрибутов.
Гм, а чем тогда хуже таблица из 10 полей?
Такой подход имеет смысл только если написан полностью универсальный интерфейс, когда пользователь может ввести в настройке новый атрибут, напимер "Код ОКПО", и система автоматом покажет эту колонку в списке, позволит сортировать и фильтровать по этому полю, включать это поле в отчетность. Если для добавления атрибута требуется вмешательство администратора в серверную или клиентскую часть, то смысла в этом я не вижу. Тогда
Ugnich AntonALTER TABLE ? :)
очень даже оправданный подход, позволяющий (если конечно позволяет клиентская часть) автоматом генерить списки на клиенте, с сортировкой и фильтрацией. Упростить или автоматизировать создание форм для ввода. Подлючать отчетные системы типа БизнесОбжектс.
...
Рейтинг: 0 / 0
01.08.2005, 18:26
    #33195075
Estets
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
locky
~500.000 контрагентов, 31 аттрибут, ~50 операторов. даже не жюжжить.

А если не секрет, как вы решили вопрос с типми атрибутов? Все в строке или три поля datetime, money, varchar(255)?
...
Рейтинг: 0 / 0
01.08.2005, 18:31
    #33195081
Хранение атрибутов сущности - как лучше ?
Для фанатов экстремальной универсализации - возможен еще и гибридный подход - в течение некоторого времени система работает по варианту 2, накапливая список всех возможных атрибутов - а потом переходит на схему ALTER TABLE, соответсвенно оптимизируя запросы :)
...
Рейтинг: 0 / 0
01.08.2005, 18:32
    #33195086
Old Nick
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
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
...
Рейтинг: 0 / 0
01.08.2005, 18:33
    #33195093
Ugnich Anton
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хранение атрибутов сущности - как лучше ?
EstetsГм, а чем тогда хуже таблица из 10 полей?
Такой подход имеет смысл только если написан полностью универсальный интерфейс, когда пользователь может ввести в настройке новый атрибут, напимер "Код ОКПО", и система автоматом покажет эту колонку в списке, позволит сортировать и фильтровать по этому полю, включать это поле в отчетность.
Именно универсальный интерфейс ! :) Я уже говорил, что пишу это не под конкретного заказчика.
Захотелось сегодня хранить данные, например, о дне рождения фирмы-контрагента (не важно), юзер добавил поле и везде, где вводится/выводится информация, это поле автоматом показывается. Пользователь (не админ) может добавлять/удалять атрибуты, причем очень легко.
Самая вкуснятина - вывод на печать. Есть шаблон документа, в котором есть слова, например, %[День рождения фирмы]%. И система автоматом заменяет в тексте это название атрибута на значение. С варинтом "ALTER TABLE" это было бы сложнее.
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Хранение атрибутов сущности - как лучше ? / 25 сообщений из 40, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]