powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / изменяемый набор полей, в каждой таблице
123 сообщений из 123, показаны все 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
изменяемый набор полей, в каждой таблице
    #35497612
lightspeed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
З.З.Ы. Кстати, про XML речи вообще не идет. Согласен с предыдущем оратором (Petro123) - это не есть лучшая среда для хранения данных. На мой взгляд - это наиболее универсальная среда для их передачи.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35497768
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lightspeed1. Не будет миллионов записей. Только не в пилотнике. Максимально - будут тысячи, ну может десятки тысяч. Все остальное - уже в рабочей версии.Вы думаете, что если система загнется после того как вы ее доделаете - будет лучше?
Мне казалось, что проектируют для того, чтобы система НЕ загнулась.
Ни до начала использования, ни в процессе эксплуатации.

По поводу количества - один из критических показателей системы - сколько она может держать в себе данных и обрабатывать.
Вам (или бизнесаналитикам) надо понимать сколько данных в систему будет загружено при старте + сколько ориентировочно будет создаваться в течении года.

Для разных объемов данных - разные решения допустимы.

lightspeed2. При изменениях объектов и аттрибутов в законченной версии, будет производиться версионнинг, (как написал Bely: в рамках усовершенствования проекта). Тем более, что в дальнейшем, кол-во изменений по объектам и аттрибутам будет уменьшаться. Т.е., система в будет стабилизироваться.Сам бог велел сделать стабильное ядро со статическими атрибутами + дополнительные атрибуты в EAV (те, которые появились новые).

При появлении критических атрибутов - добавление полей в таблицу + переделка форм.

lightspeedК сожалению, общее с бизнес-аналитиками проходит довольно сложно, поэтому, дизайн на данный момент - EAV. Хотя я понимаю, что не смотря на свою универсальность и гибкость, это довольно медленный инструмент. Буду строить индексы.. (Как только встанет задача "Загрузить пару миллионов объектов из старой системы" - придется строить не индексы, а планы по смене работы...

Так что, возможно, вам проще будет сделать EAV структуру, внести в нее пару миллионов записей (тестовых), подготовить отчет по этой структуре и показать бизнес-аналитикам как он быстро будет работать.
Вдруг, они тоже окажутся заинтересованы в том, чтобы система не закончилась на пилотном проекте :)
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35497877
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
аффтар!
Вы не поняли, что у EAV низкая скорость - не самый главный минус?

EAV будет дороже в разы! А если захотите вернуться, то придётся переписать всё на клиенте и всё на сервере.
Спросите хотя бы у программистов (у меня был не пилотный проект на нём, а реальный).


Bely +1

Удачи Вам!

ЗЫ. Кажется мне, что из за плохого контакта с бизнес-аналитиками, в угоду кажущейся простоте (добавления нового атрибута в БД), архитектор Системы может принять неверное решение.
По крайней мере, доводов от бизнеса в том что атрибуты меняются каждый день - я не увидел.

______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35497888
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну я б не сказал что это ТАК уж дорого. Мы это делали еще когда слова такого не было EAV. И даже с наследованием атрибутов. И тоже не в пилоте, а в промышленной системе, причем тиражируемой. Работает у клиентов годами уже.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35498006
Фотография shelsoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123разделение атрибутов на часто изменяемые и редко... будет искуственным, т.к. с точки зрения бизнеса этого разделения нет. Соответственно все запросы и представление данных должно это искусственное разделение обратно объединять.

1) Сударь мой разделение атрибутов "на часто изменяемые и редко" действительно искуственно
2) А вот на "значимые и незначимые" давно и успешно применяются (см ПрАце.Ру, Яндекс-Маркет и т.д. - хАчу вот такой теливизор только желтый")
3) Разделение атрибутов на "значимые и незначимые" возможно только после анализа - какой объем записей мы должны будем обработать после поиска по "значимым" атрибутам и хороше выполненной методики по вводу в базу всех данных
4) То что сказано выше достаточно сильно упирается в предметную область в которой реализуется проект


______________________________________________________
Давайте считать обступившее нас со всех строн коричневое море шоколадным
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35498064
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АБНу я б не сказал что это ТАК уж дорого....
Не дорого, потому что в ИТ индустрии нет чётких расценок на те или иные виды работ. В общей куче договора что EAV, что ORM, что "работаем с любой БД" - всё едино.

ну, можно зайти с друго бока, с низу...
- время разработки бизнес формы по ВИ в Delphi, на одну форму уходит 1 человеко день.
- при разработке используются связка:

ПровайдерДанных от MS MDAC -----> библиотека Delphi ПоставщикДанных (ADO) ----> визуализация данных и редактирование(DevExpress)

Все они (в том числе сам сервер), не понимают EAV. Все они оперируют объектом TField у которого есть тип данных. Если тип данных текст, то будет курсор. Если числовой то вызовется калькулятор и т.д.

Скока будет делать программист данную форму, если из БД идёт:

field1 field21 232 1.43 02.02.2008
если расшифровать:

field1 field2рост 23 (это из другой таблицы значит "высокий")ширина 1.4аудит 2 фер.2008
в одном поле сразу все типы данных.

Программист может всё, только кому это надо... (с)
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35498728
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123Скока будет делать программист данную форму, если из БД идёт... Мы сделали одну форму, на которую дополнительные атрибуты выводятся столбиком: атрибут-значение. С этой формой пришлось повозиться, но после этого прошлись по имеющимся формам и просто в каждой добавили переход на форму атрибутов. Это как вы понимаете минутное дело. Не самый лучший интерфейс? Согласен. Но достаточно хороший - пользователи претензий не предъявляют. Кроме этого понятно пришлось кое-что сделать в отчетности, но тоже - не смертельно.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35498757
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АБНе самый лучший интерфейс? Согласен.Вместо инструмента вы им дали конструктор.
Выучили бы их языку SQL, может вобще интерфейс писать не пришлось...

По поводу не жалуются - я видел организации, у которых стояла глюкавая система учета документов, поэтому им приходилось документ сперва регистрировать в тетрадке (записывали на бумаге), потом в отдельном экселевом файле, а потом уже в учетной системе.
И ничего - тоже люди не жаловались...
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35498818
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bely АБНе самый лучший интерфейс? Согласен.Вместо инструмента вы им дали конструктор.
Выучили бы их языку SQL, может вобще интерфейс писать не пришлось...

По поводу не жалуются - я видел организации, у которых стояла глюкавая система учета документов, поэтому им приходилось документ сперва регистрировать в тетрадке (записывали на бумаге), потом в отдельном экселевом файле, а потом уже в учетной системе.
И ничего - тоже люди не жаловались... Не надо инсинуаций - конструкторы, SQL и тетрадки тут не при чем. Пользователь видит строго типизированные атрибуты, заданные для выбранного объекта на уровне метаданных. Просто расположены они на экране не в оптимаотном с точки зрения эстетики и эргономики порядке, а в столбик один под другим.

Смысл использования EAV ведь не в том, чтобы избавиться от необходимости расширять схему БД. Что толку, если при добавлении атрибута придется переписывать все формы? Что схема, что формы в конечном итоге сводятся к трудозатратам.

В нашей реализации можно свободно добавлять атрибуты, не трогая ни схему, ни формы. Спросите у пользователя, что он предпочтет - пожертвовать качеством интерфейса или избавиться от зависимости от программистов, от затрат на переделки и от задержек между возникновения необходимости в появлении нового атрибута и возможностью работы с ним.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499025
lightspeed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 АБ и Bely: С удовольствием читаю ваш диалог. И вы знаете Bely, я согласен с АБ. Пользователи выбирают динамическое изменение данных. И их не волнует что внутренняя архитектура страдает (в некотором смысле) от этого. Вот ответ от бизнеса: "..меня не волнует что у тебя и как там работает. Мне нужен интерфейс позволяющий динамически изменять необходимые параметры объектов в соответствие с заданными критериями.."
В общем, я получил карт-бланш на flexible user-oriented interface.. Теперь осталось сделать архитектуру по-возможности, еще гибкой и дешевой в разработке.. Мда..
Кстати, с финансами проблем нет, в том смысле что бюджет на построение пилотника довольно большой. Т.е., если для ускорения работы системы понадобится кластер и распараллеливание запросов - это все будет..
И все же, как правильно заметил Bely, не хотелось бы выкинуть изделие на свалку после создания пилотика. Поэтому, опять возвращаюсь к архитектуре системы. И продолжаю следить за топиком..
Кстати, вариант однажды предложенный Bely:
Bely
..Видел еще в некоторых системах такой подход:
В таблице для хранения атрибутов заводятся поля:
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 ....
итп..

