powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / изменяемый набор полей, в каждой таблице
25 сообщений из 123, страница 1 из 5
изменяемый набор полей, в каждой таблице
    #35493015
lightspeed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Приветствую,

столкнулся с одной задачей. И что-бы не заниматься велосипедостроением, хотел-бы сначала проконсультироваться. )
В соответствие с бизнес-логикой, у компании есть набор предоставляемых ей сервисов. Пусть сервис будет объектом. Данный набор объектов заранее не определен. Т.е. он может изменяться.
Далее, у каждого объекта есть набор аттрибутов, который тоже не определен, т.е. может постоянно изменяться. Вопрос в правильном построении архитектуры базы данных/приложения, реализующих данную структуру?
Добавлю, что в лоб реализовывать набор таблиц для каждого объекта не считаю правильным. Тем более, что таких объектов намечается больше сотни, для начала. А потом еще больше..
И т.к. аттрибуты объекта постоянно меняются, то делать 'alter table add/drop/rename' - тоже не есть хорошее решение..

Вот, как вижу это я. Есть некоторый набор сервисов(объектов), заранее не определенный, предоставляемый компанией. Упрощенно,
Код: plaintext
1.
2.
3.
4.
create table services_directory (
service_id          number not null,
service_name     varchar2( 100 ) not null
);
Так-же есть набор аттрибутов, так-же заранее не определенный, (адрес, время работы, телефон, наименование, и т.д.), у каждого аттрибута есть жестко привязанный тип аттрибута, его длинна. Т.е.,
Код: plaintext
1.
2.
3.
4.
5.
6.
create table attr_directory(
attr_id              number not null,
attr_name         varchar2( 50 ) not null,
attr_type          number not null,                -- attr types defined in dictionary
attr_len            number default  0  not null     -- attr length
);
необходимо реализовать следующее:
1. матрицу привязки аттрибута к объекту (в данном случае это просто)
2. где и как должна содержаться сама информация? Т.е. в данном случае надо создавать таблицу для каждого аттрибута (с именем attr_name, для примера)? С типом и длинной поля указанного в attr_type/attr_len?
3. добавление/редактирование/удаление информации из аттрибутов для данного объекта.
4. Запросы, реализующие считывание информации по аттрибутам для данного объекта.

Реализуема ли даннах схема? И если да, то можно-ли на данном этапе проследить ее подводные камни? Возможно есть другие алгоритмы построения таких структур.
Со своей стороны замечу, что будут запросы по каждому аттрибуту объекта. А это значит, что содержать все аттрибуты объекта в едином бинарном поле - не рентабельно. Не хочу на стороне приложения, разбирать их и проверять условия запроса.. Все, максимально должно быть в backend'e.

В общем, прошу помочь в реализации алгоритма реализующего данную архитектуру.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35493186
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lightspeedстолкнулся с одной задачей. И что-бы не заниматься велосипедостроением, хотел-бы сначала проконсультироваться. )
В соответствие с бизнес-логикой, у компании есть набор предоставляемых ей сервисов. Пусть сервис будет объектом. Данный набор объектов заранее не определен. Т.е. он может изменяться.
Далее, у каждого объекта есть набор аттрибутов, который тоже не определен, т.е. может постоянно изменяться. Вопрос в правильном построении архитектуры базы данных/приложения, реализующих данную структуру?
Добавлю, что в лоб реализовывать набор таблиц для каждого объекта не считаю правильным. Тем более, что таких объектов намечается больше сотни, для начала. А потом еще больше..
И т.к. аттрибуты объекта постоянно меняются, то делать 'alter table add/drop/rename' - тоже не есть хорошее решение..Здесь многое зависит от конкретики задачи.

Есть "универсальный" механизм, который это все может реализовать - это EAV.
Но прежде чем его реализовывать - надо сильно подумать - а стоит ли оно такого гемороя?

Более простые схемы можно предложить только ели более подробно опишите задачу.
Что такое сервисы, какие они бывают, как часто они будут меняться, какая информация хранится в атрибутах...
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35493262
_Pero123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вы информационную систему проектируете или компонент для программиста (оркестровка сервисов)?
Бизнес-сущность "Сервис"? Странно.
автор у компании есть набор предоставляемых ей сервисов
что нужно автоматизировать?
- учёт сервисов?
- учёт клиентов потребляющих сервисы?
- аналитику производства сервисов?

