powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / изменяемый набор полей, в каждой таблице
23 сообщений из 123, страница 5 из 5
изменяемый набор полей, в каждой таблице
    #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
23 сообщений из 123, страница 5 из 5
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / изменяемый набор полей, в каждой таблице
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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