тоже имеет право на жизнь, и рассматривается в данное время..
Есть еще такой вариант как "EAV-наполовину":
Т.е., создаются объекты, создаются аттрибуты, которые "привязываются" к этим объектам. А далее, по ним создается таблица. Имя которой - есть имя объекта, а названия полей - есть названия аттрибутов привязанных к данному объекту. Далее, при добавлении нового аттрибута - делаем alter table add.. Но, никогда не удаляем поля таблицы объекта. Просто удаляем соответствующую запись из матрицы объект-аттрибут. Соответственно, если аттрибут для данного объекта восстановлен, получаем обратно все данные по нему.
В данном алгоритме, проблема возникает в получении данных из этих таблиц-объектов. Т.к., сначала мы должны получить имена полей из таблицы аттрибутов, для данного объекта(-ов), и лишь потом создавать sql для данной таблицы.. Если кто-то проследил за моей мыслью, буду рад пообщаться..
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499047
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lightspeed...создаются объекты, создаются аттрибуты, которые "привязываются" к этим объектам. А далее, по ним создается таблица... Не это ли примерно реализовано в 1С?
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499398
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АБПользователь видит строго типизированные атрибуты, заданные для выбранного объекта на уровне метаданных. Просто расположены они на экране не в оптимаотном с точки зрения эстетики и эргономики порядке, а в столбик один под другим.Вот у нас в форме организации - 27 основных видимых полей + с десяток - системных, еще есть возможность добавлять признаки из классификатора (по типу EAV) - нормальная ситуация, если таких признаков - 5-6, еще телефоны... 3-4 телефона, причем телефоны тоже разбиты и структурированы (код, телефон, тип телефона, extention-примечание).
Еще к организации пристыкованы люди - 3-4 человка в среднем (есть и по 20-30 человек ворганизации). У каждого человека: Фамилия, Имя, Отчество, Пол, Персональный телефон, Долджность (по классификатору - 3 поля), день рождения, Дата последнего контакта с человеком.

Я насчитал (без детализации телефонов и персон) - на каждую организацию: около 45 строк атрибутов.

И всю эту информацию человек должен увидеть, понять что к чему, сделать какие-то действия и обработать. Такие формы (как вы написали) применимы только для простых задач.
А в 45 строках абсолютно разнородной информации - человек просто потеряется.

Представлени EAV хорошо для описаний в интернет магазинах
В обработке данных - это будет просто смерть.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499445
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АБ lightspeed...создаются объекты, создаются аттрибуты, которые "привязываются" к этим объектам. А далее, по ним создается таблица... Не это ли примерно реализовано в 1С?
+1
либо ORM - маппинг объектов-класов в РСУБД.

10 раз отмерь, а потом программируй. Ведь "пилотник"можно делать на каждом уровне.

Я вот тут не увидел бизнес-логику при хранении данных.
У ас просто учётная система? Учесть(сохранить) изменяющиеся атрибуты?
Если атрибут добавить так легко, то откуда появится код обслуги данного атрибута? Тоже вручную будете городить в триггере на 1млн.записей атрибутов НА ОДНУ таблицу.
Там подводных камней масса. Я бы внятного ТЗ от "бизнесменов" попросил. Или концепции на 3-х страницах.
Потом они так-же и скажут: "а нам всё равно как вы это ТУДА засунете".
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499495
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BelyА в 45 строках абсолютно разнородной информации - человек просто потеряется. Вы бы еще сделки в эту кучу добавили и спецификации по ним - тогда не 45, а 450 строк получится. Организация - это один объект со своими атрибутами, контакты - другой, сделка - третий; мне бы в голову не пришло показывать их одним списком.

Кстати, любой желающий может посмотреть как изменяемый набор полей реализован у salesforce. Судя по тому, что пользователь сам может добавить атрибут, подозреваю, что они использовали EAV. На форму атрибут пользователь добавляет тоже сам, мышкованием.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499523
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АБКстати, любой желающий может посмотреть как изменяемый набор полей реализован у salesforce. Судя по тому, что пользователь сам может добавить атрибут, подозреваю, что они использовали EAV. На форму атрибут пользователь добавляет тоже сам, мышкованием.Не знаю, как это сделано в SalesForce, но в Support Wizard (система для HelpDesk) это реализовано через ALTER TABLE, TerrasoftCRM - ALTER TABLE, ITG Mercury - через список предопределенных полей + метаданные (как я писал ранее), в MS CRM - кажется тоже, через ALTER TABLE.

И во всех этих системах пользовательские формы - настраиваемые и не представляют собой простой список атрибутов.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499540
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АБВы бы еще сделки в эту кучу добавили и спецификации по ним - тогда не 45, а 450 строк получится. Организация - это один объект со своими атрибутами, контакты - другой, сделка - третий; мне бы в голову не пришло показывать их одним списком.Тогда вопрос - где человек увидит связанную информацию (телефоны, персоны, адреса, сделки, историю итп.)?
Или для того, чтобы получить общую информацию надо открыть 5-10-20 форм?

Особенно интересен становится просмотр всех людей, которые числятся за организацией...
как это у вас реализовано? или просто разворачиваете EAV в плоскую таблицу для представления в гриде?
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499541
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BelyИ во всех этих системах пользовательские формы - настраиваемые и не представляют собой простой список атрибутов. В отличие от перечисленных Вами систем, salesforce предоставляется по принципу SaaS, через Интернет. Я как-то с трудом могу себе представить, что в системе, в которой один инстанс обслуживает тысячи организаций, что-то может делаться через добавление новых таблиц.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499548
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123Я вот тут не увидел бизнес-логику при хранении данных.
У ас просто учётная система? Учесть(сохранить) изменяющиеся атрибуты?
Если атрибут добавить так легко, то откуда появится код обслуги данного атрибута? Тоже вручную будете городить в триггере на 1млн.записей атрибутов НА ОДНУ таблицу.
Там подводных камней масса. Я бы внятного ТЗ от "бизнесменов" попросил. Или концепции на 3-х страницах.
Потом они так-же и скажут: "а нам всё равно как вы это ТУДА засунете".+1

Информации недостаточно. Расскажите больше о задаче.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499550
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Belyгде человек увидит связанную информацию (телефоны, персоны, адреса, сделки, историю итп.)?
Или для того, чтобы получить общую информацию надо открыть 5-10-20 форм? Не понял, Вы хотите увидеть все это на одной форме? Боюсь, разговор становится беспредметным...
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499581
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АБВ отличие от перечисленных Вами систем, salesforce предоставляется по принципу SaaS, через Интернет. Я как-то с трудом могу себе представить, что в системе, в которой один инстанс обслуживает тысячи организаций, что-то может делаться через добавление новых таблиц.В свое время лично занимался введением с трой в IBS (DataFort) в 2001 году системы SupportWizard в качестве ASP сервиса.
Не знаю чем это закончилось, но SuportWizard - можно предоставить как сервис.

По поводу ITG - Mercury: тоже таботает через WEB интерфес. Предоставляет ли кто-нибудь его в аренду - не знаю.
МТС, с которым мы работали - просто купил несколько лицензий для себя.
Но сдавать его в аренду - тоже можно.

Да сдавать в аренду - можно все что угодно... в DataFort был проект по сдаче в аренду даже Navision (2001 год). Люди просто заходили через терминальный сервис и работали.

Так что - не аргумент.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499616
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АБНе понял, Вы хотите увидеть все это на одной форме? Боюсь, разговор становится беспредметным...Человеку для принятия решения надо увидеть:
Общую информацию по организации, список телефонов организации, список сотрудников организации, пара адресов. Типичный набор полей в любой CRM.

Как он в вашей системе все это увидит?
Вот надо ему позвонить главным бухгалтерам с организациями с просрочкой платежей и выяснить - дошли ли счета, правильный адрес ли стоял в письме, которое отправили по почте.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499618
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Другой вариант я видел у Paul Nielsen'a - попытка создать объектную БД на основе реляционной.
Если не изменяет память, со следующими возможностями:
-наследовать классы и задавать ассоциации между ними
-добавлять атрибуты, при этом на автомате создаются или изменяются просмотры для селектов и процедуры для update со всеми полями класса
Ссылку посял, но есть исходники с тестовым примером.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499641
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BelyЧеловеку для принятия решения надо увидеть:
Общую информацию по организации, список телефонов организации, список сотрудников организации, пара адресов. Типичный набор полей в любой CRM.
Как он в вашей системе все это увидит?
Вот надо ему позвонить главным бухгалтерам с организациями с просрочкой платежей и выяснить - дошли ли счета, правильный адрес ли стоял в письме, которое отправили по почте. Пример никудышний - это все должно быть в статических полях. Но нормально он все видит, не переживайте. Не на одной форме, но и не на 20. Проходит по 2-3 формам и все что ему надо видит. Собственно, это экспериментальный факт - напоминаю, речь идет о промышленной системе, находящейся в эксплуатации годами в разных организациях.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499726
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BelyЧеловеку для принятия решения надо увидеть:
Общую информацию по организации, список телефонов организации, список сотрудников организации, пара адресов. Типичный набор полей в любой CRM.

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

В Net'e можно реализовать свой ITypedList, в компонентах DevEpress пользователь сам может добавлять поля в формы и гриды.Попутно на основе метаинформации не кто не запрещает реализовать специально обученные билдеры.
Сам присматриваюсь к этой проблеме.Подход shelsoft с разделением на статическую и динамическую части, считаю наиболее оптимальным.Каким образом хранить последнюю еще в раздумьях.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499779
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lightspeedВот ответ от бизнеса: "..меня не волнует что у тебя и как там работает. Мне нужен интерфейс позволяющий динамически изменять необходимые параметры объектов в соответствие с заданными критериями.."А не могли бы вы расшифровать сию загадочную фразу? Что значит "динамически изменять в соответствие с критериями"? Кто и в какой форме эти критерии задавать будет? Кто и как будет программировать логику использования использования "динамически измененных параметров"?