ЗЫ. Как правильно сказали, если надо хранить "незнамо что" то берут EAV, но "врагу не пожелаю".
Проект устареет раньше чем система будет написана.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35493287
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_Pero123ЗЫ. Как правильно сказали, если надо хранить "незнамо что" то берут EAV, но "врагу не пожелаю".
Проект устареет раньше чем система будет написана.Не факт. Ограниченное применение EAV иногда бывает полезным. Т.е. если не валить все в EAV, а например использовать динамические характеристики. А уж использовать или нет эту концепцию - нужно конкретно смотреть исходя из требований и ситуации.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35493407
m0nk3y
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я заранее извиняюсь, мб я не совсем понял проблему топикстартера, но по-моему если взять положим XML файл, то реализация сущностей с переменным составом полей не представляет особой сложности:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
<firma>
 <service>
   <attr>
   </attr>
   <attr>
   </attr>
   <attr>
   </attr>
     .
 </service>
 <service>
   <attr>
   </attr>
     .
 </service>
</firma>
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35494051
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lightspeedСо своей стороны замечу, что будут запросы по каждому аттрибуту объекта. Если так, то предлагаемая вами схема (EAV) загнется очень быстро. Вряд ли она даже миллион объектов потянет с приемлимыми характеристиками. Да и реализовывать собственный "язык запросов" вместо хорошо знакомого всем sql...

lightspeedИ т.к. аттрибуты объекта постоянно меняются, то делать 'alter table add/drop/rename' - тоже не есть хорошее решение..А вот тут надо понять, что вы вкладываете в слова "постоянно меняются". Если есть некий классификатор типов и все объекты одного типа имеют одинаковый набор атрибутов, то не вижу особых трудностей с alter table.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35494054
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
m0nk3yЯ заранее извиняюсь, мб я не совсем понял проблему топикстартера, но по-моему если взять положим XML файл, то реализация сущностей с переменным составом полей не представляет особой сложности:Автор писал, что ему необходим поиск по значениям атрибутов и сделал верный вывод, что "содержать все аттрибуты объекта в едином бинарном поле - не рентабельно".
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35494074
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bogdanov Andrey lightspeedСо своей стороны замечу, что будут запросы по каждому аттрибуту объекта. Если так, то предлагаемая вами схема (EAV) загнется очень быстро.

Индекс по значению аттрибутов спасет автора
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35494113
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bogdanov Andrey lightspeedИ т.к. аттрибуты объекта постоянно меняются, то делать 'alter table add/drop/rename' - тоже не есть хорошее решение..А вот тут надо понять, что вы вкладываете в слова "постоянно меняются". Если есть некий классификатор типов и все объекты одного типа имеют одинаковый набор атрибутов, то не вижу особых трудностей с alter table.Я бы поставил вопрос "как часто меняются" и насколько кардинально меняются.

Если 1 раз в год - то это можно сделать в рамках усовершенствования системы.

Сам подход, когда требуется делать ALTER TABLE на лету - несколько коробит.

Видел еще в некоторых системах такой подход:
В таблице для хранения атрибутов заводятся поля:
INT_FIELD_01, INT_FIELD_02, INT_FIELD_03, INT_FIELD_04 ....
STR_FIELD_01, STR_FIELD_02, STR_FIELD_03, STR_FIELD_04 ....
DATE_FIELD_01, DATE_FIELD_02, DATE_FIELD_03, DATE_FIELD_04 ....
итп.

А далее в метаданных лежат настройки какое поле чему соответствует.
Например, для Серивиса-1, поле "INT_FIELD_01" называется "Кол-во клапанов".
Для "Сервиса-2", то же поле "INT_FIELD_01" называется "Кол-во сотрудников".
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35494131
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_мод Bogdanov AndreyЕсли так, то предлагаемая вами схема (EAV) загнется очень быстро.Индекс по значению аттрибутов спасет автораБезумству храбрых поем мы песню .
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35494472
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BelyСам подход, когда требуется делать ALTER TABLE на лету - несколько коробит.А чем alter table хуже insert into attr_dictionary? Естевственно, если атрибуты каждый пять минут добавляются, то alter не лучшее решение, ну а если "раз в неделю", то никаких проблем.

_модИндекс по значению аттрибутов спасет автораПредлагаю самостоятельно провести простенький тест. Берем например, атрибуты "фамилия", "имя", "отчество", "дата рождения" ну и еще десяток по желанию, загоняем миллион лиц и пытаемся найти клиента по фио+дата рождения (типовой вариант идентитфикации физлиц). Смотрим на то как нам помогает индекс (не забудем, что в среднем на одну дату рождения приходится до сотни лиц из миллиона, ну и на одно имя тоже немало).
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35494507
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bogdanov Andreyпытаемся найти клиента по фио+дата рождения (типовой вариант идентитфикации физлиц).
4 раза прямой доступ по индексу. Впрочем я не настаиваю - каждая задача имеет свое решение - надо пробовать.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35494683
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_мод4 раза прямой доступ по индексу. Впрочем я не настаиваю - каждая задача имеет свое решение - надо пробовать.Вы в самом деле попробуйте. В теории-то оно все гладко.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35494721
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Для совсем ленивых привожу тестик - индексы на свой вкус сами добавьте:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
SQL> create table tst_people
   2   (
   3   PeopleId  integer,
   4   FirstName  varchar2( 30 ),
   5   LastName   varchar2( 30 ),
   6   MiddleName varchar2( 30 )
   7   );

