 | | | | |
| Проект Вектор, или ООБД своими руками |
Полный текст материала
Другие публикации автора: Артур Юртайкин
Цитата или краткий комментарий: | «... Если понаблюдать за объектами реального мира, то станет очевидно, что их свойства претерпевают изменения с течением времени. В наше время даже пол человека может измениться. Меняется все. У каждого события есть отметка на шкале времени, а у каждого процесса временной интервал. С течением времени меняется законодательство и как следствие бизнес-логика приложения. Считаю, что при разработке информационных систем необходимо учитывать, что объекты и логика могут меняться во времени. По всей видимости, необходимо, уже на этапе разработки приложения, предусмотреть возможность внесения изменений, как в свойства, так и в логику. Должен быть некий механизм синхронизации значении свойств объектов и логики приложения. В проекте Вектор все свойства изначально периодические. Это означает, что их значения позиционируется на шкале времени, а вся история изменений хранится в БД. ...» |
Важно:- Страница предназначена для обсуждения материала, его содержания, полезности, соответствия действительности и так далее. Смысл не в разборке, а в приближении к истине :о) и пользе для всех.
- Любые другие сообщения или вопросы, а так же личные эмоции в адрес авторов и полемика, не относящаяся к теме обсуждаемого материала, будут удаляться без предупреждения авторов, дабы не мешать жителям нормально общаться.
- При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
- Размер одного сообщений не должен превышать 5К. Если Вам нужно сказать больше, сделайте это за два раза. Или, что в данной ситуации правильнее, напишите свою статью.
Всегда легче осудить сделанное, нежели сделать самому. Поэтому, пожалуйста, соблюдайте правила Королевства и уважайте друг друга.
Добавить свое мнение.
| | | Содержит полезные и(или) интересные сведения | | [1] | 1 | 50% | | | | | Ничего особенно нового и интересного | | [2] | 1 | 50% | | | | | Написано неверно (обязательно укажите почему) | | [3] | 0 | 0% | |
Всего проголосовали: 2 | | | | Все понятно, материал читается легко | | [1] | 1 | 100% | | | | | Есть неясности в изложении | | [2] | 0 | 0% | | | | | Непонятно написано, трудно читается | | [3] | 0 | 0% | |
Всего проголосовали: 1 |
[DataBase]
Отслеживать это обсуждение 
Всего сообщений: 2001-10-2012 06:10
13-09-2009 03:30>>>так называемые метаданные
>>>очепятка?
Да, надо писать "метКОданные"
|
|
04-09-2009 10:08>>>так называемые метаданные
очепятка? |
|
28-08-2009 15:36To: Fisher
Навскидку зашел на http://en.wikipedia.org/wiki/Entity-attribute-value_model, там в разделе "EAV versus row modeling" вполне себе кратко, но емко рассматривается сабж.
Другое дело, что EAV так себе технологически неорганично ложится на реляционные таблицы. Причем все "хорошее", что есть в реляционной модели (индексы, ограничения) на технологическом уровне, уже не работает, а вот "плохое" из реляционных баз данных типа SQL (плохое с точки зрения EAV), реально мешает. И вот себе вопрос: зачем покупать резиновую лодку, чтобы выкроить из нее резиновые сапоги, а потом склеить их столярным клеем?
Это просто мысль не о том, "что лушче - объектно-ориентированные базы данных или реляционные", а о том, что странно на основе реляционной базы данных сляпать подобие объектно-ориентированной. Тут как бы у самого грешок - пришлось сляпать (с описанными ограничениями), но уж точно нет сомнений:
не стоит рекламировать самопальный движок объектной базы данных на плоских таблицах как решение проблем реляционной модели. |
|
28-08-2009 07:20позволяет контролировать не более 50 таблиц (сущностей)
С ограниченностью человеческого разума соглашусь, но "классик" сказал очень грамотно - таблиц (сущностей). А в случае с EAV, как я уже говорил, количество логических сущностей (типов объектов) ничуть не уменьшается, просто они описываются иначе, причем об удобстве и понятности такого представления для SQL-запросописателя можно спорить. На практике многие говорят о необходимости организации собственного описателя метаданных, и слоя софта для автоматизации запросов к "всеобщей таблице всего". Так что довод об упрощении системы я бы назвал сомнительным.
Преимущества EAV лежат несколько в другой плоскости. Например, это хранение сильно "разреженных" таблиц, где у сущностей много свойств являются опциональными или вариантными. Другой пример - очень удобно прицепить историю действия каждого атрибута во времени, протоколирование изменения пользователями. Это навскидку. А свести бы эти аргументы в табличку - это хорошо, это плохо. |
|
28-08-2009 06:44To: Fisher
>>>И хоть убейте, не пойму, почему количество нормальных таблиц многие считают дорогим параметром?
Сошлюсь на "классика"
Р. Райордан "Основы реляционных баз данных" (Relational Database Systems) Microsoft Press, Русская редакция.
(могу напутать, ссылку проверять не полезу:)
В разделе, посвященном де-нормализации, приводится суждение, что
"объем человеческой памяти (обычного "среднего" разработчика) позволяет контролировать не более 50 таблиц (сущностей)". Соответственно, разработка/добавление новых таблиц в систему заставляет человека (разработчика) "терять из виду" уже сделанные таблицы.
Тут, правда, есть и экстенсивное решение: разбивать систему на несколько "sub-databases" с разграничением "полномочий" группы разработчиков. Вполне, видимо, обоснованное решение. В любом случае сложно говорить о создании "одной системы одним разработчиком".
Так что, с одной стороны, "количество нормальных таблиц" - несомненный вред, а, с другой стороны, проблема имеет решение без изменения технологии представления. |
|
28-08-2009 06:11В принципе, достаточно одной таблицы для хранения любого набора любых объектов:
<Код_Объекта, Свойство, Тип, Значение>.
Ссылочная целостность?
И хоть убейте, не пойму, почему количество нормальных таблиц многие считают дорогим параметром? Сложно помнить, что где и зачем? Но ведь в случае с EAV те же таблицы неявно присутствуют с нами, только в "развернутом" виде, и сложность системы ничуть не уменьшается, только вместо обычных диаграмм помнить это приходится "в голове".
Давно хочу найти нормальный, спокойный материал со сравнением EAV vs классика, с объяснением преимуществ и оправданием недостатков каждой стороны по пунктам, но все никак не найду. А сам EAV недолюбливаю, посему, боюсь, у меня объективного сравнения не выйдет. Может, кто-то кинет ссылку?
|
|
28-08-2009 05:00>>> Так что вынужден настаивать на неприменимости данного подхода к типовым задачам построения СУБД
А Сергей и не предлагает такой вариант. Это некое полярное значение. Другим полюсом является создание отдельной таблицы на каждый чих. На практике же выбирается некоторый промежуточный варинт.
Так вот, Сергей говорит, что устоявшася практика проектирования большого количества таблиц не очень хороша. Да, разрабатывать проще. Но вот сопровождать и развивать сложнее. Если же мы хотим добиться простоты опровождения и развития, то нужно изначально грамотно проработать структуру. Чтобы создание новой сущности не требовало создания кучи новых таблиц. И такие варианты есть. |
|
28-08-2009 04:37>>>В принципе, достаточно одной таблицы для хранения любого набора любых объектов:
<Код_Объекта, Свойство, Тип, Значение>.
Тут, к сожалению, но правды ради, должен поспорить.
Если говорить о реальных "больших" объемах данных, то хранение значений "не вправо", а "вниз" даст несомненно ужасные задержки по времени при выборке из нее. Тем более, если все значения лежат в одной таблице, то индексирование полей также теряет смысл.
Так что вынужден настаивать на неприменимости данного подхода к типовым задачам построения СУБД. |
|
27-08-2009 11:07Пожалуй, нужна такая тема на базарной площади.
Проблема разрастания структуры БД в сложных проектах слишком актуальна и любые методы борьбы с ней нужно внимательно рассмотреть.
Я предпочитаю не плодить и таблицы для хранения разнородных свойств.
В принципе, достаточно одной таблицы для хранения любого набора любых объектов:
<Код_Объекта, Свойство, Тип, Значение>.
Не слишком эффективно, но универсально. Для повышения эффективности, придется, естественно, вынести строковые типы в словарь и т.д.
Реально, приходится создавать структуру в два десятка таблиц, зато никакое дальнейшее развитие функциональности не потребует ее переделки.
|
|
27-08-2009 02:05Не мог пройти мимо данной темы, т.к. реализую схожий проект.
1. Не совсем ясно (из текстового материала), как реализуется связь "объект-свойство"? А если быть более точным, то "класс-свойство". Тут как бы следует еще поработать: тип никак не может быть свойством объекта. Ни по идеологическим соображениям (принадлежность к типу определяется набором свойств, а не "извне" поставленным значением), ни по технологическим (в случае "сбоя" свойства "тип" технически "переопределить" тип хранимого объекта сложно, если система не обладает встроенной процедурой "идентификации типов").
2. Не совсем понятна фраза (неточная цитата) "таблицы для хранения свойств генерируются автоматически". Автоматически можно генерировать только "подмножества" типов, которые уже представлены базой данных. А если ограничение на "количество" типов существует (в зависимости от платформы), то логично заранее "статически" наделать таблиц для хранения значений свойств.
3. Мой проект был создан в виде "объектного хранилища данных" только для того, чтобы пользователь мог "создавать свои типы". Цель проекта: создание информационной системы типа "каталог" технических систем, существенно разнородных в плане набора свойств. Например, в данный каталог можно поместить: гайки, штангенциркули, станки, гаечные ключи и т.д.
4. На мою систему наложены ряд ограничений типа: свойства атомарны, ссылочность и агрегация не поддерживаются.
5. Поддержание ссылочности и агрегации возможно, но это - следующий этап. Пока система не может хранить гайку "как часть" станка.
6. Наследование "впрямую" отсутствует, но есть инстанцирование на базе имеющегося шаблона с добавлением новых свойств.
7. В "моем" проекте "объектно-ориентированное" хранилище есть просто метод хранения данных объектов, тогда как при работе приложения идет их "создание" с заполнением из базы, и вся дальнейшая логика определяется работой и взаимодействием объектов "в памяти".
8. Я оценил данную публикацию как полезную с тем ограничением, что применимость данного подхода находится в жестких рамках. И они не пересекаются с областью классических СУБД. |
|
19-08-2009 10:18| Хочется спросить: а Фаулер читан? Для информационных систем типа времени выполнения (real time) давно предложены архитектуры Persistent Layer. Какая проблема-то? Есть логика, где каждому объекту сопоставлен объект программный. Есть механизм сессий и транзакции. Есть сервер блокировок. Если кто-то сохранил сессию, то сессии всех клиентов оповещаются об изменении данного объекта и и эти объекты просто выкидываются из сессии, а при следующем запросе читаются из БД уже с новыми значениями свойств, ссылок и пр. |
|
19-08-2009 09:36
19-08-2009 07:04>>> Задели данные слова. Не суть их, а именно тон.
Вообще-то, при общении (особенно в интеренете) имеет смысл поступать с точностью до наоборот: обращать внимание на суть, а не на тон.
Теперь, собственно, про тон. Что именно в моем тоне показалось Вам некорректным. И как мне нужно было выразить ту самую суть (если Вы против ее не возражаете), чтобы не вызвать Ваших нареканий? |
|
19-08-2009 05:00Есть некая связь, в отношении понимания статьи и защиты диплома как описано тут.
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1403
Очень многим хотелось бы слышать то что им хочется.
Не идею а конкретную технологию которую можно внедрить уже на на следующий день :)
Например:
в процессе анализа было сделано...
при разработке учитывалось...
проектирование интерфейса потребовало...
тестирование проводилось в ручном режиме...
выполнялось требование...
Я понял что при помощи этой DB можно хранить все кнопочки и прочее на сервере и создавать их например для каждого пользователя абсолютно отдельно, то есть очень глобальная задача продажи функций программы по частям. |
|
19-08-2009 04:55У меня вопрос к автору. Возможно я что-то упустил...
В таблице хранящем значение любого свойства есть поле Time, я так понимаю это время, когда значение свойства вступило в силу.
Если упомянутая Сидорова, 5 раз выходила замуж, то как узнать её фамилию на любой момент времени. Если я не ошибаюсь придётся сначала получить максимальную дату изменения соответствующего свойства которая меньше указанной, а потом значение свойства с полученной датой. Если в городе 5 миллионов женщин, которые в среднем 2 раза меняли фамилию, то для получения всего отсортированного списка фамилий актуальных на любой момент времени получится довольно затратный запросец... |
|
19-08-2009 03:26>>>Приведенного текста пока недостаточно, чтобы оценить качество задумки и реализации.
Задели данные слова. Не суть их, а именно тон. Кто Вам вообще дал право судить о труде в таком тоне? Почему Вы считаете что данный сайт достоен того, чтобы вот так взять и подарить ему труд, адекватный данной теме? |
|
18-08-2009 14:13Почитал данную статью и несколько призадумался. По моему разумению автор создал некий кусок платформы, которая обеспечивает спецификацию базы данных, изменяющейся во времени.
Вот при этом хотелось бы понять, как устроена технология создания прикладных систем в целом, включая создание программного кода приложения. Если последнее никак не учитывается, то я соглашусь с Geo в том, что не видны преимущества на уровне прикладного программиста. Возможно даже, что вместо преимуществ у него возникают дополнительные нагрузки по поддержанию платформы-прослойки между базой данных и бизнес-логикой, вынесенной в клиентскую часть системы, т.е. того, что автор называет вектором. Допускаю, что тут есть резон, - все-таки приобретение контроля за развитием базы данных во времени может быть в ряде случае довольной актуальным.
Все сказанное никак не умаляет труд автора, разумеется. |
|
18-08-2009 08:52В статье правильно обозначена проблема (изменчивость ПО), предлагаемое решение, на мой взгляд, - это утопия. Попытка повторить "подвиг" 1С. Без достаточного финансирования невозможно делать качественные продукты как для потребителей, так и для внутреннего использования (а это просто необходимо в случае отказа от реляционной структуры БД). В итоге вторая группа продуктов, как правило, развивается вяло и в конечном счете умирает. При этом разработчик попадает в зависимость от технологии, т.к. код написан под эту технологию.
Есть другой подход - генерирование исходного кода, в этом случае "кодозависимость" отсутсвует впринципе, т.к. для получения "другого" кода, достаточно изменить или заменить соотвествующий генератор. При этом количество разрабатываемого инструментария уменьшается в разы, т.к. как для создания приложения, так и для создания БД и их отладки можно использовать существующие инструменты (качество которых в любом случае намного лучше).
По теме статьи: генерировать БД проще всего, т.к. синтаксис SQL относительно простой.
ps: Пример 1С, на мой взгляд, очень поучительный. Несмотря на то, что они делают различные обертки для ускорения разработки, фундаментальные ограничения ничем уже не исправить (Уверен у 1С нет на это ни желания, ни времени, ни денег). Например, невозможно реализовать связь Master-Detail-SubDetail. Требуется может быть и не часто, но когда потребуется - получается облом. Все решения, которые я встречал по этому вопросу, очень сильно ограничивают работу пользователя. Еще один существенный недостаток - язык разработки, который, видимо, никогда не будет изменен и улучшен (хотябы по части перехода от позднего связывания кода к раннему), ну и т.д. там много чего еще можно найти... Однако, у 1С нет проблем с клиентами, они могут содержать такого монстра... А какова верятность добиться таких же экономических успехов используя, по сути, теже технологии? |
|
17-08-2009 05:21Приведенного текста пока недостаточно, чтобы оценить качество задумки и реализации. Когда говорят "объектно-ориентированный", то подразумевают, что работать придется не с элементарными конструкциями, а с некими более интегрированными метаконструкциями, называемыми "объект". Здесь в примерах это не показано. Имеется только сложный запрос на разработанной структуре данных и более простой вариант этого запроса с использованием каких-то предопределенных функций (видимо, сервисные хранимые процедуры). Да, классический вариант выглядит несколько сложнее, но ведь структура данных специально разработана под определенный способ работы с данными.
Приведенная ХП dbo.usp_Objs является, судя по всему, внутренней процедурой реализации. а как выглядит работа на уровне прикладного программиста? Какие он получает преимущества при разработке прикладных проектов? Или все преимущества заключаются исключительно в автоматическом сохранении всех изменений?
Известный факт, что за преимущества в наглядности, получаемые от ООП, мы платим увеличением объема кода и временем его работы. А какова плата здесь? Что мы теряем?
Ну и главное, в каком отношении предлагаемая концепция находится с парадигмой объектно-ориентированного проектирования? С такими моментами, как наследование, полиморфзим, инкапсуляция? Или здесь просто имеет место совпадение терминов (омонимия)? |
|
|
|