АБВ нашей реализации можно свободно добавлять атрибуты, не трогая ни схему, ни формы. Спросите у пользователя, что он предпочтет - пожертвовать качеством интерфейса или избавиться от зависимости от программистов, от затрат на переделки и от задержек между возникновения необходимости в появлении нового атрибута и возможностью работы с ним.А какие возможности работы с атрибутом кроме "сохранить/посмотреть" возникают у пользователя? И кто программирует эти возможности? И нужен ли для этого EAV?
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499896
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVa
в компонентах DevEpress пользователь сам может добавлять поля в формы и гриды.

===== каким образом? Правая кнопка - меню - добавить Поле:ЗадолженностьКонтрагента? :)

Попутно на основе метаинформации не кто не запрещает реализовать специально обученные билдеры.

======= время на разработку такого фреймворка-конструктора?
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499898
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
BelyТогда вопрос - где человек увидит связанную информацию (телефоны, персоны, адреса, сделки, историю итп.)?
Или для того, чтобы получить общую информацию надо открыть 5-10-20 форм?

Объект может иметь сложную стр-ру, когда св-во объекта - это список. Ессно для работы с такими св-ми открываются самостоят. подформы внутри формы объекта. Все это на EAV.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499915
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bogdanov Andrey АБВ нашей реализации можно свободно добавлять атрибуты, не трогая ни схему, ни формы. Спросите у пользователя, что он предпочтет - пожертвовать качеством интерфейса или избавиться от зависимости от программистов, от затрат на переделки и от задержек между возникновения необходимости в появлении нового атрибута и возможностью работы с ним.А какие возможности работы с атрибутом кроме "сохранить/посмотреть" возникают у пользователя? И кто программирует эти возможности? И нужен ли для этого EAV? Ну если так подходить, то что, в конечном счете, делает любая учетная система? Сохранить/посмотреть. А также поискать и посчитать кое-что и кое-что напечатать.

Мне кажется непрактичным стремление некоторых участников дискуссии реализовать в работе с динамическими атрибутами максимальную функциональность - ту же, что и со статическими. Не окупится. Мы в свое время сделали довольно скромную реализацию, и то наверное переусложнили: без наследования можно было обойтись. Хотя конечно оптимальный компромисс зависит от конкретики задачи, в частности, от объемов и от ожидаемого соотношения между статическими и динамическими атрибутами.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35499922
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bogdanov Andreyкакие возможности работы с атрибутом кроме "сохранить/посмотреть" возникают у пользователя? И кто программирует эти возможности? И нужен ли для этого EAV?
Хороший вопрос. Ессно новый атрибут можно сразу вводить, изменять + использовать в отчетах + в пользовательских формулах при расчетах чего-там, ну и .т.д. Без EAV как-то плохо.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35500019
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторв компонентах DevEpress пользователь сам может добавлять поля в формы и гриды.

===== каким образом? Правая кнопка - меню - добавить Поле:ЗадолженностьКонтрагента? :)

Попутно на основе метаинформации не кто не запрещает реализовать специально обученные билдеры.

======= время на разработку такого фреймворка-конструктора?

В Девках такой функционал заложен в компоненты изначально(пользователь в рантайме может добавлять, удалять поля).При вызове метода в компоненте, появляется окно со списком полей, которые не задействованы.Простым драг&дроп в нее или из нее поля убираются,или добавляются в компонент.В этом плане ничего не нужно реализовывать.Также можно сохранить/восстановить текущий вид с учетом текущей версии программы.
Что подрузумевается по framework'ом?
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35500262
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVa
В Девках такой функционал заложен в компоненты изначально(пользователь в рантайме может добавлять, удалять поля).При вызове метода в компоненте, появляется окно со списком полей, которые не задействованы.Простым драг&дроп в нее или из нее поля убираются,или добавляются в компонент.В этом плане ничего не нужно реализовывать.Также можно сохранить/восстановить текущий вид с учетом текущей версии программы.

это всё НЕ для EAV.
У EAV классического - ОДНО поле КодАтрибута и второе поле ЗначениеАтрибута (или код перечислимой характеристики).
Добавление атрибута, это добавка СТРОКИ, причём все типы данных переводятся в variant либо строчный тип.
Так что в EAV добавление поля тебе не поможет (если ты не разворачиваешь данные в нормальный вид)
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35500280
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АБ
Мне кажется непрактичным стремление некоторых участников дискуссии реализовать в работе с динамическими атрибутами максимальную функциональность - ту же, что и со статическими. Не окупится.
+1
если просто учёт-перечень сервисов, с минимальной бизнес-логикой (например, без истории изменения или редактирования сервиса) то можно и EAV.
- если компания с ними проводит какие-нибудь операции, существуют стадии, состояния сервиса - то нет.

Обычно в БД таблица - это бизнес-сущность. Между ними достаточно сложные взаимосвязи и действия реализованные в триггерах, хранимых процедурах, связях на уровне БД, FK, ограничениях и т.д.

Здесь предложение одно - объект один - сервис. Как и что с ним происходит во время деятельности компании - пусть дядя Вася автоматизирует.

Нонсенс IMHO (вся ИС - справочник товаров, тьфу сервисов)
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35500325
lightspeed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Petro123:
Petro123
Обычно в БД таблица - это бизнес-сущность. Между ними достаточно сложные взаимосвязи и действия реализованные в триггерах, хранимых процедурах, связях на уровне БД, FK, ограничениях и т.д.

Здесь предложение одно - объект один - сервис. Как и что с ним происходит во время деятельности компании - пусть дядя Вася автоматизирует.

Нонсенс IMHO (вся ИС - справочник товаров, тьфу сервисов)


Интересно, с чего вы это взяли?
С того что я вам не описал полную архитектуру системы??? Я и не собирался этого делать. В этом топике меня интересует только не большая ее часть. Архитектура некоторого динамичного справочника. Ничего больше. Поэтому, не зацикливайтесь на том, что-бы сделать что-то большее того, что я описал. Размеры справочника я сообщал. Первоначально будет порядка сотни объектов, и порядка 400 аттрибутов. Общее количество записей на начальном этапе составит примерно 400000. И так-как в дальнейшем, количество объектов и аттрибутов будет изменяться, мне нужен в пилотном проекте, некий динамичный конструктор(бд/приложение) для этого справочника. Но, при таком объеме (по вашим же словам), использование EAV в базе данных будет тормозить, плюс сложность реализации самого приложения. Ок. Я сделал для себя вывод. И пока склоняюсь к собственной архитектуре, описанной мной в предыдущем посте. Не знаю уж делали ее в 1С или нет..
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35500330
АБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123если просто учёт-перечень сервисов, с минимальной бизнес-логикой (например, без истории изменения или редактирования сервиса) то можно и EAV.
- если компания с ними проводит какие-нибудь операции, существуют стадии, состояния сервиса - то нет. Согласен, но чисто для полноты картины - в принципе и в этом случае можно держать текущее состояние в EAV, а стадии и состояния - в контексте бизнес-процесса BPM-системы. Есть положительный опыт: наличие BPM-системы позволяет упростить базу - не отслеживать смену состояний, не держать в базе данные, которые заведомо интересны только пока процесс исполняется.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35500361
provid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lightspeedЯ сделал для себя вывод. И пока склоняюсь к собственной архитектуре, описанной мной в предыдущем посте. Не знаю уж делали ее в 1С или нет..
морочили голову, а оказывается речь вообще идет про 1С.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35500546
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_модиспользовать в отчетах + в пользовательских формулах при расчетах чего-там, ну и .т.д. Без EAV как-то плохо.Собственно это все и есть уже программирование. Да, простенькое, на уровне продвинутого пользователя. И как раз EAV очень сильно усложняет этот процесс.
Без EAV отчеты в нормальном репортере даже блондинки свять способны. А чуть более продвинутые пользователи на ура SQL пользуют (если не напрямую, то с использованием удобных графических квери-билдеров). Использование же EAV практически убивает возможность использования при работа с БД чего-либо кроме поделок, поставляемых разработчиком вместе со своим EAV.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35500556
lightspeed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
provid lightspeedЯ сделал для себя вывод. И пока склоняюсь к собственной архитектуре, описанной мной в предыдущем посте. Не знаю уж делали ее в 1С или нет..
морочили голову, а оказывается речь вообще идет про 1С.

Да нет.. Это просто вы не умеете читать.. Что вы здесь вообще делаете???
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35500594
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
раунд 3-ий заключительный ;) ?!
авторТак-же есть набор аттрибутов, так-же заранее не определенный, (адрес, время работы, телефон, наименование, и т.д.)
возьмём адрес.
Вы спрашивате про подводные камни?

Опишите часть требований к ПОДсистеме для работы с атрибутом адрес.

Просто строка/почтовый/юридический/из справочника/контроль правильности ввода/запросы с агрегированием/