Таблица создана.

SQL> create table tst_peopleattr
   2   (
   3   PeopleId  integer,
   4   AttrName  varchar2( 30 ),
   5   AttrValue varchar2( 30 )
   6   );

Таблица создана.

SQL> begin
   2   for i in  1 .. 1000000  loop
   3      insert into tst_people(PeopleId,FirstName,LastName,MiddleName)
   4       values(i,mod(i, 1100 ), mod(i, 1202 ),mod(i, 1330 ));
   5      insert into tst_peopleattr(PeopleId,AttrName,AttrValue)
   6       values(i,'First',mod(i, 1100 ));
   7      insert into tst_peopleattr(PeopleId,AttrName,AttrValue)
   8       values(i,'Last',mod(i, 1202 ));
   9      insert into tst_peopleattr(PeopleId,AttrName,AttrValue)
  10       values(i,'Middle',mod(i, 1330 ));
  11   end loop;
  12   end;
  13   /

Процедура PL/SQL успешно завершена.

SQL> commit;

Фиксация обновлений завершена.

SQL> analyze table tst_people compute statistics;

Таблица проанализирована.

SQL> analyze table tst_peopleattr compute statistics;

Таблица проанализирована.

SQL> set timing on
SQL> begin
   2   for i in  1 .. 10  loop
   3     for rec in (select * from tst_people where FirstName =  10 *i and LastName =  10 *i and MiddleName =  10 *i) loop
   4        null;
   5     end loop;
   6   end loop;
   7   end;
   8   /

Процедура PL/SQL успешно завершена.

Затрач.время:  00 : 00 : 02 . 62 
SQL> begin
   2   for i in  1 .. 10  loop
   3     for rec in (select a1.peopleid from tst_peopleattr a1,tst_peopleattr a2,tst_peopleattr a3
   4    where a1.AttrName = 'First' and a1.AttrValue =  10 *i
   5    and a2.AttrName = 'Last' and a2.AttrValue =  10 *i
   6    and a3.AttrName = 'Middle' and a3.AttrValue =  10 *i
   7    and a1.PeopleId = a2.PeopleId and a1.PeopleId = a3.PeopleId) loop
   8        null;
   9     end loop;
  10   end loop;
  11   end;
  12   /

Процедура PL/SQL успешно завершена.

Затрач.время:  00 : 00 : 11 . 31 
Аттрибутов - кот наплакал. Тормоза уже заметны. И если добавление новых колонок в обычную таблицу никак на времени поиска не скажется, то вот во втором случае...
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35494766
Фотография shelsoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lightspeedВ соответствие с бизнес-логикой, у компании есть набор предоставляемых ей сервисов. Пусть сервис будет объектом.
1) Сервис->["Опросили интерфейс"]->Получили формализованное описание положили в базу (так например мы работает по протоколам XML-RPC/SOAP
2) Для подобных задач по построению БД с измененяемым набором полей я бы предложил разумно разделить данные на статическую (то что одинаково у всех объектов) и динамическую часть (индивидуальных характеристики) и хранил бы их в неком формализованном виде например XML, тем более что например в ORACLE & MSSQL есть более-менее нормальные механизмы по работе с ним


______________________________________________________
Давайте считать обступившее нас со всех строн коричневое море шоколадным
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35494811
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shelsoft2) Для подобных задач по построению БД с измененяемым набором полей я бы предложил разумно разделить данные на статическую (то что одинаково у всех объектов) и динамическую часть (индивидуальных характеристики) и хранил бы их в неком формализованном виде например XML, тем более что например в ORACLE & MSSQL есть более-менее нормальные механизмы по работе с ним Включая XQuery?
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35495835
Фотография shelsoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АБВключая XQuery?
На без рыбьи сам раком встанешь не забывая о быстродействии и продуктивности



______________________________________________________
Давайте считать обступившее нас со всех строн коричневое море шоколадным
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35495836
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я просто хотел воспользоваться случаем и узнать какие именно средства работы с XML эта парочка сейчас способна предоставить в контексте предложенного решения.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35495846
Фотография shelsoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АБэта парочка сейчас
1) Уточните ... дабы это ответ явно не аналитика
2) С точки зрения специалиста объясните анекдот про "цветной телевизор" не удаляясь от теории РСУБД

))


