|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Приветствую, столкнулся с одной задачей. И что-бы не заниматься велосипедостроением, хотел-бы сначала проконсультироваться. ) В соответствие с бизнес-логикой, у компании есть набор предоставляемых ей сервисов. Пусть сервис будет объектом. Данный набор объектов заранее не определен. Т.е. он может изменяться. Далее, у каждого объекта есть набор аттрибутов, который тоже не определен, т.е. может постоянно изменяться. Вопрос в правильном построении архитектуры базы данных/приложения, реализующих данную структуру? Добавлю, что в лоб реализовывать набор таблиц для каждого объекта не считаю правильным. Тем более, что таких объектов намечается больше сотни, для начала. А потом еще больше.. И т.к. аттрибуты объекта постоянно меняются, то делать 'alter table add/drop/rename' - тоже не есть хорошее решение.. Вот, как вижу это я. Есть некоторый набор сервисов(объектов), заранее не определенный, предоставляемый компанией. Упрощенно, Код: plaintext 1. 2. 3. 4.
Код: plaintext 1. 2. 3. 4. 5. 6.
1. матрицу привязки аттрибута к объекту (в данном случае это просто) 2. где и как должна содержаться сама информация? Т.е. в данном случае надо создавать таблицу для каждого аттрибута (с именем attr_name, для примера)? С типом и длинной поля указанного в attr_type/attr_len? 3. добавление/редактирование/удаление информации из аттрибутов для данного объекта. 4. Запросы, реализующие считывание информации по аттрибутам для данного объекта. Реализуема ли даннах схема? И если да, то можно-ли на данном этапе проследить ее подводные камни? Возможно есть другие алгоритмы построения таких структур. Со своей стороны замечу, что будут запросы по каждому аттрибуту объекта. А это значит, что содержать все аттрибуты объекта в едином бинарном поле - не рентабельно. Не хочу на стороне приложения, разбирать их и проверять условия запроса.. Все, максимально должно быть в backend'e. В общем, прошу помочь в реализации алгоритма реализующего данную архитектуру. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2008, 16:20 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
lightspeedстолкнулся с одной задачей. И что-бы не заниматься велосипедостроением, хотел-бы сначала проконсультироваться. ) В соответствие с бизнес-логикой, у компании есть набор предоставляемых ей сервисов. Пусть сервис будет объектом. Данный набор объектов заранее не определен. Т.е. он может изменяться. Далее, у каждого объекта есть набор аттрибутов, который тоже не определен, т.е. может постоянно изменяться. Вопрос в правильном построении архитектуры базы данных/приложения, реализующих данную структуру? Добавлю, что в лоб реализовывать набор таблиц для каждого объекта не считаю правильным. Тем более, что таких объектов намечается больше сотни, для начала. А потом еще больше.. И т.к. аттрибуты объекта постоянно меняются, то делать 'alter table add/drop/rename' - тоже не есть хорошее решение..Здесь многое зависит от конкретики задачи. Есть "универсальный" механизм, который это все может реализовать - это EAV. Но прежде чем его реализовывать - надо сильно подумать - а стоит ли оно такого гемороя? Более простые схемы можно предложить только ели более подробно опишите задачу. Что такое сервисы, какие они бывают, как часто они будут меняться, какая информация хранится в атрибутах... ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2008, 17:18 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Вы информационную систему проектируете или компонент для программиста (оркестровка сервисов)? Бизнес-сущность "Сервис"? Странно. автор у компании есть набор предоставляемых ей сервисов что нужно автоматизировать? - учёт сервисов? - учёт клиентов потребляющих сервисы? - аналитику производства сервисов? ЗЫ. Как правильно сказали, если надо хранить "незнамо что" то берут EAV, но "врагу не пожелаю". Проект устареет раньше чем система будет написана. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2008, 17:40 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
_Pero123ЗЫ. Как правильно сказали, если надо хранить "незнамо что" то берут EAV, но "врагу не пожелаю". Проект устареет раньше чем система будет написана.Не факт. Ограниченное применение EAV иногда бывает полезным. Т.е. если не валить все в EAV, а например использовать динамические характеристики. А уж использовать или нет эту концепцию - нужно конкретно смотреть исходя из требований и ситуации. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2008, 17:47 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Я заранее извиняюсь, мб я не совсем понял проблему топикстартера, но по-моему если взять положим XML файл, то реализация сущностей с переменным составом полей не представляет особой сложности: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2008, 18:26 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
lightspeedСо своей стороны замечу, что будут запросы по каждому аттрибуту объекта. Если так, то предлагаемая вами схема (EAV) загнется очень быстро. Вряд ли она даже миллион объектов потянет с приемлимыми характеристиками. Да и реализовывать собственный "язык запросов" вместо хорошо знакомого всем sql... lightspeedИ т.к. аттрибуты объекта постоянно меняются, то делать 'alter table add/drop/rename' - тоже не есть хорошее решение..А вот тут надо понять, что вы вкладываете в слова "постоянно меняются". Если есть некий классификатор типов и все объекты одного типа имеют одинаковый набор атрибутов, то не вижу особых трудностей с alter table. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2008, 10:22 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
m0nk3yЯ заранее извиняюсь, мб я не совсем понял проблему топикстартера, но по-моему если взять положим XML файл, то реализация сущностей с переменным составом полей не представляет особой сложности:Автор писал, что ему необходим поиск по значениям атрибутов и сделал верный вывод, что "содержать все аттрибуты объекта в едином бинарном поле - не рентабельно". ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2008, 10:23 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Bogdanov Andrey lightspeedСо своей стороны замечу, что будут запросы по каждому аттрибуту объекта. Если так, то предлагаемая вами схема (EAV) загнется очень быстро. Индекс по значению аттрибутов спасет автора ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2008, 10:28 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
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" называется "Кол-во сотрудников". ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2008, 10:43 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
_мод Bogdanov AndreyЕсли так, то предлагаемая вами схема (EAV) загнется очень быстро.Индекс по значению аттрибутов спасет автораБезумству храбрых поем мы песню . ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2008, 10:49 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
BelyСам подход, когда требуется делать ALTER TABLE на лету - несколько коробит.А чем alter table хуже insert into attr_dictionary? Естевственно, если атрибуты каждый пять минут добавляются, то alter не лучшее решение, ну а если "раз в неделю", то никаких проблем. _модИндекс по значению аттрибутов спасет автораПредлагаю самостоятельно провести простенький тест. Берем например, атрибуты "фамилия", "имя", "отчество", "дата рождения" ну и еще десяток по желанию, загоняем миллион лиц и пытаемся найти клиента по фио+дата рождения (типовой вариант идентитфикации физлиц). Смотрим на то как нам помогает индекс (не забудем, что в среднем на одну дату рождения приходится до сотни лиц из миллиона, ну и на одно имя тоже немало). ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2008, 12:18 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Bogdanov Andreyпытаемся найти клиента по фио+дата рождения (типовой вариант идентитфикации физлиц). 4 раза прямой доступ по индексу. Впрочем я не настаиваю - каждая задача имеет свое решение - надо пробовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2008, 12:27 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
_мод4 раза прямой доступ по индексу. Впрочем я не настаиваю - каждая задача имеет свое решение - надо пробовать.Вы в самом деле попробуйте. В теории-то оно все гладко. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2008, 13:21 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Для совсем ленивых привожу тестик - индексы на свой вкус сами добавьте: Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2008, 13:33 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
lightspeedВ соответствие с бизнес-логикой, у компании есть набор предоставляемых ей сервисов. Пусть сервис будет объектом. 1) Сервис->["Опросили интерфейс"]->Получили формализованное описание положили в базу (так например мы работает по протоколам XML-RPC/SOAP 2) Для подобных задач по построению БД с измененяемым набором полей я бы предложил разумно разделить данные на статическую (то что одинаково у всех объектов) и динамическую часть (индивидуальных характеристики) и хранил бы их в неком формализованном виде например XML, тем более что например в ORACLE & MSSQL есть более-менее нормальные механизмы по работе с ним ______________________________________________________ Давайте считать обступившее нас со всех строн коричневое море шоколадным ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2008, 13:44 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
shelsoft2) Для подобных задач по построению БД с измененяемым набором полей я бы предложил разумно разделить данные на статическую (то что одинаково у всех объектов) и динамическую часть (индивидуальных характеристики) и хранил бы их в неком формализованном виде например XML, тем более что например в ORACLE & MSSQL есть более-менее нормальные механизмы по работе с ним Включая XQuery? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2008, 13:55 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
АБВключая XQuery? На без рыбьи сам раком встанешь не забывая о быстродействии и продуктивности ______________________________________________________ Давайте считать обступившее нас со всех строн коричневое море шоколадным ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2008, 21:19 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Я просто хотел воспользоваться случаем и узнать какие именно средства работы с XML эта парочка сейчас способна предоставить в контексте предложенного решения. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2008, 21:21 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
АБэта парочка сейчас 1) Уточните ... дабы это ответ явно не аналитика 2) С точки зрения специалиста объясните анекдот про "цветной телевизор" не удаляясь от теории РСУБД )) ______________________________________________________ Давайте считать обступившее нас со всех строн коричневое море шоколадным ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2008, 21:39 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Послушайте, давайте обойдемся без иносказаний, гипербол, метафор, афоризмов и анекдотов. Я задал простой технический вопрос, хотя вероятно был слишком лаконичен. По моему мнению, для запросов к XML есть хороший язык под названием XQuery, но я не знаю поддерживается ли он в упомянутых СУБД. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2008, 22:28 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
АБобойдемся без иносказаний, гипербол, метафор, афоризмов и анекдотов. 1) Разработчик ПО в любой роли должен знать возможности продуктов занимающих значительное положение на рынке в области обработки структурированных и неструктурированных данных 2) XQuery одна из возможностей работы с неструктурированными данными в реляционных СУБД 3) Чистый оффтоп "Улыбайтесь обо вся дурость на свете делается с серьезным лицом" ______________________________________________________ Давайте считать обступившее нас со всех строн коричневое море шоколадным ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2008, 23:47 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
АБ shelsoft2) Для подобных задач по построению БД с измененяемым набором полей я бы предложил разумно разделить данные на статическую (то что одинаково у всех объектов) и динамическую часть (индивидуальных характеристики) и хранил бы их в неком формализованном виде например XML, тем более что например в ORACLE & MSSQL есть более-менее нормальные механизмы по работе с ним Включая XQuery? включая, но IMHO дорого, сырая технология для РСУБД, медленно, рановато на данном этапе. ЗЫ. Топик смахивает на "Проектирование БД" ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2008, 09:46 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Petro123 АБВключая XQuery? включая, но IMHO дорого, сырая технология для РСУБД, медленно, рановато на данном этапе. Спасибо! Дорого в смысле денег или трудоемкости? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2008, 15:14 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
ну, я одно от другого не отделяю. Некоторые мысли: - разделение атрибутов на часто изменяемые и редко... будет искуственным, т.к. с точки зрения бизнеса этого разделения нет. Соответственно все запросы и представление данных должно это искусственное разделение обратно объединять. - пока в РСУБД XML - инородное образование (есть специальные БД для работы с XML на уровне ядра Системы-ядра БД) - отсюда много ограничений на объединение данных из XML и НЕxml - XML - это только ТРУБОПРОВОД между разными источниками данных, но никак не хранилище их (на данном этапе) - если проектировать на EAV, то под данную структуру БД нет ни одних библиотечных компонентов и библиотек (IMHO). Всё пишется очень долго "с нуля". БД становится импотентом и понятия не имеет что у неё хранится. Вся работа за неё по контролю за непротиворечивостью данных пишется программистом. - это будет плата за требование бизнеса: "у нас всё меняется и нет никаких ограничений". Может это от жадности или непрофессионализма? - хотя есть для EAV (всё в 3-х таблицах) области автоматизации и они подробно освещены в "Проектирование БД". ЗЫ. Мне вот непонятен сам тезис: "В соответствие с бизнес-логикой, у компании есть набор предоставляемых ей сервисов. Пусть сервис будет объектом." Почему я всегда против, чтобы бизнес-аналитик был программистом. :) ______________________________________________ Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде! ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2008, 16:36 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
2 Petro123: Это не от жадности или не профессионализма. Проект - пилотный. Соответственно, все изменения, в том числе и бизнес требований, и требований по дизайну и архитектуре, будут проводиться на нем. Далее, уже на основе этого пилотного проекта (с уже оформленной необходимым образом архитектурой БД и приложения) будет создаваться законченная его версия. Поэтому: 1. Не будет миллионов записей. Только не в пилотнике. Максимально - будут тысячи, ну может десятки тысяч. Все остальное - уже в рабочей версии. 2. При изменениях объектов и аттрибутов в законченной версии, будет производиться версионнинг, (как написал Bely: в рамках усовершенствования проекта). Тем более, что в дальнейшем, кол-во изменений по объектам и аттрибутам будет уменьшаться. Т.е., система в будет стабилизироваться. К сожалению, общее с бизнес-аналитиками проходит довольно сложно, поэтому, дизайн на данный момент - EAV. Хотя я понимаю, что не смотря на свою универсальность и гибкость, это довольно медленный инструмент. Буду строить индексы.. ( З.Ы. Мне проще думать о бизнес-сервисе, как о некотором абстрактном объекте с некоторыми аттрибутами. А рентабельность, производительность и мощность данного бизнес-сервиса, пусть считают бизнес-аналитики.. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2008, 17:13 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
З.З.Ы. Кстати, про XML речи вообще не идет. Согласен с предыдущем оратором (Petro123) - это не есть лучшая среда для хранения данных. На мой взгляд - это наиболее универсальная среда для их передачи. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2008, 17:16 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
lightspeed1. Не будет миллионов записей. Только не в пилотнике. Максимально - будут тысячи, ну может десятки тысяч. Все остальное - уже в рабочей версии.Вы думаете, что если система загнется после того как вы ее доделаете - будет лучше? Мне казалось, что проектируют для того, чтобы система НЕ загнулась. Ни до начала использования, ни в процессе эксплуатации. По поводу количества - один из критических показателей системы - сколько она может держать в себе данных и обрабатывать. Вам (или бизнесаналитикам) надо понимать сколько данных в систему будет загружено при старте + сколько ориентировочно будет создаваться в течении года. Для разных объемов данных - разные решения допустимы. lightspeed2. При изменениях объектов и аттрибутов в законченной версии, будет производиться версионнинг, (как написал Bely: в рамках усовершенствования проекта). Тем более, что в дальнейшем, кол-во изменений по объектам и аттрибутам будет уменьшаться. Т.е., система в будет стабилизироваться.Сам бог велел сделать стабильное ядро со статическими атрибутами + дополнительные атрибуты в EAV (те, которые появились новые). При появлении критических атрибутов - добавление полей в таблицу + переделка форм. lightspeedК сожалению, общее с бизнес-аналитиками проходит довольно сложно, поэтому, дизайн на данный момент - EAV. Хотя я понимаю, что не смотря на свою универсальность и гибкость, это довольно медленный инструмент. Буду строить индексы.. (Как только встанет задача "Загрузить пару миллионов объектов из старой системы" - придется строить не индексы, а планы по смене работы... Так что, возможно, вам проще будет сделать EAV структуру, внести в нее пару миллионов записей (тестовых), подготовить отчет по этой структуре и показать бизнес-аналитикам как он быстро будет работать. Вдруг, они тоже окажутся заинтересованы в том, чтобы система не закончилась на пилотном проекте :) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2008, 18:17 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
аффтар! Вы не поняли, что у EAV низкая скорость - не самый главный минус? EAV будет дороже в разы! А если захотите вернуться, то придётся переписать всё на клиенте и всё на сервере. Спросите хотя бы у программистов (у меня был не пилотный проект на нём, а реальный). Bely +1 Удачи Вам! ЗЫ. Кажется мне, что из за плохого контакта с бизнес-аналитиками, в угоду кажущейся простоте (добавления нового атрибута в БД), архитектор Системы может принять неверное решение. По крайней мере, доводов от бизнеса в том что атрибуты меняются каждый день - я не увидел. ______________________________________________ Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде! ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2008, 19:27 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Ну я б не сказал что это ТАК уж дорого. Мы это делали еще когда слова такого не было EAV. И даже с наследованием атрибутов. И тоже не в пилоте, а в промышленной системе, причем тиражируемой. Работает у клиентов годами уже. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2008, 19:39 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Petro123разделение атрибутов на часто изменяемые и редко... будет искуственным, т.к. с точки зрения бизнеса этого разделения нет. Соответственно все запросы и представление данных должно это искусственное разделение обратно объединять. 1) Сударь мой разделение атрибутов "на часто изменяемые и редко" действительно искуственно 2) А вот на "значимые и незначимые" давно и успешно применяются (см ПрАце.Ру, Яндекс-Маркет и т.д. - хАчу вот такой теливизор только желтый") 3) Разделение атрибутов на "значимые и незначимые" возможно только после анализа - какой объем записей мы должны будем обработать после поиска по "значимым" атрибутам и хороше выполненной методики по вводу в базу всех данных 4) То что сказано выше достаточно сильно упирается в предметную область в которой реализуется проект ______________________________________________________ Давайте считать обступившее нас со всех строн коричневое море шоколадным ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2008, 21:08 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
АБНу я б не сказал что это ТАК уж дорого.... Не дорого, потому что в ИТ индустрии нет чётких расценок на те или иные виды работ. В общей куче договора что 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 в одном поле сразу все типы данных. Программист может всё, только кому это надо... (с) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2008, 22:43 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Petro123Скока будет делать программист данную форму, если из БД идёт... Мы сделали одну форму, на которую дополнительные атрибуты выводятся столбиком: атрибут-значение. С этой формой пришлось повозиться, но после этого прошлись по имеющимся формам и просто в каждой добавили переход на форму атрибутов. Это как вы понимаете минутное дело. Не самый лучший интерфейс? Согласен. Но достаточно хороший - пользователи претензий не предъявляют. Кроме этого понятно пришлось кое-что сделать в отчетности, но тоже - не смертельно. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 11:54 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
АБНе самый лучший интерфейс? Согласен.Вместо инструмента вы им дали конструктор. Выучили бы их языку SQL, может вобще интерфейс писать не пришлось... По поводу не жалуются - я видел организации, у которых стояла глюкавая система учета документов, поэтому им приходилось документ сперва регистрировать в тетрадке (записывали на бумаге), потом в отдельном экселевом файле, а потом уже в учетной системе. И ничего - тоже люди не жаловались... ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 12:07 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Bely АБНе самый лучший интерфейс? Согласен.Вместо инструмента вы им дали конструктор. Выучили бы их языку SQL, может вобще интерфейс писать не пришлось... По поводу не жалуются - я видел организации, у которых стояла глюкавая система учета документов, поэтому им приходилось документ сперва регистрировать в тетрадке (записывали на бумаге), потом в отдельном экселевом файле, а потом уже в учетной системе. И ничего - тоже люди не жаловались... Не надо инсинуаций - конструкторы, SQL и тетрадки тут не при чем. Пользователь видит строго типизированные атрибуты, заданные для выбранного объекта на уровне метаданных. Просто расположены они на экране не в оптимаотном с точки зрения эстетики и эргономики порядке, а в столбик один под другим. Смысл использования EAV ведь не в том, чтобы избавиться от необходимости расширять схему БД. Что толку, если при добавлении атрибута придется переписывать все формы? Что схема, что формы в конечном итоге сводятся к трудозатратам. В нашей реализации можно свободно добавлять атрибуты, не трогая ни схему, ни формы. Спросите у пользователя, что он предпочтет - пожертвовать качеством интерфейса или избавиться от зависимости от программистов, от затрат на переделки и от задержек между возникновения необходимости в появлении нового атрибута и возможностью работы с ним. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 12:25 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
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 для данной таблицы.. Если кто-то проследил за моей мыслью, буду рад пообщаться.. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 13:16 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
lightspeed...создаются объекты, создаются аттрибуты, которые "привязываются" к этим объектам. А далее, по ним создается таблица... Не это ли примерно реализовано в 1С? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 13:20 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
АБПользователь видит строго типизированные атрибуты, заданные для выбранного объекта на уровне метаданных. Просто расположены они на экране не в оптимаотном с точки зрения эстетики и эргономики порядке, а в столбик один под другим.Вот у нас в форме организации - 27 основных видимых полей + с десяток - системных, еще есть возможность добавлять признаки из классификатора (по типу EAV) - нормальная ситуация, если таких признаков - 5-6, еще телефоны... 3-4 телефона, причем телефоны тоже разбиты и структурированы (код, телефон, тип телефона, extention-примечание). Еще к организации пристыкованы люди - 3-4 человка в среднем (есть и по 20-30 человек ворганизации). У каждого человека: Фамилия, Имя, Отчество, Пол, Персональный телефон, Долджность (по классификатору - 3 поля), день рождения, Дата последнего контакта с человеком. Я насчитал (без детализации телефонов и персон) - на каждую организацию: около 45 строк атрибутов. И всю эту информацию человек должен увидеть, понять что к чему, сделать какие-то действия и обработать. Такие формы (как вы написали) применимы только для простых задач. А в 45 строках абсолютно разнородной информации - человек просто потеряется. Представлени EAV хорошо для описаний в интернет магазинах В обработке данных - это будет просто смерть. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 14:41 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
АБ lightspeed...создаются объекты, создаются аттрибуты, которые "привязываются" к этим объектам. А далее, по ним создается таблица... Не это ли примерно реализовано в 1С? +1 либо ORM - маппинг объектов-класов в РСУБД. 10 раз отмерь, а потом программируй. Ведь "пилотник"можно делать на каждом уровне. Я вот тут не увидел бизнес-логику при хранении данных. У ас просто учётная система? Учесть(сохранить) изменяющиеся атрибуты? Если атрибут добавить так легко, то откуда появится код обслуги данного атрибута? Тоже вручную будете городить в триггере на 1млн.записей атрибутов НА ОДНУ таблицу. Там подводных камней масса. Я бы внятного ТЗ от "бизнесменов" попросил. Или концепции на 3-х страницах. Потом они так-же и скажут: "а нам всё равно как вы это ТУДА засунете". ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 14:52 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
BelyА в 45 строках абсолютно разнородной информации - человек просто потеряется. Вы бы еще сделки в эту кучу добавили и спецификации по ним - тогда не 45, а 450 строк получится. Организация - это один объект со своими атрибутами, контакты - другой, сделка - третий; мне бы в голову не пришло показывать их одним списком. Кстати, любой желающий может посмотреть как изменяемый набор полей реализован у salesforce. Судя по тому, что пользователь сам может добавить атрибут, подозреваю, что они использовали EAV. На форму атрибут пользователь добавляет тоже сам, мышкованием. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 15:03 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
АБКстати, любой желающий может посмотреть как изменяемый набор полей реализован у salesforce. Судя по тому, что пользователь сам может добавить атрибут, подозреваю, что они использовали EAV. На форму атрибут пользователь добавляет тоже сам, мышкованием.Не знаю, как это сделано в SalesForce, но в Support Wizard (система для HelpDesk) это реализовано через ALTER TABLE, TerrasoftCRM - ALTER TABLE, ITG Mercury - через список предопределенных полей + метаданные (как я писал ранее), в MS CRM - кажется тоже, через ALTER TABLE. И во всех этих системах пользовательские формы - настраиваемые и не представляют собой простой список атрибутов. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 15:10 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
АБВы бы еще сделки в эту кучу добавили и спецификации по ним - тогда не 45, а 450 строк получится. Организация - это один объект со своими атрибутами, контакты - другой, сделка - третий; мне бы в голову не пришло показывать их одним списком.Тогда вопрос - где человек увидит связанную информацию (телефоны, персоны, адреса, сделки, историю итп.)? Или для того, чтобы получить общую информацию надо открыть 5-10-20 форм? Особенно интересен становится просмотр всех людей, которые числятся за организацией... как это у вас реализовано? или просто разворачиваете EAV в плоскую таблицу для представления в гриде? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 15:14 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
BelyИ во всех этих системах пользовательские формы - настраиваемые и не представляют собой простой список атрибутов. В отличие от перечисленных Вами систем, salesforce предоставляется по принципу SaaS, через Интернет. Я как-то с трудом могу себе представить, что в системе, в которой один инстанс обслуживает тысячи организаций, что-то может делаться через добавление новых таблиц. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 15:15 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Petro123Я вот тут не увидел бизнес-логику при хранении данных. У ас просто учётная система? Учесть(сохранить) изменяющиеся атрибуты? Если атрибут добавить так легко, то откуда появится код обслуги данного атрибута? Тоже вручную будете городить в триггере на 1млн.записей атрибутов НА ОДНУ таблицу. Там подводных камней масса. Я бы внятного ТЗ от "бизнесменов" попросил. Или концепции на 3-х страницах. Потом они так-же и скажут: "а нам всё равно как вы это ТУДА засунете".+1 Информации недостаточно. Расскажите больше о задаче. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 15:16 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Belyгде человек увидит связанную информацию (телефоны, персоны, адреса, сделки, историю итп.)? Или для того, чтобы получить общую информацию надо открыть 5-10-20 форм? Не понял, Вы хотите увидеть все это на одной форме? Боюсь, разговор становится беспредметным... ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 15:17 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
АБВ отличие от перечисленных Вами систем, salesforce предоставляется по принципу SaaS, через Интернет. Я как-то с трудом могу себе представить, что в системе, в которой один инстанс обслуживает тысячи организаций, что-то может делаться через добавление новых таблиц.В свое время лично занимался введением с трой в IBS (DataFort) в 2001 году системы SupportWizard в качестве ASP сервиса. Не знаю чем это закончилось, но SuportWizard - можно предоставить как сервис. По поводу ITG - Mercury: тоже таботает через WEB интерфес. Предоставляет ли кто-нибудь его в аренду - не знаю. МТС, с которым мы работали - просто купил несколько лицензий для себя. Но сдавать его в аренду - тоже можно. Да сдавать в аренду - можно все что угодно... в DataFort был проект по сдаче в аренду даже Navision (2001 год). Люди просто заходили через терминальный сервис и работали. Так что - не аргумент. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 15:24 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
АБНе понял, Вы хотите увидеть все это на одной форме? Боюсь, разговор становится беспредметным...Человеку для принятия решения надо увидеть: Общую информацию по организации, список телефонов организации, список сотрудников организации, пара адресов. Типичный набор полей в любой CRM. Как он в вашей системе все это увидит? Вот надо ему позвонить главным бухгалтерам с организациями с просрочкой платежей и выяснить - дошли ли счета, правильный адрес ли стоял в письме, которое отправили по почте. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 15:30 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Другой вариант я видел у Paul Nielsen'a - попытка создать объектную БД на основе реляционной. Если не изменяет память, со следующими возможностями: -наследовать классы и задавать ассоциации между ними -добавлять атрибуты, при этом на автомате создаются или изменяются просмотры для селектов и процедуры для update со всеми полями класса Ссылку посял, но есть исходники с тестовым примером. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 15:30 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
BelyЧеловеку для принятия решения надо увидеть: Общую информацию по организации, список телефонов организации, список сотрудников организации, пара адресов. Типичный набор полей в любой CRM. Как он в вашей системе все это увидит? Вот надо ему позвонить главным бухгалтерам с организациями с просрочкой платежей и выяснить - дошли ли счета, правильный адрес ли стоял в письме, которое отправили по почте. Пример никудышний - это все должно быть в статических полях. Но нормально он все видит, не переживайте. Не на одной форме, но и не на 20. Проходит по 2-3 формам и все что ему надо видит. Собственно, это экспериментальный факт - напоминаю, речь идет о промышленной системе, находящейся в эксплуатации годами в разных организациях. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 15:37 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
BelyЧеловеку для принятия решения надо увидеть: Общую информацию по организации, список телефонов организации, список сотрудников организации, пара адресов. Типичный набор полей в любой CRM. Как он в вашей системе все это увидит? Вот надо ему позвонить главным бухгалтерам с организациями с просрочкой платежей и выяснить - дошли ли счета, правильный адрес ли стоял в письме, которое отправили по почте. В Net'e можно реализовать свой ITypedList, в компонентах DevEpress пользователь сам может добавлять поля в формы и гриды.Попутно на основе метаинформации не кто не запрещает реализовать специально обученные билдеры. Сам присматриваюсь к этой проблеме.Подход shelsoft с разделением на статическую и динамическую части, считаю наиболее оптимальным.Каким образом хранить последнюю еще в раздумьях. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 16:02 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
lightspeedВот ответ от бизнеса: "..меня не волнует что у тебя и как там работает. Мне нужен интерфейс позволяющий динамически изменять необходимые параметры объектов в соответствие с заданными критериями.."А не могли бы вы расшифровать сию загадочную фразу? Что значит "динамически изменять в соответствие с критериями"? Кто и в какой форме эти критерии задавать будет? Кто и как будет программировать логику использования использования "динамически измененных параметров"? АБВ нашей реализации можно свободно добавлять атрибуты, не трогая ни схему, ни формы. Спросите у пользователя, что он предпочтет - пожертвовать качеством интерфейса или избавиться от зависимости от программистов, от затрат на переделки и от задержек между возникновения необходимости в появлении нового атрибута и возможностью работы с ним.А какие возможности работы с атрибутом кроме "сохранить/посмотреть" возникают у пользователя? И кто программирует эти возможности? И нужен ли для этого EAV? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 16:15 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
SeVa в компонентах DevEpress пользователь сам может добавлять поля в формы и гриды. ===== каким образом? Правая кнопка - меню - добавить Поле:ЗадолженностьКонтрагента? :) Попутно на основе метаинформации не кто не запрещает реализовать специально обученные билдеры. ======= время на разработку такого фреймворка-конструктора? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 16:43 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
BelyТогда вопрос - где человек увидит связанную информацию (телефоны, персоны, адреса, сделки, историю итп.)? Или для того, чтобы получить общую информацию надо открыть 5-10-20 форм? Объект может иметь сложную стр-ру, когда св-во объекта - это список. Ессно для работы с такими св-ми открываются самостоят. подформы внутри формы объекта. Все это на EAV. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 16:44 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Bogdanov Andrey АБВ нашей реализации можно свободно добавлять атрибуты, не трогая ни схему, ни формы. Спросите у пользователя, что он предпочтет - пожертвовать качеством интерфейса или избавиться от зависимости от программистов, от затрат на переделки и от задержек между возникновения необходимости в появлении нового атрибута и возможностью работы с ним.А какие возможности работы с атрибутом кроме "сохранить/посмотреть" возникают у пользователя? И кто программирует эти возможности? И нужен ли для этого EAV? Ну если так подходить, то что, в конечном счете, делает любая учетная система? Сохранить/посмотреть. А также поискать и посчитать кое-что и кое-что напечатать. Мне кажется непрактичным стремление некоторых участников дискуссии реализовать в работе с динамическими атрибутами максимальную функциональность - ту же, что и со статическими. Не окупится. Мы в свое время сделали довольно скромную реализацию, и то наверное переусложнили: без наследования можно было обойтись. Хотя конечно оптимальный компромисс зависит от конкретики задачи, в частности, от объемов и от ожидаемого соотношения между статическими и динамическими атрибутами. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 16:47 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Bogdanov Andreyкакие возможности работы с атрибутом кроме "сохранить/посмотреть" возникают у пользователя? И кто программирует эти возможности? И нужен ли для этого EAV? Хороший вопрос. Ессно новый атрибут можно сразу вводить, изменять + использовать в отчетах + в пользовательских формулах при расчетах чего-там, ну и .т.д. Без EAV как-то плохо. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 16:48 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
авторв компонентах DevEpress пользователь сам может добавлять поля в формы и гриды. ===== каким образом? Правая кнопка - меню - добавить Поле:ЗадолженностьКонтрагента? :) Попутно на основе метаинформации не кто не запрещает реализовать специально обученные билдеры. ======= время на разработку такого фреймворка-конструктора? В Девках такой функционал заложен в компоненты изначально(пользователь в рантайме может добавлять, удалять поля).При вызове метода в компоненте, появляется окно со списком полей, которые не задействованы.Простым драг&дроп в нее или из нее поля убираются,или добавляются в компонент.В этом плане ничего не нужно реализовывать.Также можно сохранить/восстановить текущий вид с учетом текущей версии программы. Что подрузумевается по framework'ом? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 17:16 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
SeVa В Девках такой функционал заложен в компоненты изначально(пользователь в рантайме может добавлять, удалять поля).При вызове метода в компоненте, появляется окно со списком полей, которые не задействованы.Простым драг&дроп в нее или из нее поля убираются,или добавляются в компонент.В этом плане ничего не нужно реализовывать.Также можно сохранить/восстановить текущий вид с учетом текущей версии программы. это всё НЕ для EAV. У EAV классического - ОДНО поле КодАтрибута и второе поле ЗначениеАтрибута (или код перечислимой характеристики). Добавление атрибута, это добавка СТРОКИ, причём все типы данных переводятся в variant либо строчный тип. Так что в EAV добавление поля тебе не поможет (если ты не разворачиваешь данные в нормальный вид) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 18:39 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
АБ Мне кажется непрактичным стремление некоторых участников дискуссии реализовать в работе с динамическими атрибутами максимальную функциональность - ту же, что и со статическими. Не окупится. +1 если просто учёт-перечень сервисов, с минимальной бизнес-логикой (например, без истории изменения или редактирования сервиса) то можно и EAV. - если компания с ними проводит какие-нибудь операции, существуют стадии, состояния сервиса - то нет. Обычно в БД таблица - это бизнес-сущность. Между ними достаточно сложные взаимосвязи и действия реализованные в триггерах, хранимых процедурах, связях на уровне БД, FK, ограничениях и т.д. Здесь предложение одно - объект один - сервис. Как и что с ним происходит во время деятельности компании - пусть дядя Вася автоматизирует. Нонсенс IMHO (вся ИС - справочник товаров, тьфу сервисов) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 18:51 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
2 Petro123: Petro123 Обычно в БД таблица - это бизнес-сущность. Между ними достаточно сложные взаимосвязи и действия реализованные в триггерах, хранимых процедурах, связях на уровне БД, FK, ограничениях и т.д. Здесь предложение одно - объект один - сервис. Как и что с ним происходит во время деятельности компании - пусть дядя Вася автоматизирует. Нонсенс IMHO (вся ИС - справочник товаров, тьфу сервисов) Интересно, с чего вы это взяли? С того что я вам не описал полную архитектуру системы??? Я и не собирался этого делать. В этом топике меня интересует только не большая ее часть. Архитектура некоторого динамичного справочника. Ничего больше. Поэтому, не зацикливайтесь на том, что-бы сделать что-то большее того, что я описал. Размеры справочника я сообщал. Первоначально будет порядка сотни объектов, и порядка 400 аттрибутов. Общее количество записей на начальном этапе составит примерно 400000. И так-как в дальнейшем, количество объектов и аттрибутов будет изменяться, мне нужен в пилотном проекте, некий динамичный конструктор(бд/приложение) для этого справочника. Но, при таком объеме (по вашим же словам), использование EAV в базе данных будет тормозить, плюс сложность реализации самого приложения. Ок. Я сделал для себя вывод. И пока склоняюсь к собственной архитектуре, описанной мной в предыдущем посте. Не знаю уж делали ее в 1С или нет.. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 19:19 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Petro123если просто учёт-перечень сервисов, с минимальной бизнес-логикой (например, без истории изменения или редактирования сервиса) то можно и EAV. - если компания с ними проводит какие-нибудь операции, существуют стадии, состояния сервиса - то нет. Согласен, но чисто для полноты картины - в принципе и в этом случае можно держать текущее состояние в EAV, а стадии и состояния - в контексте бизнес-процесса BPM-системы. Есть положительный опыт: наличие BPM-системы позволяет упростить базу - не отслеживать смену состояний, не держать в базе данные, которые заведомо интересны только пока процесс исполняется. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 19:23 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
lightspeedЯ сделал для себя вывод. И пока склоняюсь к собственной архитектуре, описанной мной в предыдущем посте. Не знаю уж делали ее в 1С или нет.. морочили голову, а оказывается речь вообще идет про 1С. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 19:58 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
_модиспользовать в отчетах + в пользовательских формулах при расчетах чего-там, ну и .т.д. Без EAV как-то плохо.Собственно это все и есть уже программирование. Да, простенькое, на уровне продвинутого пользователя. И как раз EAV очень сильно усложняет этот процесс. Без EAV отчеты в нормальном репортере даже блондинки свять способны. А чуть более продвинутые пользователи на ура SQL пользуют (если не напрямую, то с использованием удобных графических квери-билдеров). Использование же EAV практически убивает возможность использования при работа с БД чего-либо кроме поделок, поставляемых разработчиком вместе со своим EAV. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 23:06 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
provid lightspeedЯ сделал для себя вывод. И пока склоняюсь к собственной архитектуре, описанной мной в предыдущем посте. Не знаю уж делали ее в 1С или нет.. морочили голову, а оказывается речь вообще идет про 1С. Да нет.. Это просто вы не умеете читать.. Что вы здесь вообще делаете??? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 23:17 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
раунд 3-ий заключительный ;) ?! авторТак-же есть набор аттрибутов, так-же заранее не определенный, (адрес, время работы, телефон, наименование, и т.д.) возьмём адрес. Вы спрашивате про подводные камни? Опишите часть требований к ПОДсистеме для работы с атрибутом адрес. Просто строка/почтовый/юридический/из справочника/контроль правильности ввода/запросы с агрегированием/ Будет ли у Вас атрибуты: Арес1 Адрес2 и нужно ли в отчётах будет распологать Адрес2 за Адресом1? Требуется ли от ПодСитсемы отвечать на запросы с SUM, MAX и т.д.? Предпологаются ли перечислимые характеристики-атрибутов? (большой-маленький, 0,5-1,2 ....)? Механизм их создания, правки, удаления Ваш прототип IMHO должен будет ответить на все эти вопросы. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2008, 23:59 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
_модОбъект может иметь сложную стр-ру, когда св-во объекта - это список. Ессно для работы с такими св-ми открываются самостоят. подформы внутри формы объекта. Все это на 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.
или вобще - затягиваем данные в память клиентского компьютера и дальше изображаем из себя SQL машину (сортировки, фильтры, джоины)? как именно? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2008, 00:23 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Рискну предложить еще два варианта для обсуждения. Интересно будет услышать мнение других. 1) Еспользование sys.Anydata для хранения значений. Из минусов когда пробывал в 10g хранить LOB данные, хоть в документации и есть соответсвующая фукция она не работает. 2) Если у вас известно количество атрибутов на начальном этапе то можно создать таблицу с набором универсальных колонок кажого основного типа и таблицу для с описание в какой колонке для данного типа сервиса храница определенный атрибут. На основе этой таблички строить динамическиt SQL Производительность будет максимальна. NULL как известо места не требует. Если количество атраибтов превысит аксимальное количство калонок построить еще таблицу с отношением 1 к 1 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2008, 03:18 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
немного оффтопа по сабжу)) насколько я понял по существу рассматривается вопрос о реализации ООП средствами реляционной СУБД а это упрется в разработку языка для работы постоянными (persistent) объектами компилятора для него (или как минимум транслятора в язык SQL) http://www.ibase.ru/devinfo/oop_rdbms.htm по моему это слишком большая задача и судя по инофрмации в инете эту проблему пытаются безуспешно (под успехом я понимаю получение такой же рапространенности как и реляционные СУБД) крупные исследовательские компании уже довольно долго, persistent objects хотя потребность в подобных системах все растет и растет интересно чем это все дело кончится мне начинает казаться, что системы для работы с постоянными объектами требуют иного вида хранилищ, чем реляционные базы. и еще ООП ведь не панацея - вот посмотрите сами мы пытаемся не сколько реализовать технологию сущность-атрибут, а сколько внести большую структурированность в табличные базы! А в этой области тоже достаточно много наработок. ну например http://www.ibase.ru/devinfo/treedb.htm и что? куча частностей, а общей теории нет (опять таки сравнивайте с РБД) так что, если практика заходит в тупик физик обычно идет к математику (мол что у тебя там нового)) ), так не пора ли обратиться что там ученые понаразработали)) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2008, 08:55 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Bogdanov AndreyИспользование же EAV практически убивает возможность использования при работа с БД чего-либо кроме поделок, поставляемых разработчиком вместе со своим EAV. Это верно, но такие "поделки" как раз и называются FW. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2008, 09:31 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Belyкак именно? Поскольку obj_id известен, то подсписки формируются просто по obj_id и имени этого подсписка, ведь это один атрибут-таблица. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2008, 09:42 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
sherzod_по существу рассматривается вопрос о реализации ООП средствами реляционной СУБД Нет, речь идет о системах, ориентированных на конечного пользователя, когда он может самостоятельно менять бизнес-логику, структуру данных - практически все. Вот для них и применяется EAV. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2008, 09:45 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
_модЭто верно, но такие "поделки" как раз и называются FW.Я не против поделок. Некоторые из них даже весьма удобны и удачны. Правда то, что каждый разработчик прикладной системы начинает с разработки собственного FW, наверное не свосем верно. Но это уже личное дело разработчика и того, кто ему труд оплачивает. Я против того, чтобы "результатом" этого FW был уродец под названием EAV, так как этот уродец резко ограничивает пользователя по возможности использования чего-то еще кроме поделки. Сейчас существует довольно много удобных средств для отчетности, аналитики или выгрузки данных из реляционными СУБД. И постоянно появляются новые. Прикрутить какой-нибудь OLAP к EAV базе становится нетривиальной для пользователя задачей. Ну а если способностей (или времени) хватает только на FW с EAV, то не стоит за такое браться. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2008, 09:54 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
_модПоскольку obj_id известен, то подсписки формируются просто по obj_id и имени этого подсписка, ведь это один атрибут-таблица.Вы не поняли - как именно данные попадают в грид? посредством хитрого SQL запроса? или запихиваете в грид данные на клиенте? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2008, 10:10 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Еще раз перечитал начальный пост(раньше по диагонали). Весь требуемый функционал реализован в 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'ов с параметрами. Думаю, в качестве прототипа(или посмотреть на подход) и оценки производительности сойдет. Исходники есть. Тестовый скрипт вложил ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2008, 14:26 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Bogdanov Andrey Я против того, чтобы "результатом" этого FW был уродец под названием EAV, так как этот уродец резко ограничивает пользователя по возможности использования чего-то еще кроме поделки. EAV - это способ создания систем для конечного пользователя ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2008, 16:24 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Belyкак именно данные попадают в грид? посредством хитрого SQL запроса? Да, и не очень хитрого. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2008, 16:25 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Такие "уродцы" неплохо иметь для пилотных проектов,во время разработки и для полукоробочных вариантов. При методе - с шашками на танки, постоянно возникает необходимость прикрутить какой-нибудь атрибут, а это тормозит процесс.Поэтому приходится тоже ковырять подобный вариант. 2 Petro, в результате будут строго типизированные объекты, что такое EAV,что нужно для нормальной работы компонентов форм, я имею представление ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2008, 16:49 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
_модEAV - это способ создания систем для конечного пользователяНе согласен. Во-первых, Конечному пользователю динамические атрибуты в подавляющем большинстве случаев не нужны. Они могут быть нужны технологу. А во-вторых, даже для поддержки динамических атрибутов есть лучшие способы создания систем. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2008, 19:27 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
SeVaЕще раз перечитал начальный пост(раньше по диагонали). Весь требуемый функционал реализован в SQL Server O/R Hybrid Database ... очень хотелось бы посмотреть на эту систему но она недоступна(сайт досутпен - система не скачивается). url not found on server если кто нибудь скачал просьба слейте на мыло. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2008, 08:39 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
если нужно что-то работающее, то нужно просто добавлять в таблицу объекта столько атрибутов, сколько требуется. Если для экспериментов, то можно и EAV и т.п. При наличии свободного времени и шарового финансирования. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2008, 09:39 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
SeVaТакие "уродцы" неплохо иметь для пилотных проектов,во время разработки и для полукоробочных вариантов. При методе - с шашками на танки, постоянно возникает необходимость прикрутить какой-нибудь атрибут, а это тормозит процесс.Поэтому приходится тоже ковырять подобный вариант. 2 Petro, в результате будут строго типизированные объекты, что такое EAV,что нужно для нормальной работы компонентов форм, я имею представление -1 "во время разработк" не надо бегать "с шашками на танки". Есть отработанные технологии, когда без всякого EAV время добавления нового атрибута составляет 30 мин. в БД и 1 час на клиенте. Нужно хорошо подумать, чтобы вместо отработанной методологии написать свой слой в БД, свой слой в поставщике данных и свой слой в представлении данных. Причём квалификация программиста должна быть выше среднего, т.к. он просто будет брать ВСЕ данные на клиента и перебирать их в цикле, чтобы найти нужный атрибут и вычислить среднее. Готовые решения можно взять, но писать своё? Безумству храбрых поём мы песню (с) SeVa 2 Petro, в результате будут строго типизированные объекты, что такое EAV,что нужно для нормальной работы компонентов форм, я имею представление вы о чём? Мы это и обсуждаем. ЗЫ. Почти похожая ситуация наблюдается с деревьями в РСУБД. Понятно, что БД деревья хранить не умеет, но: - методология хранения в БД - есть: - все запросы для манипулирования структурой дерева - есть и отработаны - поддержка на уровне БД (добавляется в последнее время и старших версиях) - клиенские библиотеки для отображения и редактирования деревьев - есть и отработаны. В том числе по скорости (виртуальное дерево, где листья грузятся по мере просмотра) Для EAV есть только первый пункт, со всем остальным разработчик тра...ется самостоятельно. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2008, 10:48 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
2 Petro123: Petro123... авторТак-же есть набор аттрибутов, так-же заранее не определенный, (адрес, время работы, телефон, наименование, и т.д.) возьмём адрес. Вы спрашивате про подводные камни? Опишите часть требований к ПОДсистеме для работы с атрибутом адрес.. ...Ваш прототип IMHO должен будет ответить на все эти вопросы. Все это замечательно, за исключением того, что аттрибуты объектов - динамичны. Или, вы предполагатете заняться data mining'ом и создавать концепт на каждый полученный аттрибут??? Думаю, это не реально в условиях динамичного добавления и изменения объектов и аттрибутов, конечными пользователями (читай - _разными_ специалистами (в различных областях знаний и бизнеса, компания - холдинг), которым необходимы _разнородные_ объекты и аттрибуты. Соотвественно, аттрибут "адрес" - имеет _различное_ понимание у того или иного специалиста.. 2 provid: Код: plaintext 1.
В очередной раз убеждаюсь, что вы не умеете читать.. ( Далее.. Может кто-то подскажет по проблемам и хинтам текущей модели, на которой я остановился? Код: plaintext 1. 2. 3.
Может кто работал с данной моделью? А то общение сместилось немного.. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2008, 17:32 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
авторСоотвественно, аттрибут "адрес" - имеет _различное_ понимание у того или иного специалиста.. - т.е. даже так? Классификатора атрибутов не будет? Один введёт атрибут "Адрес", другой "Адресс", третий "адрес". А в таблице значений не код атрибута, а его строковое имя (понимаемое каждым по разному). - правильности ввода значения для какого либо атрибута не будет? и т.д. Тогда лучше сканы в jpeg из записной книжки стенографистки хранить. ... Никаких требований нет, окромя "можно добавить в подсистему". Внятные запросы к такому справочнику сервисов тоже под вопросом. авторИли, вы предполагатете заняться data mining'ом я предлагаю озвучить требования, цель и концепцию ИС, а не заниматься гаданием на кофейной гуще. Часто оказывается, что решение лежит совсем в другом месте. Пока вы озвучили одно требование - динамическое добавление пользователем атрибутов объектов. А сервис - это объект, т.к. это ВАМ удобнее. 2. По поводу модели, на которой Вы остановились - ничего не понятно. "ООП на клиенте плохо скрещивается с РСУБД" ЗЫ. Если Вы ораклист, можно ещё попытаться в БД объектами и наследованием баловаться. Если времени вагон. ______________________________________________ Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде! ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2008, 22:29 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
lightspeed2 provid: Код: plaintext 1.
В очередной раз убеждаюсь, что вы не умеете читать.. ( я еще и писАть умею. Впрочем никто никого ни в чем не ограничивает. У вас право выбора. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2008, 23:02 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
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 ЗЫ. Если Вы ораклист, можно ещё попытаться в БД объектами и наследованием баловаться. Если времени вагон. Да. Ораклист. Т.ч. уже думаю по объекты и наследование. Впрочем, писать систему не мне. А я лишь пытаюсь разработать наиболее удачную архитектуру. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2008, 05:41 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
lightspeed Постарайте прочесть текст из этого абзаца выше, не по диагонали. И вы достигните просветления.. ) я бы, на вашем месте, специальным образом на тексте выше внимание не акцентировал. А то и правда у всех наступит просветление и они начнут создавать таблицы объектов по количеству пользователей. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2008, 09:26 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
авторНе так. Я говорил про различные типы значений аттрибута Адрес. Который есть един и неделим. ) Например, один специалист должен хранить формат Адрес, скажем в текстовой строке, без выделения, скажем улицы, дома, корпуса, офиса, и индекса. А другому нужно это выделение.. А у третьего, это вообще выбор из справочника адресов.. Или еще, вот есть аттрибут "Дата начала": один хранит его в формате 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С хороша, но у меня жена глав-бух не сама там программирует и вводит атрибуты, а меня зовёт :). - доработка данной системы в процессе эксплуатации будет неглюкавее, дешевле и быстрее авторА я лишь пытаюсь разработать наиболее удачную архитектуру - займитесь ВИ, в паре с разработчиком БД (они в другом форуме сидят) ______________________________________________ Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде! ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2008, 10:58 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
ROT EAV плюсы и минусы ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2008, 11:34 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
lightspeedМожет кто работал с данной моделью? Плохая модель - объект может иметь сложную ст-ру и не влезать в одну таблицу. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 09:49 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Bogdanov AndreyВо-первых, Конечному пользователю динамические атрибуты в подавляющем большинстве случаев не нужны. Они могут быть нужны технологу. А во-вторых, даже для поддержки динамических атрибутов есть лучшие способы создания систем. 1. Под конечным пользователем как раз и понимается технолог. 2. М.б., но я не встречал ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 09:51 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
_мод2. М.б., но я не встречалНу тогда советую ознакомиться, а потом EAV защищать. Даже в этой теме примеры систем уже упоминали. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 10:12 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Petro123ROT EAV плюсы и минусы Все верно, вот только вопрос - почему "Возможность увеличивать количество классов без увеличения количества таблиц" является преимуществом? По всей видимости, есть какое-то подспудное мнение, что создавать таблицы - нехорошо. Не мог ли бы мне кто-нибудь из участников дискуссии объяснить что в этом нехорошего? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 10:21 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Bogdanov Andrey Petro123ROT EAV плюсы и минусы Все верно, вот только вопрос - почему "Возможность увеличивать количество классов без увеличения количества таблиц" является преимуществом? По всей видимости, есть какое-то подспудное мнение, что создавать таблицы - нехорошо. Не мог ли бы мне кто-нибудь из участников дискуссии объяснить что в этом нехорошего? суть вопроса только в том, что любое увеличение числа таблиц или полей требует доработки системы. Эти доработки могут даваться таким трудом, что разрабочик вынужден искать путь возложения на пользователя возможности самостоятельного расширения атрибутного состава. Так и рождаются EAV и компания. Если же добавление атрибута в таблицу или создание новой таблицы (со всем окружением в виде форм и т.д.) требуют умения грамотно написать имя таблицы, то мыслей изобретать универсальные, но сложные и неповоротливые архитектуры - просто не возникает. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 10:29 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Bogdanov AndreyНе мог ли бы мне кто-нибудь из участников дискуссии объяснить что в этом нехорошего? Для того чтобы уже существующие программы подхватили новый объект(таблицу, столбец) они изначально должны быть написана на динамическиом SQL и использовать словарь БД - таких систем я лично не видел. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 12:02 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
авторДля того чтобы уже существующие программы подхватили новый объект(таблицу, столбец) они изначально должны быть написана на динамическиом SQL и использовать словарь БД - таких систем я лично не видел. Совершенно необязательно.В варианте,который я приводил раньше, при добавлении/удалении атрибута, на автомате создаются view&sp со всеми полями.В Net возможны и другие варианты. Например, свой BindingManager. PS На вопрос "как?", все обсуждение сводится к ответам:"Кому это нужно!". ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 12:43 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
_модДля того чтобы уже существующие программы подхватили новый объект(таблицу, столбец) они изначально должны быть написана на динамическиом SQL и использовать словарь БД - таких систем я лично не видел.То есть системы в которых программы умеют "подхватывать" новый атрибут, описанный в "самодельном" словаре данных вы себе представляете, а программы, которые умеют "подхватывать" новый атрибут описанный в словаре данных СУБД - представить не можете? Я думаю, что вы - лукваите. Вы сами для работы с СУБД какое средство используете? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 13:20 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
Bogdanov AndreyТо есть системы в которых программы умеют "подхватывать" новый атрибут, описанный в "самодельном" словаре данных вы себе представляете Это довольно просто - ведь SQL статический Bogdanov Andreyа программы, которые умеют "подхватывать" новый атрибут описанный в словаре данных СУБД - представить не можете? Такие программы я стараюсь писать только в крайних случаях. Bogdanov Andrey Вы сами для работы с СУБД какое средство используете? Смотря какая СУБД :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 14:02 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
_мод Belyкак именно данные попадают в грид? посредством хитрого SQL запроса? Да, и не очень хитрого.Примет "не очень хитрого" - можете продемонстрировать? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 14:04 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
_модДля того чтобы уже существующие программы подхватили новый объект(таблицу, столбец) они изначально должны быть написана на динамическиом SQL и использовать словарь БД - таких систем я лично не видел.Никто не мешает использовать метаданные не только для EAV, но и для обычных таблиц. И таких программ - масса, которые можно донастроить для изменившихся таблиц. И не зачем лазить для этого в словарь БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 14:36 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
_мод Bogdanov AndreyТо есть системы в которых программы умеют "подхватывать" новый атрибут, описанный в "самодельном" словаре данных вы себе представляете Это довольно просто - ведь SQL статическийПокажите мне "статический SQL", который считывает список клиентов (фамилия, имя, отчество) из EAV базы. _мод Bogdanov Andreyа программы, которые умеют "подхватывать" новый атрибут описанный в словаре данных СУБД - представить не можете? Такие программы я стараюсь писать только в крайних случаях. То есть своем самодельному словарю данных вы доверяете больше, чем системному словарю БД? И из-за этого заставляете всех пользователей ваше программы мучаться с вашим собственным словарем вместо использования промышленных стандартов. _модСмотря какая СУБД :)Ну я не знаю с какими вы вообще работаете. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 14:49 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
BelyНикто не мешает использовать метаданные не только для EAV, но и для обычных таблиц. Это верно, но в select-е все равно придется использовать новые имена таблиц-столбцов, т.е запрос будет динамический. Так что метаописание не спасает. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 16:52 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#18+
BelyПримет "не очень хитрого" - можете продемонстрировать? Простенького готового нет а думать лень :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2008, 16:53 |
|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#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?all=1&fid=33&tid=1548708]: |
0ms |
get settings: |
7ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
131ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
193ms |
get tp. blocked users: |
2ms |
others: | 11ms |
total: | 376ms |
0 / 0 |