Будет ли у Вас атрибуты: Арес1 Адрес2 и нужно ли в отчётах будет распологать Адрес2 за Адресом1?

Требуется ли от ПодСитсемы отвечать на запросы с SUM, MAX и т.д.?

Предпологаются ли перечислимые характеристики-атрибутов? (большой-маленький, 0,5-1,2 ....)? Механизм их создания, правки, удаления

Ваш прототип IMHO должен будет ответить на все эти вопросы.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35500609
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_модОбъект может иметь сложную стр-ру, когда св-во объекта - это список. Ессно для работы с такими св-ми открываются самостоят. подформы внутри формы объекта. Все это на EAV.т.е. списки делаем вот такими запросами?
Код: 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.
--Writing queries might look pretty straightforward, but its impossible to do in a 
--performant fashion. For example, if we wanted to get everyone that was born in MARCH or 
--has a LAST_NAME = "SMITH", we could simply take the query from above and just wrap an 
--inline view around that:


ops$tkyte@ORA920>; select *
   2     from (
   3   select 
     max(decode(attrName, 'FIRST_NAME', value, null)) first_name,
   4   max(decode(attrName, 'LAST_NAME',  value, null)) last_name,
   5   max(decode(attrName, 'DATE_OF_BIRTH',  value, null)) 
                                                      date_of_birth
   6     from objects, object_attributes, attributes
   7    where attributes.attrName in ( 'FIRST_NAME', 
                                     'LAST_NAME', 'DATE_OF_BIRTH' )
   8      and object_attributes.attrId = attributes.attrId
   9      and object_attributes.oid = objects.oid
  10      and objects.name = 'PERSON'
  11    group by objects.oid
  12          )
  13    where last_name = 'Smith'
  14       or date_of_birth like '%-mar-%'
  15   /

взято отсюда

или вобще - затягиваем данные в память клиентского компьютера и дальше изображаем из себя SQL машину (сортировки, фильтры, джоины)?
как именно?
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35500660
stuard
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Рискну предложить еще два варианта для обсуждения. Интересно будет услышать мнение других.

1) Еспользование sys.Anydata для хранения значений. Из минусов когда пробывал в 10g хранить LOB данные, хоть в документации и есть соответсвующая фукция она не работает.
2) Если у вас известно количество атрибутов на начальном этапе то можно создать таблицу с набором универсальных колонок кажого основного типа и таблицу для с описание в какой колонке для данного типа сервиса храница определенный атрибут. На основе этой таблички строить динамическиt SQL Производительность будет максимальна. NULL как известо места не требует. Если количество атраибтов превысит аксимальное количство калонок построить еще таблицу с отношением 1 к 1
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35500776
sherzod_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
немного оффтопа по сабжу))
насколько я понял
по существу рассматривается вопрос о реализации ООП средствами реляционной СУБД
а это упрется в разработку языка для работы постоянными (persistent) объектами
компилятора для него (или как минимум транслятора в язык SQL)

http://www.ibase.ru/devinfo/oop_rdbms.htm

по моему это слишком большая задача и судя по инофрмации в инете эту проблему пытаются безуспешно (под успехом я понимаю получение такой же рапространенности как и реляционные СУБД) крупные исследовательские компании уже довольно долго,
persistent objects
хотя потребность в подобных системах все растет и растет

интересно чем это все дело кончится
мне начинает казаться, что системы для работы с постоянными объектами требуют иного вида хранилищ, чем реляционные базы.

и еще ООП ведь не панацея - вот посмотрите сами мы пытаемся не сколько реализовать технологию сущность-атрибут, а сколько внести большую структурированность в табличные базы! А в этой области тоже достаточно много наработок. ну например
http://www.ibase.ru/devinfo/treedb.htm

и что? куча частностей, а общей теории нет (опять таки сравнивайте с РБД)

так что, если практика заходит в тупик физик обычно идет к математику (мол что у тебя там нового)) ), так не пора ли обратиться что там ученые понаразработали))
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35500819
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bogdanov AndreyИспользование же EAV практически убивает возможность использования при работа с БД чего-либо кроме поделок, поставляемых разработчиком вместе со своим EAV.
Это верно, но такие "поделки" как раз и называются FW.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35500837
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Belyкак именно?
Поскольку obj_id известен, то подсписки формируются просто по obj_id и имени этого подсписка, ведь это один атрибут-таблица.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35500844
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
sherzod_по существу рассматривается вопрос о реализации ООП средствами реляционной СУБД
Нет, речь идет о системах, ориентированных на конечного пользователя, когда он может самостоятельно менять бизнес-логику, структуру данных - практически все. Вот для них и применяется EAV.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35500856
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_модЭто верно, но такие "поделки" как раз и называются FW.Я не против поделок. Некоторые из них даже весьма удобны и удачны. Правда то, что каждый разработчик прикладной системы начинает с разработки собственного FW, наверное не свосем верно. Но это уже личное дело разработчика и того, кто ему труд оплачивает.
Я против того, чтобы "результатом" этого FW был уродец под названием EAV, так как этот уродец резко ограничивает пользователя по возможности использования чего-то еще кроме поделки. Сейчас существует довольно много удобных средств для отчетности, аналитики или выгрузки данных из реляционными СУБД. И постоянно появляются новые. Прикрутить какой-нибудь OLAP к EAV базе становится нетривиальной для пользователя задачей.
Ну а если способностей (или времени) хватает только на FW с EAV, то не стоит за такое браться.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35500887
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_модПоскольку obj_id известен, то подсписки формируются просто по obj_id и имени этого подсписка, ведь это один атрибут-таблица.Вы не поняли - как именно данные попадают в грид?

посредством хитрого SQL запроса?
или запихиваете в грид данные на клиенте?
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35501748
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Еще раз перечитал начальный пост(раньше по диагонали).
Весь требуемый функционал реализован в SQL Server O/R Hybrid Database

SQL Server O/R dbms supports the following Pure Object-Oriented concepts:
Classes / Sub Classes
Domain Integrity
Inheritance
Polymorphism
Complex Objects

Beyond pure OOdbms, SQL Server O/R dbms adds:
Workflow State
Complex Associations
Collections & Aggregations
Association Spidering
Faзade Code Generation

При создании классов и добавлении атрибутов автоматически создаются view и процедуры для выборки со всеми атрибутами.Реализованы процедуры для select'ов и update'ов с параметрами.
Думаю, в качестве прототипа(или посмотреть на подход) и оценки производительности сойдет.
Исходники есть.
Тестовый скрипт вложил
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35502167
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bogdanov Andrey
Я против того, чтобы "результатом" этого FW был уродец под названием EAV, так как этот уродец резко ограничивает пользователя по возможности использования чего-то еще кроме поделки.

EAV - это способ создания систем для конечного пользователя
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35502170
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Belyкак именно данные попадают в грид?
посредством хитрого SQL запроса?
Да, и не очень хитрого.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35502244
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Такие "уродцы" неплохо иметь для пилотных проектов,во время разработки и для полукоробочных вариантов.
При методе - с шашками на танки, постоянно возникает необходимость прикрутить какой-нибудь атрибут, а это тормозит процесс.Поэтому приходится тоже ковырять подобный вариант.
2 Petro, в результате будут строго типизированные объекты, что такое EAV,что нужно для нормальной работы компонентов форм, я имею представление
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35502546
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_модEAV - это способ создания систем для конечного пользователяНе согласен. Во-первых, Конечному пользователю динамические атрибуты в подавляющем большинстве случаев не нужны. Они могут быть нужны технологу.
А во-вторых, даже для поддержки динамических атрибутов есть лучшие способы создания систем.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35502816
sherzod_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaЕще раз перечитал начальный пост(раньше по диагонали).
Весь требуемый функционал реализован в SQL Server O/R Hybrid Database
...


очень хотелось бы посмотреть на эту систему но она недоступна(сайт досутпен - система не скачивается).
url not found on server

если кто нибудь скачал просьба слейте на мыло.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35502830
provid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
если нужно что-то работающее, то нужно просто добавлять в таблицу объекта столько атрибутов, сколько требуется. Если для экспериментов, то можно и EAV и т.п. При наличии свободного времени и шарового финансирования.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35502847
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaТакие "уродцы" неплохо иметь для пилотных проектов,во время разработки и для полукоробочных вариантов.
При методе - с шашками на танки, постоянно возникает необходимость прикрутить какой-нибудь атрибут, а это тормозит процесс.Поэтому приходится тоже ковырять подобный вариант.
2 Petro, в результате будут строго типизированные объекты, что такое EAV,что нужно для нормальной работы компонентов форм, я имею представление
-1
"во время разработк" не надо бегать "с шашками на танки". Есть отработанные технологии, когда без всякого EAV время добавления нового атрибута составляет 30 мин. в БД и 1 час на клиенте.
Нужно хорошо подумать, чтобы вместо отработанной методологии написать свой слой в БД, свой слой в поставщике данных и свой слой в представлении данных.
Причём квалификация программиста должна быть выше среднего, т.к. он просто будет брать ВСЕ данные на клиента и перебирать их в цикле, чтобы найти нужный атрибут и вычислить среднее.

