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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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