Comments 20
ООБД без ООП
Что вы вкладываете в понятие «ООБД» и чем это, по вашему мнению, отличается от документо-ориентированной БД?
По моему скромному мнению, ООБД и ДОБД — это одно и то же.
Это БД, в которой могут храниться объекты с произвольным набором свойств.
В ДОБД такие объекты называют документами, в ООБД — объектами.
Известная аналогия ДОБД с лесом, деревьями, сучьями и листиками мне не нравится,
потому что наборы документов в ней почему-то называют коллекциями, а должны называть гербариями.
Это БД, в которой могут храниться объекты с произвольным набором свойств.
В ДОБД такие объекты называют документами, в ООБД — объектами.
Известная аналогия ДОБД с лесом, деревьями, сучьями и листиками мне не нравится,
потому что наборы документов в ней почему-то называют коллекциями, а должны называть гербариями.
А, ну если так, то вы, конечно, можете считать, что ООБД без ООП возможна. Только, пожалуйста, вынесите свое определение ООБД в самое начало статьи, чтобы люди не ожидали, что вы придерживаетесь более консервативных (и более распространенных) точек зрения.
Ну и да, при таком определении вынесенный в заголовок статьи вопрос не имеет смысла: документо-ориентированная БД возможна без ООП, что тут обсуждать-то?
Ну и да, при таком определении вынесенный в заголовок статьи вопрос не имеет смысла: документо-ориентированная БД возможна без ООП, что тут обсуждать-то?
Сразу предупреждаю: из ИЕ не работает, все претензии к разработчикам фреймворка RSF.
Вот любопытное дело. Фреймворк RSF разработан компанией ООО «Результат», вот цитата из их статьи в песочнице:
В общем, получился фреймворк, на который была переведена СЭД, и на котором теперь происходит ее дальнейшая разработка. Фреймворк решили назвать RSF (Result-Systems Framework).
Основная разработка этой компании — это профессиональная система электронного документооборота Result-Systems. И, что характерно, CRM-Sova, про которую вы пишете, что вы ее выложили в сеть (и, судя по всему, вы же ее написали, чтобы «утешить любимую жену») — это вариант Result-Systems, официально предлагаемый на их сайте. Более того, приведенная выше аналогия про гербарии — это цитата из статьи на сайте того же ООО.
Если не секрет, как же именно вы соотноситесь с этой компанией, что с одной стороны предлагаете их CRM, косвенно упоминая, что это ваша разработка, а с другой — говорите, что все претензии к ним?
Грешен, я имею отношение к Результат, но фреймворк писал не я (и статью в песочнице тоже не я).
Сова — это моя авторская работа, я написал ее для жены и выложил в сеть на сайте-страничке crm-sova.ru (там, к слову, об ООО «Результат» ни слова).
Когда Результат предложил выложить Сову на своем сайте, я был не против. Вот так Сова стала «официально предлагаемой».
Авторских прав я не заявлял, а к официальному сайту доверия больше.
Я извиняюсь за то, что в моей статье оказалась реклама Совы, а Сова в свою очередь оказалась на коммерческом сайте, но прошу учесть,
что Сова продукт некоммерческий. Как правило, бесплатные CRM в чем-то ограничены, их задача склонить пользователя купить платную версию.
С Совой иначе: ни я, ни Результат не предлагают платную версию CRM (ее просто нет).
Сова — это моя авторская работа, я написал ее для жены и выложил в сеть на сайте-страничке crm-sova.ru (там, к слову, об ООО «Результат» ни слова).
Когда Результат предложил выложить Сову на своем сайте, я был не против. Вот так Сова стала «официально предлагаемой».
Авторских прав я не заявлял, а к официальному сайту доверия больше.
Я извиняюсь за то, что в моей статье оказалась реклама Совы, а Сова в свою очередь оказалась на коммерческом сайте, но прошу учесть,
что Сова продукт некоммерческий. Как правило, бесплатные CRM в чем-то ограничены, их задача склонить пользователя купить платную версию.
С Совой иначе: ни я, ни Результат не предлагают платную версию CRM (ее просто нет).
А когда вы в статье «Печальное будущее толстых клиентов или нетрадиционная ориентация веб-браузеров» (которая посвящена тоже Result-Systems) пишете «мы» («мы покажем», «нам приглянулся», «мы взяли за образец», «наша система») — вы что имеете в виду?
Когда вы рассуждаете в статье выше о построении какой-то структуры в БД — какая в этом роль RSF, а какая — ваша?
Когда вы рассуждаете в статье выше о построении какой-то структуры в БД — какая в этом роль RSF, а какая — ваша?
«Имею отношение к Результат» — это «я генеральный директор этого ООО». Ну да, «имею отношение». А «все претензии к разработчикам RSF» — это «все претензии к разработчикам компании, которой я же и управляю». Ну и наконец «Результат предложил» — это «компания предложила своему ГД».
Любопытно.
(если что, представленная в комментарии информация о должности — общедоступна в ЕГРЮЛ, дата внесения 1.02.2008, верно на момент написания комментария)
Любопытно.
(если что, представленная в комментарии информация о должности — общедоступна в ЕГРЮЛ, дата внесения 1.02.2008, верно на момент написания комментария)
Моя роль в статье «Печальное будущее толстых клиентов...» следует из подписи: Делопроизводитель.
Я хорошо знаю, что требуется от системы, и могу это объяснить программистам. По-этому я и писал «мы».
Второй вопрос я не совсем понял. Я (как любой человек) иногда рассуждаю на совершенно разные темы, даже на те, где моей роли нет никакой.
Если Вы о фрагментах кода, — то их написал я специально для статьи. Ни в RSF, ни в Сове таких фрагментов нет. Правила с похожими названиями есть,
но они означают совсем другое.
Я хорошо знаю, что требуется от системы, и могу это объяснить программистам. По-этому я и писал «мы».
Второй вопрос я не совсем понял. Я (как любой человек) иногда рассуждаю на совершенно разные темы, даже на те, где моей роли нет никакой.
Если Вы о фрагментах кода, — то их написал я специально для статьи. Ни в RSF, ни в Сове таких фрагментов нет. Правила с похожими названиями есть,
но они означают совсем другое.
Если вы делопроизводитель, а не программист, и не архитектор, то на основании какого опыта вы делаете какие-то суждения о построении БД, архитектуре систем, ООП, ORM, гибкости, поддерживаемости?
Простые вопросы:
1. каким образом предлагаемое вами решение:
интегрируется с системами управления версиями и системами автоматической верификации?
2. каким образом при создании документо-ориентированной БД на SQLite (или любой другой реляционной БД) обеспечивается необходимая и достаточная для крупных решений производительность при сложных запросах?
Простые вопросы:
1. каким образом предлагаемое вами решение:
Это много и это говорит о том, что центр тяжести системы сползает в сторону описания правил, т.е. в область настроек. Гибкость увеличивается, а главное, такая архитектура позволяет исполнять капризы заказчика, не трогая исходных кодов инструментальной части системы.
интегрируется с системами управления версиями и системами автоматической верификации?
2. каким образом при создании документо-ориентированной БД на SQLite (или любой другой реляционной БД) обеспечивается необходимая и достаточная для крупных решений производительность при сложных запросах?
Если вы делопроизводитель, а не программист, и не архитектор...
Я считаю, что именно делопроизводитель должен определять архитектуру системы. Для этого он должен ориентироваться в существующих технологиях.
Если спросить программистов: «Что главное в СЭД?» — большинство ответит, что главное — это электронная подпись и электронное согласование.
Делопроизводитель эти задачи поставит по важности на 5-6 место. К сожалению большинство СЭД на рынке проектировались программистами.
Я не программировал в ОРМ, но читал документацию по Hibernate и Django и представляю их плюсы и минусы.
Когда модель статична, для нее можно прописать и оптимизировать сложные запросы, и все будет прекрасно работать.
Но когда состав свойств объекта может меняться, когда объект во время жизненного цикла может обрасти новыми свойствами,
более эффективно использовать ДОБД.
каким образом предлагаемое вами решение интегрируется с системами управления версиями и системами автоматической верификации?
В Сове никак не интегрируется.
каким образом при создании документо-ориентированной БД на SQLite (или любой другой реляционной БД) обеспечивается необходимая и достаточная для крупных решений производительность при сложных запросах?
Поля индексируются, каждый запрос по одной таблице, таблицы относительно небольшие (в одной таблице как правило меньше 100 000 документов). Если нужна выборка по нескольким таблицам, будет работать медленнее, но таблицы можно раскидать по нескольким серверам.
В СЭД такой подход более эффективен, потому что большинство запросов простые, плюс пользователю не надо искать по всей базе.
В КУГИ СПб после замены ДОБД (LN) на РСУБД (Oracle) делопроизводители жаловались, что работать стало медленнее.
Я считаю, что именно делопроизводитель должен определять архитектуру системы.
То есть вы считаете, что делопроизводитель знает принципы построения ПО лучше архитектора? Тогда почему он делопроизводитель, а не архитектор?
Если спросить программистов: «Что главное в СЭД?» — большинство ответит, что главное — это электронная подпись и электронное согласование.
Делопроизводитель эти задачи поставит по важности на 5-6 место.
Это не архитектура, это бизнес-анализ.
Я не программировал в ОРМ, но читал документацию по Hibernate и Django и представляю их плюсы и минусы.
Плюсы и минусы по сравнению с чем?
Но когда состав свойств объекта может меняться, когда объект во время жизненного цикла может обрасти новыми свойствами,
более эффективно использовать ДОБД.
В чем выражается более высокая эффективность? Более высокая эффективность по сравнению с чем?
В Сове никак не интегрируется.
Сова — это частный пример решения, которые вы озвучиваете в статье. А я говорю о всем подходе целиком.
Поля индексируются
Покажите на примере, пожалуйста, как именно вы предлагаете совмещать entity-attribute-value (или key-value, не принципиально) модель с индексируемыми полями.
таблицы относительно небольшие (в одной таблице как правило меньше 100 000 документов).
А сколько у вас строк в этих таблицах?
Если нужна выборка по нескольким таблицам, будет работать медленнее, но таблицы можно раскидать по нескольким серверам.
Получается одно из двух: либо у вас всего сотня тысяч документов (в этом случае мы говорим о маленькой системе), либо у вас документы можно секционировать по формальным признакам. В обоих случаях сложная поисковая выборка по РСУБД окажется быстрее; более того, даже сложная выборка по документо-ориентированной БД окажется быстрее (благодаря оптимизации).
большинство запросов простые
Я говорил о сложных.
В КУГИ СПб после замены ДОБД (LN) на РСУБД (Oracle) делопроизводители жаловались, что работать стало медленнее.
Нельзя заменить Lotus Notes на Oracle, это решения разного уровня. Вы говорите о конкретном решении на базе Oracle, которое может быть как более, так и менее удачным.
почему он делопроизводитель, а не архитектор?
Странный вопрос. Я 17 лет занимаюсь делопроизводством и не стремлюсь в архитекторы.
Мне в очень солидной фирме демонстрировали модель БД для СЭД на Rational Rose размером со стену.
Архитектор БД умный интеллигентный профессионал, вот только СЭД у них получилась полупрофессиональная.
Потому что он не был делопроизводителем, а артифакты рисовались на основе бесед с секретаршами.
Я представляю их плюсы и минусы. — Плюсы и минусы по сравнению с чем?
Странный вопрос. Если бы я написал «Я знаю их возможности», вопроса бы не возникло?
Это не архитектура, это бизнес-анализ.
Бизнес-анализ определяет архитектуру, я считаю, эти вещи нельзя делить. Архитектор должен знать бизнес процессы.
Если он просто соединит квадратики стрелочками, получится то, что я описал выше.
В чем выражается более высокая эффективность? Более высокая эффективность по сравнению с чем?
Странный вопрос. Абзац описывает, что объекты с неопределенным набором атрибутов удобнее хранить в ДОБД по сравнению с ОРМ.
Сова — это частный пример решения, которые вы озвучиваете в статье. А я говорю о всем подходе целиком.
управление версиями за счет перевода измененных полей в историю, верификация нужна только для проверки связанных объектов.
Есть агент, который это делает.
А сколько у вас строк в этих таблицах?
Не много: 5-10 млн
Я говорил о сложных.
С СЭД работают 1000 человек. И 99.9% запросов простые. Это не теория, это опыт.
В РСУБД простые запросы выполняются не просто медленнее, а значительно медленнее, чем в ДОБД (я говорю о трех российских СЭД, с которыми я работал).
Сложные запросы — это отчетность, которая может собираться и 5 минут, и 10.
Нельзя заменить Lotus Notes на Oracle, это решения разного уровня.
Странное замечание. Почему нельзя? Взяли и заменили. Была СЭД на ЛН, стала на Оракл. Было быстро, стало медленно.
И я вовсе не считаю, что у программистов руки кривые или архитектор не так квадратики расставил и не так стрелочки нарисовал.
Я знаю 3 (три) популярные СЭД на РСУБД и все 3 ведут себя одинаково.
Мне в очень солидной фирме демонстрировали модель БД для СЭД на Rational Rose размером со стену.
А зачем?
Потому что он не был делопроизводителем, а артифакты рисовались на основе бесед с секретаршами.
Это очередная (и типичная) ошибка анализа. А вы считаете, что если бы архитектор был делопроизводителем, он бы нарисовал модель лучше?
Бизнес-анализ определяет архитектуру, я считаю, эти вещи нельзя делить.
Можно и нужно. Сначала проводится бизнес-анализ, потом на его основе делаются требования, потом на их основе делается архитектурное решение. Представитель заказчика (мы сейчас говорим о бизнес-представителе) может влиять на результаты анализа (требования), но не должен влиять на архитектуру (потому что она за пределами его компетенции).
Абзац описывает, что объекты с неопределенным набором атрибутов удобнее хранить в ДОБД по сравнению с ОРМ.
Это некорректное противопоставление (приблизительно уровня «воду удобнее хранить в бутылке, а не в холодильнике»). Документо-ориентированные БД можно противопоставлять реляционным или объектно-ориентированным; но нельзя противопоставлять БД — ORM, потому что ORM — это уже механизм работы с БД.
управление версиями за счет перевода измененных полей в историю, верификация нужна только для проверки связанных объектов.
Вы, кажется, не поняли: я говорю о предлагаемом вами подходе, когда в БД хранятся правила/скрипты. Для них управление версиями не ограничивается переводом в историю (нужна совместная работа, ветки, слияние, дифы и так далее), а верификация нужна не только для проверки связанных объектов (нужен анализ кода на синтаксическую корректность, проверка системы типов и доступности свойств и прикладное тестирование).
Не много: 5-10 млн
А в реляционной БД было бы 100 тыс. Разница в два порядка (и да, эта разница сказывается на скорости и месте).
С СЭД работают 1000 человек. И 99.9% запросов простые.
На СЭД разговор перевели вы. В изначальном посте речь шла о «ООБД», примером была CRM, а мой вопрос звучал как «каким образом при создании документо-ориентированной БД на SQLite (или любой другой реляционной БД)». Если ваше решение применимо только для СЭД, так и скажите.
И я не спрашиваю на какой БД (документо-ориентированной или реляционной) строить СЭД, я спрашиваю как упоминаемое вами документо-ориентированное решение поверх SQLite обеспечивает производительность, сопоставимую с чисто реляционными или чисто документо-ориентированными решениями.
И обратите внимание, что уже два моих конкретных технических замечания к предлагаемому вами решению вы проигнорировали.
Странное замечание. Почему нельзя? Взяли и заменили. Была СЭД на ЛН, стала на Оракл. Было быстро, стало медленно.
Потому что заменили СЭД на СЭД, и новая оказалась медленнее старой. Нельзя просто взять и заменить LN на Oracle, ничего больше не поменяв в системе.
И обратите внимание, что уже два моих конкретных технических замечания к предлагаемому вами решению вы проигнорировали.
Извиняюсь, я не старался выбрать вопросы поудобнее.
1. Про индексирование. Документы хранятся в таблице из 5 столбцов: uuid, xcreated, xname, xvalue, xmodified.
uuid, xname, xvalue — индексированы
2. Повторите, плиз, вопрос, — вопросов много, среди них есть риторические, т.е. не требующие ответа (зачем мне демонстрировали систему?).
Про бизнес-аналитику в идеале Вы правы. Только в жизни представитель заказчика не всегда понимает, что он хочет в результате получить.
Но обсуждать эту тему лучше не со мной. Я специалист по ДП и не планирую строить модели в других областях.
Документо-ориентированные БД можно противопоставлять реляционным или объектно-ориентированным; но нельзя противопоставлять БД — ORM, потому что ORM — это уже механизм работы с БД.
Конечно, я сравнивал ДОБД с ОРМ.
А в реляционной БД было бы 100 тыс. Разница в два порядка (и да, эта разница сказывается на скорости и месте).
Места ДОБД, возможно, займет меньше. Если в документе заполнено 5 полей из 50 возможных, в ДОБД пустых полей просто не будет, а в РСУБД они будут, но пустые.
Я изучал возможность построения базы на ОРМ, но забраковал эту идею. Объекты в ОРМ должны быть статичны, хранение в одной таблице объектов разных классов приводит тому, что таблиц становится несколько. В результате все не гибко, не быстро и не удобно.
Вы, кажется, не поняли: я говорю о предлагаемом вами подходе, когда в БД хранятся правила/скрипты.
В плане версий: скрипты могут хранятся в виде файлов, а в базу загружаться по команде. Верификация даже проще — не надо перегружать сервер.
Если ваше решение применимо только для СЭД, так и скажите.
Так и говорю: мое решение применимо только для СЭД. Только СМК я тоже считаю СЭД. И CRM тоже СЭД. И bug tracking — тоже СЭД. А бухгалтерия — это не СЭД? Скажите главбуху, что ее работа не связана с документами и внимательно проследите за реакцией.
я спрашиваю как упоминаемое вами документо-ориентированное решение поверх SQLite обеспечивает производительность, сопоставимую с чисто реляционными или чисто документо-ориентированными решениями.
SQLite годится для локала, для больших систем другие серверы.
Производительность вещь лукавая. Есть простой поиск, есть сложный, есть время открытия, время сохранения, время связывания объектов и пр.
Для СЭД наше решение оказалось наиболее удачным. Оно обеспечило даже лучшую производительность, чем РСУБД.
Структуру базы я описал, индексы тоже. Есть еще коллекции (виды) документов. Больше ничего нет. Можно считать, что у программистов РСУБД руки кривые, а можно, что архитектура ДОБД более эффективна. Я не из головы беру сравнения: была конкретная СЭД на ДОБД, заменили на СЭД на РСУБД, — стало хуже, была другая конкретная СЭД на РСУБД, заменили на СЭД на ДОБД, — стало лучше.
Документы хранятся в таблице из 5 столбцов: uuid, xcreated, xname, xvalue, xmodified. uuid, xname, xvalue — индексированы
Угу. Вы сравнивали планы запросов, необходимых для поиска документа с наименованием, начнающемся на «Положение», который был зарегистрирован 15 мая этого года (согласитесь, что это типичный запрос даже для СЭД) в вашем варианте, в РСУБД, в нативной документо-ориентированной БД? Так вот, я набросал простенький тестик под MS SQL (200 тысяч объектов, три поля, поиск по двум из них) для EAV и для реляционного хранилища, и для EAV план запроса сложнее в полтора раза, а время выполнение больше в два. И это, заметим, в идеальных для EAV условиях — значение проиндексировано (в реальности далеко не каждая СУБД это позволит), нет операций с типами (т.е. мы не пытаемся, скажем, сравнивать даты без учета времени), в реальных условиях EAV работает еще хуже. Вывод: предложенное вами решение не обеспечивает сопоставимой производительности (разрыв в два раза — это уже слишком много).
Повторите, плиз, вопрос, — вопросов много, среди них есть риторические, т.е. не требующие ответа (зачем мне демонстрировали систему?).
Формально это был не вопрос, а утверждение, но оно противоречит вашим высказываниям и вы его не оспорили:
Получается одно из двух: либо у вас всего сотня тысяч документов (в этом случае мы говорим о маленькой системе), либо у вас документы можно секционировать по формальным признакам. В обоих случаях сложная поисковая выборка по РСУБД окажется быстрее; более того, даже сложная выборка по документо-ориентированной БД окажется быстрее (благодаря оптимизации).
Только в жизни представитель заказчика не всегда понимает, что он хочет в результате получить.
Вот для этого и есть аналитики — чтобы выяснить, что же хочет получить заказчик на самом деле.
Я специалист по ДП и не планирую строить модели в других областях.
Это ваше высказывание плохо сочетается с вашим же «именно делопроизводитель должен определять архитектуру системы. ».
Конечно, я сравнивал ДОБД с ОРМ.
Я уже объяснил (прямо в том абзаце, на который вы отвечаете), почему это сравнение некорректно.
в ДОБД пустых полей просто не будет, а в РСУБД они будут, но пустые.
Вы, видимо, не в курсе, что РСУБД уже давно оптимизируются под ситуацию с незаполненными полями, и при правильно выбранной модели пустые поля влияют на размер хранилища несущественным образом.
Я изучал возможность построения базы на ОРМ, но забраковал эту идею.
На ORM нельзя построить базу.
Объекты в ОРМ должны быть статичны, хранение в одной таблице объектов разных классов приводит тому, что таблиц становится несколько.
Оба этих утверждения неверны. Современная ORM адекватно относится к изменениям структуры объектов, более того, можно работать через ORM с объектами неопределенной структуры (хотя в этот момент мы и теряем большую часть преимуществ ORM). С другой стороны, ORM позволяют хранение в одной таблице объектов разных классов — другое дело, что я не очень понимаю, зачем это нужно, учитывая, что это приводит к потерям в производительности и надежности.
скрипты могут хранятся в виде файлов, а в базу загружаться по команде.
… дополнительным инструментом. Зачем? В чем выигрыш?
Верификация даже проще — не надо перегружать сервер.
Вы не поверите, но в современных системах разработки для половины верификации не нужно даже разворачивать систему, не то что перегружать сервер.
Только СМК я тоже считаю СЭД.
Я не знаю, что вы называете СМК.
И CRM тоже СЭД.
Не обязательно.
И bug tracking — тоже СЭД
Нет, это система управления процессами.
А бухгалтерия — это не СЭД? Скажите главбуху, что ее работа не связана с документами и внимательно проследите за реакцией.
А вот это — банальное жульничество в терминологии. Нет, бухгалтерия — это не СЭД, даже если главбух считает, что работает с документами (хотя счета и проводки — это не документы).
Для СЭД наше решение оказалось наиболее удачным. Оно обеспечило даже лучшую производительность, чем РСУБД.
Вопрос в том, обеспечивает ли оно лучшую производительность, нежели нативные документо-ориентированные БД (например, Mongo или Raven).
Я не из головы беру сравнения: была конкретная СЭД на ДОБД, заменили на СЭД на РСУБД, — стало хуже, была другая конкретная СЭД на РСУБД, заменили на СЭД на ДОБД, — стало лучше.
Повторюсь, это проблема производительности конкретной СЭД.
Если вы делопроизводитель, а не программист, и не архитектор, то на основании какого опыта вы делаете какие-то суждения о построении БД, архитектуре систем, ООП, ORM, гибкости, поддерживаемости?
Странный вопрос.
Если не секрет, то кто Вы, что можете определять, кто имеет право рассуждать о той или иной теме, а кто — нет?
Sign up to leave a comment.
ООБД без ООП