Готовые решения можно взять, но писать своё?
Безумству храбрых поём мы песню (с)
SeVa
2 Petro, в результате будут строго типизированные объекты, что такое EAV,что нужно для нормальной работы компонентов форм, я имею представление
вы о чём? Мы это и обсуждаем.

ЗЫ. Почти похожая ситуация наблюдается с деревьями в РСУБД.
Понятно, что БД деревья хранить не умеет, но:
- методология хранения в БД - есть:
- все запросы для манипулирования структурой дерева - есть и отработаны
- поддержка на уровне БД (добавляется в последнее время и старших версиях)
- клиенские библиотеки для отображения и редактирования деревьев - есть и отработаны.
В том числе по скорости (виртуальное дерево, где листья грузятся по мере просмотра)

Для EAV есть только первый пункт, со всем остальным разработчик тра...ется самостоятельно.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35503089
lightspeed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Petro123:
Petro123...
авторТак-же есть набор аттрибутов, так-же заранее не определенный, (адрес, время работы, телефон, наименование, и т.д.)
возьмём адрес.
Вы спрашивате про подводные камни?

Опишите часть требований к ПОДсистеме для работы с атрибутом адрес..
...Ваш прототип IMHO должен будет ответить на все эти вопросы.

Все это замечательно, за исключением того, что аттрибуты объектов - динамичны.
Или, вы предполагатете заняться data mining'ом и создавать концепт на каждый полученный аттрибут??? Думаю, это не реально в условиях динамичного добавления и изменения объектов и аттрибутов, конечными пользователями (читай - _разными_ специалистами (в различных областях знаний и бизнеса, компания - холдинг), которым необходимы _разнородные_ объекты и аттрибуты.
Соотвественно, аттрибут "адрес" - имеет _различное_ понимание у того или иного специалиста..

2 provid:
Код: plaintext
1.
если нужно что-то работающее, то нужно просто добавлять в таблицу объекта столько атрибутов, сколько требуется. Если для экспериментов, то можно и EAV и т.п. При наличии свободного времени и шарового финансирования

В очередной раз убеждаюсь, что вы не умеете читать.. (


Далее.. Может кто-то подскажет по проблемам и хинтам текущей модели, на которой я остановился?
Код: plaintext
1.
2.
3.
..Есть еще такой вариант как "EAV-наполовину":
Т.е., создаются объекты, создаются аттрибуты, которые "привязываются" к этим объектам. А далее, по ним создается таблица. Имя которой - есть имя объекта, а названия полей - есть названия аттрибутов привязанных к данному объекту. Далее, при добавлении нового аттрибута - делаем alter table add.. Но, никогда не удаляем поля таблицы объекта. Просто удаляем соответствующую запись из матрицы объект-аттрибут. Соответственно, если аттрибут для данного объекта восстановлен, получаем обратно все данные по нему.
В данном алгоритме, проблема возникает в получении данных из этих таблиц-объектов. Т.к., сначала мы должны получить имена полей из таблицы аттрибутов, для данного объекта(-ов), и лишь потом создавать sql для данной таблицы.. Если кто-то проследил за моей мыслью, буду рад пообщаться..

Может кто работал с данной моделью? А то общение сместилось немного..
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35503176
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторСоотвественно, аттрибут "адрес" - имеет _различное_ понимание у того или иного специалиста..
- т.е. даже так? Классификатора атрибутов не будет? Один введёт атрибут "Адрес", другой "Адресс", третий "адрес". А в таблице значений не код атрибута, а его строковое имя (понимаемое каждым по разному).
- правильности ввода значения для какого либо атрибута не будет?

и т.д.
Тогда лучше сканы в jpeg из записной книжки стенографистки хранить. ... Никаких требований нет, окромя "можно добавить в подсистему". Внятные запросы к такому справочнику сервисов тоже под вопросом.

авторИли, вы предполагатете заняться data mining'ом
я предлагаю озвучить требования, цель и концепцию ИС, а не заниматься гаданием на кофейной гуще. Часто оказывается, что решение лежит совсем в другом месте.

Пока вы озвучили одно требование - динамическое добавление пользователем атрибутов объектов.
А сервис - это объект, т.к. это ВАМ удобнее.

2. По поводу модели, на которой Вы остановились - ничего не понятно. "ООП на клиенте плохо скрещивается с РСУБД"

ЗЫ. Если Вы ораклист, можно ещё попытаться в БД объектами и наследованием баловаться. Если времени вагон.

______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35503192
provid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lightspeed2 provid:
Код: plaintext
1.
если нужно что-то работающее, то нужно просто добавлять в таблицу объекта столько атрибутов, сколько требуется. Если для экспериментов, то можно и EAV и т.п. При наличии свободного времени и шарового финансирования

В очередной раз убеждаюсь, что вы не умеете читать.. (

я еще и писАть умею. Впрочем никто никого ни в чем не ограничивает. У вас право выбора.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35503254
lightspeed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Petro123 авторСоотвественно, аттрибут "адрес" - имеет _различное_ понимание у того или иного специалиста..
- т.е. даже так? Классификатора атрибутов не будет? Один введёт атрибут "Адрес", другой "Адресс", третий "адрес". А в таблице значений не код атрибута, а его строковое имя (понимаемое каждым по разному).
- правильности ввода значения для какого либо атрибута не будет?
...

Не так. Я говорил про различные типы значений аттрибута Адрес. Который есть един и неделим. )
Например, один специалист должен хранить формат Адрес, скажем в текстовой строке, без выделения, скажем улицы, дома, корпуса, офиса, и индекса. А другому нужно это выделение.. А у третьего, это вообще выбор из справочника адресов..
Или еще, вот есть аттрибут "Дата начала": один хранит его в формате time_t, а другому нужно "23-AUG-2008 23:53:53".. Все это конечно можно привести к time_t и потом приводить к необходимому виду. Просто, я хочу сказать что из этого всего следует, что форматы значений аттрибутов - разные. Как и кол-во аттрибутов и их набор на объект, как и кол-во объектов. Вот что имелось ввиду.


Petro123
авторИли, вы предполагатете заняться data mining'ом
я предлагаю озвучить требования, цель и концепцию ИС, а не заниматься гаданием на кофейной гуще. Часто оказывается, что решение лежит совсем в другом месте..

Опять не так. Я уже замечал что описать полную схему ИС я здесь не могу, да и не планирую. Сейчас вопрос о динамическом справочнике, +рационально(время разработки/скорость работы с конечным пользователем)+ хранящем объекты и аттрибуты. Пример аттрибутов я привел выше.


Petro123
2. По поводу модели, на которой Вы остановились - ничего не понятно. "ООП на клиенте плохо скрещивается с РСУБД"

Что именно не понятно? Вроде понятно, что после созданий объекта, и привязки к нему набора аттрибутов, создается статическая таблица, которая есть этот объект, с полями, которые есть эти аттрибуты. Аттрибуты, есть многомерная таблица (z-ось, есть описание формата данного аттрибута для данного пользователя), из которой выбирается необходимый данному пользователю аттрибут. Далее, после автоматического создания данной таблицы, создаются необходимые PK/FK/indexes/triggers связанные с этой таблицей. Все эти аттрибуты таблицы создаются так-же автоматически. Далее, на сервере приложений мы с помощью обычных sql запросов получаем необходимые данные из этой таблицы. Т.е., например, мы ищем необходимые данные по аттрибуту "Адрес", объекта "Рестораны". Мы сначала ищем, наименование таблицы описывающей объект "Рестораны" в таблице объектов. Далее, мы ищем наименование поля, описывающего аттрибут "Адрес". Далее, по таблице-объекту и полю-аттрибуту ищем адрес, причем, в формате для данного пользователя (табл. аттрибутов - многомерна). Т.е., кому-то адрес - это обычная текстовая строка. Кто-то содержит адрес в виде форматированной текстовой строки (для разбиения ее на улицу, дом, корпус, офис, и т.д. Кто-то, указатель на справочник адресов.
Соответственно, в UI, у одного пользователя возникает обычный текстовый input. У другого уже несколько текстовых inputов, а у третьего select со списком адресов. И получают они таблицу, с записями по объекту "Рестораны", с выбранным ранее списком аттриботов (полей таблицы-объекта), и содержащим необходимые данные в аттрибуте "Адрес"..
Конечно, из этого следует что таблиц-объектов "Рестораны", будет <= кол-ву пользователей имеющих право создавать объекты и аттрибуты..
Постарайте прочесть текст из этого абзаца выше, не по диагонали. И вы достигните просветления.. )


Petro123
ЗЫ. Если Вы ораклист, можно ещё попытаться в БД объектами и наследованием баловаться. Если времени вагон.

Да. Ораклист. Т.ч. уже думаю по объекты и наследование. Впрочем, писать систему не мне. А я лишь пытаюсь разработать наиболее удачную архитектуру.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35503262
provid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lightspeed Постарайте прочесть текст из этого абзаца выше, не по диагонали. И вы достигните просветления.. )

