|
изменяемый набор полей, в каждой таблице
|
|||
---|---|---|---|
#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 |
|
|
start [/forum/topic.php?fid=33&msg=35493186&tid=1548708]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
129ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 285ms |
total: | 518ms |
0 / 0 |