|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
_мод BelyПримет "не очень хитрого" - можете продемонстрировать? Простенького готового нет а думать лень :)То есть заполнение грида уже "непростая" задача - думать заставляет. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 16:55 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Bogdanov AndreyПокажите мне "статический SQL", который считывает список клиентов (фамилия, имя, отчество) из EAV базы. Поскольку в EAV используется БД фиксированной стр-ры, то запросы статические, т.е. имена таблиц и полей тоже фиксированные. Их можно отладить один раз и навсегда. Что не мешает строить запросы динамически (в основном при пользовательском поиске). Но там отлаживается не запрос а алгоритм его формирования. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 17:03 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
_модПоскольку в EAV используется БД фиксированной стр-ры, то запросы статические, т.е. имена таблиц и полей тоже фиксированные. Их можно отладить один раз и навсегда. Ну так написать этот статический запрос вы в состоянии? Чтобы в гриде было Name, MiddleName, LastName. Структура СУБД в этом топике на первой странице. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 17:14 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
_мод BelyНикто не мешает использовать метаданные не только для EAV, но и для обычных таблиц. Это верно, но в select-е все равно придется использовать новые имена таблиц-столбцов, т.е запрос будет динамический. Так что метаописание не спасает.Во всех системах и во всех языках программирования сейчас запрос можно указать в качестве свойства датасета/рекордсета. Сам SQL запрос - можно хранить просто в метаданных. У нас так построена система отчетов. Указал SQL запрос, указал выводимые столбцы и как называются колонки - все, отчет готов. Отчет = грид. _мод[Простенького готового нет а думать лень :)вот такие? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 17:50 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
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.
Все триггеры строятся автоматически, на уровне создания объекта, из заданных прототипов, код которых сидит в отдельной таблице прототипов. Этот код формируется программистом, при создании прототипа. При создании объекта с данным аттрибутом, технолог выбирает один из заданных прототипов. После, CONTROLLER генерит функционал триггера на основе этого прототипа. , создается статическая таблица === нет такого понятия в оракле и других бд. Будем считать ОБЫЧНАЯ имелось ввиду, что это не будет составная view/mat.view из других таблиц. Далее, по таблице-объекту и полю-аттрибуту ищем адрес, причем, в формате для данного пользователя (табл. аттрибутов - многомерна). Т.е., кому-то адрес - это обычная текстовая строка. Кто-то содержит адрес в виде форматированной текстовой строки (для разбиения ее на улицу, дом, корпус, офис, и т.д. Кто-то, указатель на справочник адресов. ====== тоже в динамике пользователем Иван Иваныч? И что такое указатель в РСУБД? FK? Да, именно. FK. In conclusion, получается довольно интересная архитектура. Которая совмещает в себе ROT и обычную, relational архитектуру.. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 19:17 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
авторВсе триггеры строятся автоматически, на уровне создания объекта, из заданных прототипов, код которых сидит в отдельной таблице прототипов - замучитесь шаблоны делать. Такая штука в 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 - клиентские библиотеки тоже работать не будут - пока напишешь этого "ежа с ужом" или заказчик помрёт, или .... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2008, 01:25 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
попробуй сваять самый простой запрос на свою модель. При таком подходе лучше в БЛОБ все классы хранить, всё равно все строки перебирать при поиске и парсинге - многопользовательской работы нет - SQL нет - поля таблиц - не нужны нафига тебе триггеры и EAV? f1 f2 f3 f4 f5123 рестораны Иванов ТипКласса1 стрим_поток_блоб_класса ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2008, 01:34 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
_мод BelyНикто не мешает использовать метаданные не только для EAV, но и для обычных таблиц. Это верно, но в select-е все равно придется использовать новые имена таблиц-столбцов, т.е запрос будет динамический. Так что метаописание не спасает.Никто не мешает хранить запрос тоже отдельно, в метаданных, в отдельной таблице, в файле и т.п. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2008, 09:20 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
lightspeedИзлагаю доступно?? Доступно, но неверно. Объект сложной структуры и связь между объектами разных типов - разные вещи. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2008, 09:21 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Bogdanov AndreyЧтобы в гриде было Name, MiddleName, LastName. Структура СУБД в этом топике на первой странице. Код: plaintext 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2008, 09:25 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
BelyУказал SQL запрос, указал выводимые столбцы и как называются колонки - все, отчет готов. Если вы не наврали в запросе или кто-то не поменял стр-ру БД. Иначе для юзера будет сюрприз. В том и беда динамических запросов, что они непредсказуемы. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2008, 09:28 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Код: plaintext 1. 2.
Запрос под названием, "прощай индексы" ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2008, 11:11 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
BelyЗапрос под названием, "прощай индексы"+1 ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2008, 11:17 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
BelyЗапрос под названием, "прощай индексы" Это была шутка Код: plaintext 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2008, 12:06 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
_модЭто была шуткаЭто чуть лучше, но EXISTS - это тоже гарантированный FULL SCAN по obj Не говоря о том, что условия AND приводят к нужде делать несколько EXIST-ов для получения результата. Так 5-10 безобидных условий поиска делают запрос развеселым с точки зрения времени выполнения. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2008, 12:26 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
BelyТак 5-10 безобидных условий поиска делают запрос развеселым с точки зрения времени выполнения. Конечно, но здесь важно предельно допустимое время. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2008, 15:15 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Делал похожую задачу, был цех по производству изделий для вентеляционных систем, надо было считать расход списанного материала. Поскольку каждое изделие по своей сути уникально, не формой так размерами, поэтому единственным решением был EAV. Расход материалов описывался формулами (например расчет площади поверхности для списания оцинкованного листа), все параметры/переменные этих формул как раз и были атрибутами. Всё достаточно шустро работало. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.08.2008, 16:35 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Для задачи именно хранения я бы использовал примерно следующую архитектуру: Метаданные в небольшом числе таблиц, отдельные таблицы для каждого типа данных или его версии. Для манипуляции данными - свой язык, транслирующийся в 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2008, 09:16 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Shr не увидел решения по сабжу. Вместо него вы расширили ТЗ добавив: - хранение истории и изменение типов атрибутов - создание "своего языка" (для кого?) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2008, 12:28 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Petro123не увидел решения по сабжу.Сабж заключался в следующем: lightspeedВопрос в правильном построении архитектуры базы данных/приложения, реализующих данную структуру? Конкретнее: 1. матрицу привязки аттрибута к объекту 2. где и как должна содержаться сама информация? 3. добавление/редактирование/удаление информации из аттрибутов для данного объекта. 4. Запросы, реализующие считывание информации по аттрибутам для данного объекта. Ответ был на общий вопрос, ответы на остальные из него следуют. Если угодно, могу расписать. Petro123 Вместо него вы расширили ТЗ добавив: - хранение истории и изменение типов атрибутов - создание "своего языка" (для кого?) Хранение истории и изменение типов атрибутов - это не ТЗ, это описание предложенной реализации. Создание своего языка (обертка над sql, позволяющая манипулировать данными по имени типа без учета версии и названия конкретной таблицы) - предложение по реализации 3, 4 вопроса из сабжа. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2008, 14:34 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Shr - мне не очень нравится термин "версия атрибута". Как это будет выглядеть для одного (или составного) атрибута Адрес : Калашников переулок, дом 17 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2008, 15:12 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
ну, типа такого разброса вариантов: , , Заревый пр., 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, , Аэропорт ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2008, 15:18 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
АБ Bely АБНе самый лучший интерфейс? Согласен.Вместо инструмента вы им дали конструктор. Выучили бы их языку SQL, может вобще интерфейс писать не пришлось... По поводу не жалуются - я видел организации, у которых стояла глюкавая система учета документов, поэтому им приходилось документ сперва регистрировать в тетрадке (записывали на бумаге), потом в отдельном экселевом файле, а потом уже в учетной системе. И ничего - тоже люди не жаловались... Не надо инсинуаций - конструкторы, SQL и тетрадки тут не при чем. Пользователь видит строго типизированные атрибуты, заданные для выбранного объекта на уровне метаданных. Просто расположены они на экране не в оптимаотном с точки зрения эстетики и эргономики порядке, а в столбик один под другим. Смысл использования EAV ведь не в том, чтобы избавиться от необходимости расширять схему БД. Что толку, если при добавлении атрибута придется переписывать все формы? Что схема, что формы в конечном итоге сводятся к трудозатратам. В нашей реализации можно свободно добавлять атрибуты, не трогая ни схему, ни формы. Спросите у пользователя, что он предпочтет - пожертвовать качеством интерфейса или избавиться от зависимости от программистов, от затрат на переделки и от задержек между возникновения необходимости в появлении нового атрибута и возможностью работы с ним. Спрашивали! Пользователям положить на зависимость от програмистов. Им подавай удобный и понятный интерфейс. Кстати, список еще умещается на одной странице, или уже надо листать? ы ... |
|||
:
Нравится:
Не нравится:
|
|||
06.09.2008, 22:11 |
|
|
start [/forum/topic.php?fid=33&msg=35505565&tid=1548708]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
44ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
others: | 295ms |
total: | 438ms |
0 / 0 |