я бы, на вашем месте, специальным образом на тексте выше внимание не акцентировал. А то и правда у всех наступит просветление и они начнут создавать таблицы объектов по количеству пользователей.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35503284
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторНе так. Я говорил про различные типы значений аттрибута Адрес. Который есть един и неделим. )
Например, один специалист должен хранить формат Адрес, скажем в текстовой строке, без выделения, скажем улицы, дома, корпуса, офиса, и индекса. А другому нужно это выделение.. А у третьего, это вообще выбор из справочника адресов..
Или еще, вот есть аттрибут "Дата начала": один хранит его в формате time_t, а другому нужно "23-AUG-2008 23:53:53".. Все это конечно можно привести к time_t и потом приводить к необходимому виду. Просто, я хочу сказать что из этого всего следует, что форматы значений аттрибутов - разные. Как и кол-во аттрибутов и их набор на объект, как и кол-во объектов. Вот что имелось ввиду.
раньше нельзя было это сказать? Как вы ТЗ составляете? Или задачи ставите?
- "один специалист" в условиях многопользовательской системы - это функциональное рабочее место ФРМ "Спец".
Представим ВИ данного ФРМ №1:
- вводит новый атрибут "адрес"
- проверяет наличие уже данного атрибута у сервиса №12345
а)- у данного сервиса нет атрибута
б)- у данного сервиса есть атрибут, но с форматом Строка (нам нужен справочник (дом, квартал, улица, корпус...))

как вы представляете (нужно вашему бизнесу) дальнейшие действия?

ААААААААА. (Пишите Вы кучеряво). Вы имелли ввиду не форматы разные, а формат хранения в БД один, а формат ПРЕДСТАВЛЕНИЯ для каждого ФРМ различный?
Т.е. для логина Иван Иваныч адрес будет склеенная строка, а для Петра Петровича - код улицы, номер дома и т.д.?

Приведите реальный пример реального длинного адреса:
- хранящегося в БД
- показываемого всем(каждому) пользователю

ЗЫ Формат хранения и формат представления - разные вещи.

авторЧто именно не понятно? Вроде понятно, что после созданий объекта

==== на клиенте? Понятно.

, и привязки к нему набора аттрибутов

======== непонятно. Я хоть и программист, но термин привязка ПОЛЬЗОВАТЕЛЕМ непонятна. НАПИШИТЕ ВИ (вариант использования)

, создается статическая таблица

=== нет такого понятия в оракле и других бд. Будем считать ОБЫЧНАЯ

, которая есть этот объект, с полями, которые есть эти аттрибуты.

=======
1.1.1.1 Суть подхода «Класс как таблица (ROT)»

Аттрибуты, есть многомерная таблица (z-ось, есть описание формата данного аттрибута для данного пользователя), из которой выбирается необходимый данному пользователю аттрибут. Далее, после автоматического создания данной таблицы, создаются необходимые PK/FK/indexes/triggers связанные с этой таблицей. Все эти аттрибуты таблицы создаются так-же автоматически. Далее, на сервере приложений мы с помощью обычных sql запросов получаем необходимые данные из этой таблицы. Т.е., например, мы ищем необходимые данные по аттрибуту "Адрес", объекта "Рестораны". Мы сначала ищем, наименование таблицы описывающей объект "Рестораны" в таблице объектов. Далее, мы ищем наименование поля, описывающего аттрибут "Адрес".

======= т.е.
Таблица_Иванова
Ресторан Адрес Field_Adress


Далее, по таблице-объекту и полю-аттрибуту ищем адрес, причем, в формате для данного пользователя (табл. аттрибутов - многомерна). Т.е., кому-то адрес - это обычная текстовая строка. Кто-то содержит адрес в виде форматированной текстовой строки (для разбиения ее на улицу, дом, корпус, офис, и т.д. Кто-то, указатель на справочник адресов.

====== тоже в динамике пользователем Иван Иваныч? И что такое указатель в РСУБД? FK?


Соответственно, в UI, у одного пользователя возникает обычный текстовый input. У другого уже несколько текстовых inputов, а у третьего select со списком адресов. И получают они таблицу, с записями по объекту "Рестораны", с выбранным ранее списком аттриботов (полей таблицы-объекта), и содержащим необходимые данные в аттрибуте "Адрес"..
Конечно, из этого следует что таблиц-объектов "Рестораны", будет <= кол-ву пользователей имеющих право создавать объекты и аттрибуты..
Постарайте прочесть текст из этого абзаца выше, не по диагонали. И вы достигните просветления.. )
нда! прочёл 8-)

IMHO
- этот абзац на форум по Проектированию БД, там тебе скажут более профессионально про многомерные таблицы и Z ось в БД
- перед этим определиться в ВИ, и в текстовом виде ЗДЕСЬ написать КАК БУДЕТ РАБОТАТЬ ИВАН ИВАНЫЧ со всей этой байдой
- перед этим определиться в ВИ, и в текстовом виде ЗДЕСЬ написать КАК БУДЕТ РАБОТАТЬ ПЕТР ПЕТРОВИЧ делая поиск по всей этой массе разнородной-разноформатой инфы
- пример ВИ я написал выше


IMHO
- У Вас в работе нет ни одного ограничения
- Вы на пользователя хотите повесить (хоть и в автомате) создание объектов, атрибутов, ссылок на справочник, заполнение справочников, создание триггеров, FK и тд., определение типа атрибута. Какая зарплата у данного пользователя?
- система а-ля 1С хороша, но у меня жена глав-бух не сама там программирует и вводит атрибуты, а меня зовёт :).
- доработка данной системы в процессе эксплуатации будет неглюкавее, дешевле и быстрее

авторА я лишь пытаюсь разработать наиболее удачную архитектуру
- займитесь ВИ, в паре с разработчиком БД (они в другом форуме сидят)

______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35503294
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ROT EAV плюсы и минусы
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35503893
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
lightspeedМожет кто работал с данной моделью?
Плохая модель - объект может иметь сложную ст-ру и не влезать в одну таблицу.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35503896
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bogdanov AndreyВо-первых, Конечному пользователю динамические атрибуты в подавляющем большинстве случаев не нужны. Они могут быть нужны технологу.
А во-вторых, даже для поддержки динамических атрибутов есть лучшие способы создания систем.
1. Под конечным пользователем как раз и понимается технолог.
2. М.б., но я не встречал
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35503929
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_мод2. М.б., но я не встречалНу тогда советую ознакомиться, а потом EAV защищать. Даже в этой теме примеры систем уже упоминали.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35503945
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123ROT EAV плюсы и минусы
Все верно, вот только вопрос - почему "Возможность увеличивать количество классов без увеличения количества таблиц" является преимуществом? По всей видимости, есть какое-то подспудное мнение, что создавать таблицы - нехорошо. Не мог ли бы мне кто-нибудь из участников дискуссии объяснить что в этом нехорошего?
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35503953
provid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bogdanov Andrey Petro123ROT EAV плюсы и минусы
Все верно, вот только вопрос - почему "Возможность увеличивать количество классов без увеличения количества таблиц" является преимуществом? По всей видимости, есть какое-то подспудное мнение, что создавать таблицы - нехорошо. Не мог ли бы мне кто-нибудь из участников дискуссии объяснить что в этом нехорошего?
суть вопроса только в том, что любое увеличение числа таблиц или полей требует доработки системы. Эти доработки могут даваться таким трудом, что разрабочик вынужден искать путь возложения на пользователя возможности самостоятельного расширения атрибутного состава. Так и рождаются EAV и компания. Если же добавление атрибута в таблицу или создание новой таблицы (со всем окружением в виде форм и т.д.) требуют умения грамотно написать имя таблицы, то мыслей изобретать универсальные, но сложные и неповоротливые архитектуры - просто не возникает.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35504172
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bogdanov AndreyНе мог ли бы мне кто-нибудь из участников дискуссии объяснить что в этом нехорошего?
Для того чтобы уже существующие программы подхватили новый объект(таблицу, столбец) они изначально должны быть написана на динамическиом SQL и использовать словарь БД - таких систем я лично не видел.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35504261
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторДля того чтобы уже существующие программы подхватили новый объект(таблицу, столбец) они изначально должны быть написана на динамическиом SQL и использовать словарь БД - таких систем я лично не видел.

Совершенно необязательно.В варианте,который я приводил раньше, при добавлении/удалении атрибута, на автомате создаются view&sp со всеми полями.В Net возможны и другие варианты.
Например, свой BindingManager.
PS На вопрос "как?", все обсуждение сводится к ответам:"Кому это нужно!".
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35504336
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_модДля того чтобы уже существующие программы подхватили новый объект(таблицу, столбец) они изначально должны быть написана на динамическиом SQL и использовать словарь БД - таких систем я лично не видел.То есть системы в которых программы умеют "подхватывать" новый атрибут, описанный в "самодельном" словаре данных вы себе представляете, а программы, которые умеют "подхватывать" новый атрибут описанный в словаре данных СУБД - представить не можете?
Я думаю, что вы - лукваите. Вы сами для работы с СУБД какое средство используете?
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35504445
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bogdanov AndreyТо есть системы в которых программы умеют "подхватывать" новый атрибут, описанный в "самодельном" словаре данных вы себе представляете
Это довольно просто - ведь SQL статический
Bogdanov Andreyа программы, которые умеют "подхватывать" новый атрибут описанный в словаре данных СУБД - представить не можете?
Такие программы я стараюсь писать только в крайних случаях.
Bogdanov Andrey Вы сами для работы с СУБД какое средство используете?
Смотря какая СУБД :)
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35504451
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_мод Belyкак именно данные попадают в грид?
посредством хитрого SQL запроса?
Да, и не очень хитрого.Примет "не очень хитрого" - можете продемонстрировать?
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35504540
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_модДля того чтобы уже существующие программы подхватили новый объект(таблицу, столбец) они изначально должны быть написана на динамическиом SQL и использовать словарь БД - таких систем я лично не видел.Никто не мешает использовать метаданные не только для EAV, но и для обычных таблиц.