______________________________________________________
Давайте считать обступившее нас со всех строн коричневое море шоколадным
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35495899
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Послушайте, давайте обойдемся без иносказаний, гипербол, метафор, афоризмов и анекдотов. Я задал простой технический вопрос, хотя вероятно был слишком лаконичен. По моему мнению, для запросов к XML есть хороший язык под названием XQuery, но я не знаю поддерживается ли он в упомянутых СУБД.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35495938
Фотография shelsoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АБобойдемся без иносказаний, гипербол, метафор, афоризмов и анекдотов.
1) Разработчик ПО в любой роли должен знать возможности продуктов занимающих значительное положение на рынке в области обработки структурированных и неструктурированных данных
2) XQuery одна из возможностей работы с неструктурированными данными в реляционных СУБД
3) Чистый оффтоп "Улыбайтесь обо вся дурость на свете делается с серьезным лицом"


______________________________________________________
Давайте считать обступившее нас со всех строн коричневое море шоколадным
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35496151
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АБ shelsoft2) Для подобных задач по построению БД с измененяемым набором полей я бы предложил разумно разделить данные на статическую (то что одинаково у всех объектов) и динамическую часть (индивидуальных характеристики) и хранил бы их в неком формализованном виде например XML, тем более что например в ORACLE & MSSQL есть более-менее нормальные механизмы по работе с ним Включая XQuery?
включая, но
IMHO
дорого, сырая технология для РСУБД, медленно, рановато на данном этапе.

ЗЫ. Топик смахивает на "Проектирование БД"
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35497213
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123 АБВключая XQuery?
включая, но
IMHO
дорого, сырая технология для РСУБД, медленно, рановато на данном этапе. Спасибо! Дорого в смысле денег или трудоемкости?
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35497472
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ну, я одно от другого не отделяю.
Некоторые мысли:
- разделение атрибутов на часто изменяемые и редко... будет искуственным, т.к. с точки зрения бизнеса этого разделения нет. Соответственно все запросы и представление данных должно это искусственное разделение обратно объединять.
- пока в РСУБД XML - инородное образование (есть специальные БД для работы с XML на уровне ядра Системы-ядра БД)
- отсюда много ограничений на объединение данных из XML и НЕxml
- XML - это только ТРУБОПРОВОД между разными источниками данных, но никак не хранилище их (на данном этапе)
- если проектировать на EAV, то под данную структуру БД нет ни одних библиотечных компонентов и библиотек (IMHO). Всё пишется очень долго "с нуля". БД становится импотентом и понятия не имеет что у неё хранится. Вся работа за неё по контролю за непротиворечивостью данных пишется программистом.
- это будет плата за требование бизнеса: "у нас всё меняется и нет никаких ограничений". Может это от жадности или непрофессионализма?
- хотя есть для EAV (всё в 3-х таблицах) области автоматизации и они подробно освещены в "Проектирование БД".

ЗЫ. Мне вот непонятен сам тезис: "В соответствие с бизнес-логикой, у компании есть набор предоставляемых ей сервисов. Пусть сервис будет объектом."

Почему я всегда против, чтобы бизнес-аналитик был программистом. :)



______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35497597
lightspeed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Petro123:
Это не от жадности или не профессионализма. Проект - пилотный. Соответственно, все изменения, в том числе и бизнес требований, и требований по дизайну и архитектуре, будут проводиться на нем. Далее, уже на основе этого пилотного проекта (с уже оформленной необходимым образом архитектурой БД и приложения) будет создаваться законченная его версия.
Поэтому:
1. Не будет миллионов записей. Только не в пилотнике. Максимально - будут тысячи, ну может десятки тысяч. Все остальное - уже в рабочей версии.
2. При изменениях объектов и аттрибутов в законченной версии, будет производиться версионнинг, (как написал Bely: в рамках усовершенствования проекта). Тем более, что в дальнейшем, кол-во изменений по объектам и аттрибутам будет уменьшаться. Т.е., система в будет стабилизироваться.
К сожалению, общее с бизнес-аналитиками проходит довольно сложно, поэтому, дизайн на данный момент - EAV. Хотя я понимаю, что не смотря на свою универсальность и гибкость, это довольно медленный инструмент. Буду строить индексы.. (

З.Ы.
Мне проще думать о бизнес-сервисе, как о некотором абстрактном объекте с некоторыми аттрибутами. А рентабельность, производительность и мощность данного бизнес-сервиса, пусть считают бизнес-аналитики..
...
Рейтинг: 0 / 0
25 сообщений из 123, страница 1 из 5
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / изменяемый набор полей, в каждой таблице
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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