И таких программ - масса, которые можно донастроить для изменившихся таблиц.
И не зачем лазить для этого в словарь БД.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35504570
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_мод Bogdanov AndreyТо есть системы в которых программы умеют "подхватывать" новый атрибут, описанный в "самодельном" словаре данных вы себе представляете
Это довольно просто - ведь SQL статическийПокажите мне "статический SQL", который считывает список клиентов (фамилия, имя, отчество) из EAV базы.

_мод Bogdanov Andreyа программы, которые умеют "подхватывать" новый атрибут описанный в словаре данных СУБД - представить не можете?
Такие программы я стараюсь писать только в крайних случаях. То есть своем самодельному словарю данных вы доверяете больше, чем системному словарю БД? И из-за этого заставляете всех пользователей ваше программы мучаться с вашим собственным словарем вместо использования промышленных стандартов.

_модСмотря какая СУБД :)Ну я не знаю с какими вы вообще работаете.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35504882
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
BelyНикто не мешает использовать метаданные не только для EAV, но и для обычных таблиц.

Это верно, но в select-е все равно придется использовать новые имена таблиц-столбцов, т.е запрос будет динамический. Так что метаописание не спасает.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35504886
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
BelyПримет "не очень хитрого" - можете продемонстрировать?
Простенького готового нет а думать лень :)
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35504890
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_мод BelyПримет "не очень хитрого" - можете продемонстрировать?
Простенького готового нет а думать лень :)То есть заполнение грида уже "непростая" задача - думать заставляет.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35504911
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bogdanov AndreyПокажите мне "статический SQL", который считывает список клиентов (фамилия, имя, отчество) из EAV базы.
Поскольку в EAV используется БД фиксированной стр-ры, то запросы статические, т.е. имена таблиц и полей тоже фиксированные. Их можно отладить один раз и навсегда. Что не мешает строить запросы динамически (в основном при пользовательском поиске). Но там отлаживается не запрос а алгоритм его формирования.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35504944
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_модПоскольку в EAV используется БД фиксированной стр-ры, то запросы статические, т.е. имена таблиц и полей тоже фиксированные. Их можно отладить один раз и навсегда. Ну так написать этот статический запрос вы в состоянии? Чтобы в гриде было Name, MiddleName, LastName. Структура СУБД в этом топике на первой странице.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35505029
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_мод BelyНикто не мешает использовать метаданные не только для EAV, но и для обычных таблиц.

Это верно, но в select-е все равно придется использовать новые имена таблиц-столбцов, т.е запрос будет динамический. Так что метаописание не спасает.Во всех системах и во всех языках программирования сейчас запрос можно указать в качестве свойства датасета/рекордсета.

Сам SQL запрос - можно хранить просто в метаданных.
У нас так построена система отчетов.
Указал SQL запрос, указал выводимые столбцы и как называются колонки - все, отчет готов.
Отчет = грид.

_мод[Простенького готового нет а думать лень :)вот такие?
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35505145
lightspeed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 _мод:
_мод lightspeedМожет кто работал с данной моделью?
Плохая модель - объект может иметь сложную ст-ру и не влезать в одну таблицу.
В моей модели, объект - это таблица. Соотв., это подразумевает, что все, что связанно с этим объектом - находится в этой таблице. Что в этом случае значит "не влезать в одну таблицу"? Но, даже если такое произойдет, и встретится вот такой вот сложный объект, никто не мешает технологу, создающему аттрибуты(читай - поля) для данного объекта, добавить еще один аттрибут содержащий метаинформацию о связи одного объекта с другим. (Ведь что такое сложный объект - это объект состоящий из нескольких других, взаимосвязанных по определенным правилам объектов). Т.е., одним из аттрибутов "простого" объекта может быть некий набор правил и данных (метаинформация) о связи с ним другого объекта. В крайнем случае, можно лишь добавить поле указатель FK на PK_ID таблицы с метаинформацией. Что впрочем, не изменяет смысла работы модели. Излагаю доступно??


2 Petro123:
автор
Приведите реальный пример реального длинного адреса:
- хранящегося в БД
- показываемого всем(каждому) пользователю

Пример:
Код: 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.
 1 . пользователь Иванов
-- адрес берет(и кладет) из обычной текстовой строки
MODEL:
объект - Иванов_рестораны
аттрибут(varchar) - адрес
значение - Калашников переулок, дом  17 
VIEW:
Адрес: <input type=text name=address value="Калашников переулок, дом 17">

 2 . пользователь Петров
-- адрес берет из таблицы кодов-адресов.
MODEL:
объект - Петров_заводы
аттрибут(varchar) - адрес
значение -  17 / 23 /// 422 
VIEW:
Улица: <input type=text name=street value="Калашников переулок">
Дом: <input type=text name=house value="23">
Офис: <input type=text name=office value="422">
CONTROLLER (читай PL/SQL код триггера, сидящий в SELECT данной таблицы):
берет значение  17 / 23 /// 422  и разделывает его на  17  -  23  -  422 
далее, берет FK  17  и смотрит его в другом объекте - адреса.

 3 . пользователь Сидоров
-- адрес берет из форматированной текстовой строки.
MODEL:
объект - Сидоров_магазины
аттрибут(varchar) - адрес
значение - Калашников переулок& 17 & 23 
VIEW:
Улица: <input type=text name=street value="Калашников переулок">
Дом: <input type=text name=house value="17">
Офис: <input type=text name=office value="23">
CONTROLLER:
берет форматированную строку, разделывает ее, и выкидывает ее в SELECT.

Все триггеры строятся автоматически, на уровне создания объекта, из заданных прототипов, код которых сидит в отдельной таблице прототипов. Этот код формируется программистом, при создании прототипа. При создании объекта с данным аттрибутом, технолог выбирает один из заданных прототипов. После, CONTROLLER генерит функционал триггера на основе этого прототипа.



, создается статическая таблица
=== нет такого понятия в оракле и других бд. Будем считать ОБЫЧНАЯ

имелось ввиду, что это не будет составная view/mat.view из других таблиц.



Далее, по таблице-объекту и полю-аттрибуту ищем адрес, причем, в формате для данного пользователя (табл. аттрибутов - многомерна). Т.е., кому-то адрес - это обычная текстовая строка. Кто-то содержит адрес в виде форматированной текстовой строки (для разбиения ее на улицу, дом, корпус, офис, и т.д. Кто-то, указатель на справочник адресов.

====== тоже в динамике пользователем Иван Иваныч? И что такое указатель в РСУБД? FK?

Да, именно. FK.

In conclusion, получается довольно интересная архитектура. Которая совмещает в себе ROT и обычную, relational архитектуру..
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35505384
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторВсе триггеры строятся автоматически, на уровне создания объекта, из заданных прототипов, код которых сидит в отдельной таблице прототипов

- замучитесь шаблоны делать. Такая штука в ErWin есть (рисунок). Так там целый язык для этого сделан, и документации на 300 страниц.

авторИванов_рестораны
- а зачем ФИО в имени таблицы? А если он уволился? У Вас не многопользовательская система?

авторИванов_рестораны
- как вы будете искать: Найти все объекты по улице с ID = 17? Как все таблицы перебирать будете? Если завтра появится объект lightspeed_1 и lightspeed_2_туалеты?


авторlightspeed_рестораны
- как вы будете искать: Найти все объекты по улице с ID = 17? Иванова объект со строкой как найдётся? Или клиент с кодами из справочника не работает?

авторВсе триггеры строятся автоматически
- проблема в том, что в триггер в EAV срабатывает на строку, т.е. при вставке поля возраст и поля-строки АДРЕС он срабатывает одинаково. Как шаблон писать будем? Как отличать будем строки-атрибуты, чтобы знать что делать, когда не знаем какие атрибуты будут ? 8-)

авторВсе триггеры строятся автоматически

- На Update/Insert/Delete до вставки и они же после. Итого 6 на каждую таблицу?

авторкод триггера, сидящий в SELECT данной таблицы

- что такое триггер на select? На Update/Insert/Delete знаю (все 6 на каждую которых будет генерить шаблон программиста).

авторТ.е., одним из аттрибутов "простого" объекта может быть некий набор правил и данных (метаинформация) о связи с ним другого объекта. В крайнем случае, можно лишь добавить поле указатель FK на PK_ID таблицы с метаинформацией. Что впрочем, не изменяет смысла работы модели. Излагаю доступно??

- это уже не EAV. "Просто" засунуть бесконечное дерево в одну таблицу в РСУБД можно, а вот заранее неизвестный по сложности объект со связями - нет.
.............

- Тут запросы вообще работать не будут, только ручной перебор построчный по всей базе - fullscan

- клиентские библиотеки тоже работать не будут

- пока напишешь этого "ежа с ужом" или заказчик помрёт, или ....
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35505388
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
попробуй сваять самый простой запрос на свою модель.
При таком подходе лучше в БЛОБ все классы хранить, всё равно все строки перебирать при поиске и парсинге
- многопользовательской работы нет
- SQL нет
- поля таблиц - не нужны

нафига тебе триггеры и EAV?

f1 f2 f3 f4 f5123 рестораны Иванов ТипКласса1 стрим_поток_блоб_класса
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35505554
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_мод BelyНикто не мешает использовать метаданные не только для EAV, но и для обычных таблиц.

Это верно, но в select-е все равно придется использовать новые имена таблиц-столбцов, т.е запрос будет динамический. Так что метаописание не спасает.Никто не мешает хранить запрос тоже отдельно, в метаданных, в отдельной таблице, в файле и т.п.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35505557
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
lightspeedИзлагаю доступно??
Доступно, но неверно. Объект сложной структуры и связь между объектами разных типов - разные вещи.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35505565
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bogdanov AndreyЧтобы в гриде было Name, MiddleName, LastName. Структура СУБД в этом топике на первой странице.
Код: plaintext
1.
2.
select attr(obj_id,'Name'), attr(obj_id,'MiddleName'), attr(obj_id,'LastName') from obj
  where attr(obj_id,'Name') like 'Иванов%'
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35505570
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
BelyУказал SQL запрос, указал выводимые столбцы и как называются колонки - все, отчет готов.
Если вы не наврали в запросе или кто-то не поменял стр-ру БД. Иначе для юзера будет сюрприз.
В том и беда динамических запросов, что они непредсказуемы.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35505818
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
select attr(obj_id,'Name'), attr(obj_id,'MiddleName'), attr(obj_id,'LastName') from obj
  where attr(obj_id,'Name') like 'Иванов%'
Я так и думал.
Запрос под названием, "прощай индексы"
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35505830
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BelyЗапрос под названием, "прощай индексы"+1
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35505973
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
BelyЗапрос под названием, "прощай индексы"
Это была шутка
Код: plaintext
1.
2.
3.
4.
5.
6.
select attr(obj_id,'Name'), attr(obj_id,'MiddleName'), attr(obj_id,'LastName') from obj x
  where
  exists(select  1  from obj_atr where obj_id=x.obj_id and atr_name='Name' and atr_value like 'Иванов%')

select attr(obj_id,'Name'), attr(obj_id,'MiddleName'), attr(obj_id,'LastName') from obj
  where obj_id in(select obj_id from obj_atr where atr_name='Name' and atr_value like 'Иванов%')
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35506037
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_модЭто была шуткаЭто чуть лучше, но EXISTS - это тоже гарантированный FULL SCAN по obj

Не говоря о том, что условия AND приводят к нужде делать несколько EXIST-ов для получения результата.
Так 5-10 безобидных условий поиска делают запрос развеселым с точки зрения времени выполнения.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35506632
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
BelyТак 5-10 безобидных условий поиска делают запрос развеселым с точки зрения времени выполнения.
Конечно, но здесь важно предельно допустимое время.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35506899
jikez
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Делал похожую задачу, был цех по производству изделий для вентеляционных систем, надо было считать расход списанного материала. Поскольку каждое изделие по своей сути уникально, не формой так размерами, поэтому единственным решением был EAV.

Расход материалов описывался формулами (например расчет площади поверхности для списания оцинкованного листа), все параметры/переменные этих формул как раз и были атрибутами.

Всё достаточно шустро работало.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35515374
Shr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Для задачи именно хранения я бы использовал примерно следующую архитектуру:
Метаданные в небольшом числе таблиц, отдельные таблицы для каждого типа данных или его версии.
Для манипуляции данными - свой язык, транслирующийся в sql. Имена ТД должны транслироваться в имена таблиц версий, или view над их обьединениями (union).
Шире - возможности языка должны определяться требованиями к проекту, которых в постановке нет.

Таблицы метаданных:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
-- Типы данных (ТД)
data_types ( id , name)

/*
  Версии ТД
  sys_name - имя таблицы, в которой хранятся обьекты этого типа.
  При создании или изменении типа создается новая таблица.
  Имена таблиц данных генерируются автоматически.
*/
type_versions ( type_id, version_id , sys_name, from_date, to_date)

-- Аттрибуты в каждой версии
version_attributes ( type_id, version_id, attribute_name , attribute_type)

--  История изменений ТД
version_changes ( change_id , type_id, version_from, version_to)

/*
  Изменения атрибутов при формировании новой версии
  Атрибут может быть добавлен, удален, изменен его тип  
*/
version_change_attributes ( change_id, attribute_name , change_type)
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35515779
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Shr
не увидел решения по сабжу.
Вместо него вы расширили ТЗ добавив:
- хранение истории и изменение типов атрибутов
- создание "своего языка" (для кого?)
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35516090
Shr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123не увидел решения по сабжу.Сабж заключался в следующем:

lightspeedВопрос в правильном построении архитектуры базы данных/приложения, реализующих данную структуру?

Конкретнее:
1. матрицу привязки аттрибута к объекту
2. где и как должна содержаться сама информация?
3. добавление/редактирование/удаление информации из аттрибутов для данного объекта.
4. Запросы, реализующие считывание информации по аттрибутам для данного объекта.
Ответ был на общий вопрос, ответы на остальные из него следуют. Если угодно, могу расписать.

Petro123
Вместо него вы расширили ТЗ добавив:
- хранение истории и изменение типов атрибутов
- создание "своего языка" (для кого?)
Хранение истории и изменение типов атрибутов - это не ТЗ, это описание предложенной реализации.

Создание своего языка (обертка над sql, позволяющая манипулировать данными по имени типа без учета версии и названия конкретной таблицы) - предложение по реализации 3, 4 вопроса из сабжа.
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35516198
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Shr
- мне не очень нравится термин "версия атрибута".
Как это будет выглядеть для одного (или составного) атрибута Адрес :

Калашников переулок, дом 17
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35516218
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ну, типа такого разброса вариантов:

, , Заревый пр., 15 - 17, , , , Северное Медведково
, , Римского-Корсакова ул., 8, , , , Отрадное
, , Наметкина ул., , , , ,
, , Ореховый бульв., 57, , , , Зябликово
, , Овчинниковская наб., 22 - 24, , , , Замоскворечье
, , Фрунзенская наб., 40, , , , Хамовники
, , Корнейчука ул., 42, , , , Бибирево
, , Казанский 2-й просек, 21 / 48, , , , Рязанский
14, , , , , , ,
, , Авиационная ул., 63 - 65, , 1, , Щукино
, , Остоженка ул., 16 / 1 - 1 А, , , 5, Хамовники
, , Рублевское шоссе, 72, , , , Крылатское
, , Ямского поля 1-я ул., 12, , , , Беговой
19 В, , , , , КП29, , Ховрино
, , Старобитцевская ул., , , , , Северное Бутово
, , Андропова просп., , , , ,
, , Айвазовского ул., , , , , Ясенево
, , Внуково пос., , , 8, 9, , Внуково
, 268, Последний пер., 14, , , , Мещанский
, 4 / 16 А, 5 / 14, , , , 18, , Аэропорт
...
Рейтинг: 0 / 0
изменяемый набор полей, в каждой таблице
    #35526177
Николай1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АБ Bely АБНе самый лучший интерфейс? Согласен.Вместо инструмента вы им дали конструктор.
Выучили бы их языку SQL, может вобще интерфейс писать не пришлось...

По поводу не жалуются - я видел организации, у которых стояла глюкавая система учета документов, поэтому им приходилось документ сперва регистрировать в тетрадке (записывали на бумаге), потом в отдельном экселевом файле, а потом уже в учетной системе.
И ничего - тоже люди не жаловались... Не надо инсинуаций - конструкторы, SQL и тетрадки тут не при чем. Пользователь видит строго типизированные атрибуты, заданные для выбранного объекта на уровне метаданных. Просто расположены они на экране не в оптимаотном с точки зрения эстетики и эргономики порядке, а в столбик один под другим.

Смысл использования EAV ведь не в том, чтобы избавиться от необходимости расширять схему БД. Что толку, если при добавлении атрибута придется переписывать все формы? Что схема, что формы в конечном итоге сводятся к трудозатратам.

В нашей реализации можно свободно добавлять атрибуты, не трогая ни схему, ни формы. Спросите у пользователя, что он предпочтет - пожертвовать качеством интерфейса или избавиться от зависимости от программистов, от затрат на переделки и от задержек между возникновения необходимости в появлении нового атрибута и возможностью работы с ним.

Спрашивали!
Пользователям положить на зависимость от програмистов. Им подавай удобный и понятный интерфейс.
Кстати, список еще умещается на одной странице, или уже надо листать?

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


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