Реляционные БД vs Объектно-ориентированные БД

    К сожалению не нашел на хабре достаточно интересных стаей про объектно-ориентированные базы данных (ООБД). Хотелось бы поднять эту тему, т.к. в последнее время все больше и больше идет разговоров об ООБД. Однако в одну статью всю информацию уложить не получится, поэтому приведу для начала небольшой обзор и свои размышления на эту тему. В этой статье я не буду рассматривать конкретные решения, основанные на каждой из технологий, а только постараюсь сравнить сами технологии.

    Предыстория


    Я занимаюсь проектированием и разработкой баз данных уже порядка 6 лет. За это время у меня сложилось свое видение как лучше подходить к проектированию, как выбирать архитектуру системы, какие существуют особенности при нормализации и денормализации реляционных БД, как оптимизировать те или иные конструкции и запросы. В первый год работы я пришел к тому, что не хочу заниматься рутиной по написанию одних и тех же запросов. В результате я написал свой генератор хранимых процедур, который по структуре БД генерировал большинство рутинных запросов (если будет интересно, то могу написать статью на эту тему). Затем этот генератор эволюционировал из года в год, и, в итоге, я пришел к необходимости хранить объекты, как они есть, чтобы не заморачиваться переводом объектной модели в реляционную структуру. Т.е. фактически я пришел к генерации некой ORM надстройки. Конечно, Вы можете сказать, что уже создано достаточное количество качественных ORM надстроек и объектно-реляционных БД, которые можно успешно использовать (и я с Вами соглашусь, но с некоторыми оговорками). Но и это меня не устроило. И я решил пойти дальше.

    Влияние ORM


    По моему скромному мнению использование ORM надстроек только тормозит развитие ООБД. Постараюсь пояснить это достаточно спорное утверждение. Я не считаю, что ORM это зло, но и абсолютным добром она тоже не является. Технология ORM несомненно сыграла (да и сейчас играет) важную роль в развитии средств разработки, она показала, что программист на самом деле может и не заботиться о логике хранения данных. Однако здесь, как и везде есть свои «НО».

    Использование ORM несомненно ускоряет разработку продукта, снижает трудозатраты и бла-бла-бла. Однако, любая ORM это некая прослойка, которая всегда будет работать медленнее, нежели прямая работа (я тут отнюдь не призываю перенести все вызовы SQL запросов в приложение – везде должна быть золотая середина). Наличие ORM позволяет разработчикам не особо задумываться о работе СУБД (и они-таки не задумываются в большистве своем), что влечет за собой, мягко говоря, не совсем оптимальную работу приложения под нагрузкой. Для оптимизации приходится лезть руками в прослойку и настраивать запросы так, чтобы они стали работать быстрее, приходится лезть в базу данных и перенастраивать индексы и таблицы. Таким образом, для оптимальной работы приложения необходимо приложить больше усилий, нежели когда ORM отсутствует. В итоге мы сокращаем затраты на разработку и ускоряем выпуск первой версии продукта, но усложняем процесс оптимизации.

    Однако об оптимизации никто не думает в момент написания первой (а зачастую и второй, и третьей) версии продукта. Для большинства контор сейчас главным фактором является не качество, а скорость разработки. Оно и понятно: изначально заказчик хочет получить продукт как можно раньше, затратив минимум денег. И только спустя некоторое время, когда база наполнится реальными данными, пройдет пару месяцев, заказчик (да и разработчик тоже) с удивлением обнаруживает, что время выборок увеличилась почти вдвое, при работе 10-20 пользователей одновременно СУБД пытается покончить жизнь самоубийством и т.д. и т.п. Разработчик часто руководствуется восточной мудростью: А там уже либо ишак сдохнет, либо султан, либо сам Ходжа. Но, если никто не сдох, то вот тут-то разработчик и начинает искать узкие места, выдирает из ORM автоматически сгенерированные запросы, переписывает их руками, перестраивает индексы в таблицах БД и тратит на это и подобную оптимизацию еще уйму времени и сил.

    Что-то меня понесло в сторону. Надеюсь, я достаточно понятно изложил свою позицию относительно ORM. Давайте вернемся к сравнению (или, если кому угодно — противостоянию) реляционных и объектно-ориентированных БД.

    Реляционные БД vs ООБД


    Не смотря на огромную популярность парадигмы ООП в программировании, в технологии разработки баз данных эта парадигма пока не особо популярна. И тому есть как объективные, так и субъективные причины.
    • Популярность. Под реляционные базы создано множество замечательных продуктов, которые необходимо поддерживать и развивать. В эти продукты уже вложены большие деньги и заказчики готовы еще вкладывать деньги в их развитие. Напротив, с использованием ООБД разработано сравнительно мало серьезных коммерческих продуктов, существует мало мощных ООСУБД.
    • Язык запросов и его стандартизация. Еще в далеком 1986 году был принят первый стандарт SQL-86, который определил всю судьбу реляционных БД. После принятия стандарта все разработчики реляционных СУБД обязаны были следовать ему. Для объектно-ориентированных баз данных пока стандарта языка запросов нет. Сейчас среди разработчиков даже нет единого мнения о том, что этот язык запросов должен делать, не говоря уже о том, как он это должен делать.
    • Математический аппарат. Для реляционных БД в свое время Эдгар Кодд заложил фундамент математического аппарата реляционной алгебры. Этот мат. аппарат объясняет, как должны выполняться основные операции над отношениями в базе данных, доказывает их оптимальность (либо из него видно, где надо оптимизировать). С другой стороны для ООБД нет такого аппарата, даже не смотря на то, что работы в этой области ведутся с 80-х годов. Таким образом, в ООБД пока нет строгих терминов, таких как декартово произведение, отношение и т.д.
    • Проблема хранения данных и методов. В реляционных БД хранятся только голые данные. Что с ними будет делать приложение, зависит уже от приложения. В ООБД же, напротив должны храниться объекты, а объект это совокупность его свойств (параметры объекта) и методов (интерфейс объекта). Здесь так же нет единого мнения, как ООБД должна осуществлять хранение объектов и как разработчик должен эти объекты разрабатывать и проектировать. Здесь же возникает и проблема хранения иерархии объектов, хранение абстрактных классов и т.п.

    Выводы и перспективы


    В свете сложившейся в настоящее время ситуации в мире разработки, перспектива появления серьезных и популярных решений с использованием ООБД кажется весьма сомнительной (но от этого не менее желаемой) до тех пор, пока не будут разрешены фундаментальные вопросы (мат аппарат и стандарт языка запросов). Меня, как разработчика, это несколько печалит, ибо я пришел к выводу, что наличие мощной и удобной ООБД просто необходимо для дальнейшего качественного развития средств разработки баз данных.

    Что касается перспектив реляционных БД, то я полагаю, что они будут жить еще достаточно долго. ООБД все равно не смогут заменить реляционные БД в полном объеме. В некоторых реальных задачах все же удобней и правильней хранить данные не в объектах, а в таблицах.

    Таким образом, я считаю, что со временем ООБД отвоюет у реляционных БД кусок рынка коммерческих систем, однако добиться такого тотального преимущества, которое сейчас имеют реляционные БД им не под силу.
    Поделиться публикацией

    Комментарии 201

    • НЛО прилетело и опубликовало эту надпись здесь
        +7
        С удовольствием опишу механику работы. В ближайшее время соберусь с мыслями и напишу статью на эту тему, даже наврено из этого получится цикл статей.
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            Будем ждать.
              0
              Аккурат сейчас сижу и свой генератор пишу. Только как раз отличающийся универсальностью. Он будет по логической схеме сущностей генерить что угодно что из неё может следовать (create-запросы для создания новой бд, хранимки, web-сервисы, scaffold-заготовки приложений на любом нужном мне языке).

              Недавно понял что слишком много времени я трачу на написание очень похожего кода и решил это автоматизировать. Погуглил, ничего готового подходящего мне не нашёл, так что вроде не велик. Говорят для написания таких штук здорово подходит Prolog, но мне пока страшновато за него браться, пишу на родных C#+LINQ+TSQL.
                0
                Prolog построен на правилах. Фактически, любая система, которая полностью описывается набором правил и приоритетами, может быть легко описана на Prolog.

                Для изучения концепций языка потребуется:
                1) Учебный курс, хотя бы простельнький
                2) 1 месяц обучения (предполагается, что общие сведения о языках, построенных на правилах вывода, имеются)

                После этого его уже вполне можно использовать.
            +3
            Не могли бы вы сделал обзор существующих ООБД? Я видел что они уже существуют, но доверия не вызывают совершенно.

            Правильно ли я понимаю, что документо-ориентированные ДБ — это нечто среднее между реляционными ДБ и тем, что имеете ввиду вы?
              +9
              Можно было бы и обзор написать.
                +1
                насколько я понимаю (mnogodb, lotus notes) — документоориентированные — это просто недоделанные ООБД :)
                в документах есть поля данных, но нет никакой связи с методами класса (кроме типа документа)
                ну и наследования никакого (развечто включать отдельным полем ссылку на экземпляр базового класса.
                  0
                  schemaless, если точнее
                    +1
                    это mnogodb безсхемная.
                    а в лотусе есть формы документов с описаниями полей.
                      0
                      Да, точно (сам же работал раньше!).
                0
                Перенесите в какой-нибудь профильный блог, пожалуйста. (Да и предыдущий свой топик можете в «Образование» перенести.)
                  0
                  «Разработка» подойдет?
                    0
                    Да, вполне, раз уж нет отдельного блога типа «Базы данных».

                    Кстати, ждите сообщение в личку, есть к вам несколько вопросов :).
                      0
                      Спасибо, перенес.
                  +6
                  Извините, ни о чем
                    0
                    И что же Вам не понравилось?
                      +13
                      Вы как-то растеклись мыслею по древу, и фактически не произвели сравнения Реляционных БД и ООБД. Мало фактов, процентов на 90 ваш пост состоит из воды.
                        +2
                        Вполне возможно немного сумбурное изложение получилось и не совсем именно то, что хотел рассказать, не судите строго — первая попытка написания подобных статей. В дальнейшем постараюсь исправиться.
                        0
                        В самом начале раздела «Влияние ORM» вы громко декларировали что ORM сильно тормозит развитие ООБД, но дальше вы описываете чем же ORM плох. Так, а чем же он тормозит развитие?

                        Сравнивая СУБД и ООБД, вы описали плюсы СУБД, но где же все остальное?

                          0
                          Пардон, как можно сравнивать СУБД и ООБД? (:
                            +1
                            Моя ошибка, я имел ввиду Реляционные БД
                            0
                            Тормозит тем, что наличие ORM предоставляет разработчику иллюзию хранения объектной модели. А следовательно, конечные разработчики думают что все супер и не заморачиваются.
                              +5
                              Наличие с++ предоставляет разработчику иллюзию присутствия в адресном пространстве программы объектной модели, а не одномерного массива байт. А, следовательно, конечные разработчики… ну, вы поняли =)
                                –1
                                так давайте всё писать на асме или сразу в двоичном/хекс коде?
                                  +2
                                  Нет, давайте все на plain sql, и никаких ORM ;)
                                    0
                                    А давайте без давайте? )

                                    Думаю, дело не в том, что предоставляется иллюзия объектной модели, а в том, что покрытие неполное. В итоге при возникновении проблем приходится детально разбираться, что происходит и почему, и требует для использования серьезной подготовки не только в части ORM framework'а, а также в структуре и принципах работы самих реляционных БД.

                                    А насчет иллюзии объектной модели в памяти — там-таки данная полнота присутствует, и при отсутствии хаков (а именно — отсутствии прямой работы с памятью, отведенной под объект, и магических cast'ов) данных функционал работает именно так, как ожидается.
                                      +1
                                      Мы с вами продолжим беседу, как только вы дадите определение «полноты покрытия», раз уж вы этим аргументируете :) Причем, вы упоминаете полноту и там, и там (и про ОРМ, и про с++), так что хотелось бы увидеть одно общее определение, да
                                +1
                                … можно подумать, ООБД не делает того же самого.

                                Поясню: ООБД дает разработчику видимость хранения объектной модели. Разработчик думает, что все супер. Но беда в том, что никто не знает, насколько все супер, и что с этим делать.

                                В этом отношении ОРМ и ООБД совершенно идентичны (а ООБД, как закрытая система, еще и хуже).

                                Мораль: что ОРМ, что ООБД просто надо тестировать под нагрузкой. И выбирать по результатам.
                                  0
                                  ООБД дает разработчику видимость хранения объектной модели

                                  По этой логике SQL Server + ORM — это ООБД?
                                    +1
                                    А вот вы подумайте с точки зрения разработчика: ему ли не пофиг, вызвал он метод ORM, вернувший набор объектов по заданному критерию, или же вызвал он метод ООБД-провайдера, вернувший тот же набор объектов по тому же критерию?

                                    В обоих случаях мы дернули черный ящик, получили результат, только в первом случае черный ящик состоит из двух известных нам слоев (ORM — RDBMS), а в другом — из одного (ООДБ, причем какая у нея внутре неонка, мы не знаем).
                                      0
                                      Давайте не будем думать с т.з. разработчика, а все-таки посмотрим с т.з. того, что говорит теория. Есть различные модели данных, на их основе строятся соответствующие БД и СУБД.

                                      А вы утверждаете, что при использовании ООП и соответствующей прослойки любая БД — это ООБД. Вы неправы. Термин «объектно-ориентированная БД» лежит на том же уровне, что и реляционная БД, сетевая, иерархическая и т.д., но никак не выше.
                                        –1
                                        «вы утверждаете, что при использовании ООП и соответствующей прослойки любая БД — это ООБД»
                                        Я этого не утверждаю. Я говорю, что недостаток «предоставляет разработчику иллюзию хранения объектной модели. А следовательно, конечные разработчики думают что все супер и не заморачиваются» равно присущ как ORM+RDBMS, так и ООБД (и чистым RDBMS тоже, кстати).

                                        Теория — это хорошо, но в теории ORM, например, генерит «чистый код».

                                        Нам интереснее практика.
                                          0
                                          А на какой именно модели данных строится ООБД?
                                            +1
                                            Как ни странно, на объектно-ориентированной :).
                                              0
                                              шутник… Как они так данные на диске хранят, чтоб доступ был быстрый, и при этом не модель была не реляционной?
                                                0
                                                Без шуток. Потому что модель данных и способ их хранения на диске — это в общем-то перпендикулярные вещи. ООБД внутри данные может хранить точно так же, как и РБД.
                                                Про внутренности — это все так давно было, что я уже могу и позабыть. Кто-то использует append write, кто-то деревья, кто-то это все комбинирует. Вариантов много. К сожалению, я не могу сейчас дать каких-то конкретных ссылок. Это можно попробовать погуглить по фразам "<название БД> internals".
                                          0
                                          Ну я полагаю что ООДБ будет быстрее чем связка ORM+RDBMS в данном случае.
                                            0
                                            А вы это полагаете, полагаю, исключительно из теоретических соображений? А как это реально обосновать?
                                              0
                                              С точки зрения логики, нативная работа со структурами данных должна быть быстрее чем их преобразование с помощью прослойки в другую форму и потом уже работа с ними.
                                                +2
                                                Это когда вы решаете задачу «прочитать-записать».

                                                А когда вы решаете задачу «найти все, удовлетворяющие условию», как тогда?
                                                  –1
                                                  тогда скорость сравнима. это я по опыту работы с документ-ориентированными сужу.
                                                    0
                                                    Вот и возникает вопрос — а за счет чего она сравнима? «Что у нея внутре»? Ведь «с точки зрения логики», сканирование табличных данных выгоднее, нежели сканирование произвольных структур. Не выходит ли так, что внутри там, на самом деле, неявная генерация табличного представления для каждого «типа» документов?

                                                    В частности, шарпойнт — тоже в каком-то смысле документоориентированная СУБД (как и TFS). Но внутри там RDBMS, просто специальным образом организованная.
                                                      0
                                                      известно за счет чего. за счет индексов.
                                                        0
                                                        А без индексов? Запрос бывает и не по индексированному полю.

                                                        (а еще бывают трюки с покрывающими индексами, скажем, или полнотекстовыми, или xml — в итоге выходит, что для реализации всего этого проще взять движок RDBMS и немного допилить напильником. Смотри на шарпойнт.)
                                                          0
                                                          А без индексов будет феерический звездец по производительности)))

                                                          Не спорю с этим.

                                                          Но есть несомненный выигрыш изза нативности хранения данных. Я лично щупал монгодб, там данные хранятся в BSON, никакого отношения к RDBMS оно не имеет.
                                                            0
                                                            «А без индексов будет феерический звездец по производительности»
                                                            … что, давайте покроем все поля индексами?

                                                            «Я лично щупал монгодб, там данные хранятся в BSON, никакого отношения к RDBMS оно не имеет. „
                                                            И как bson реагирует на запрос по неидексированному полю?
                                                              +1
                                                              Я не предлагаю покрывать все поля индексами оО
                                                              Вы что, по всем полям ищете обычно?

                                                              Индексы должны быть для полей, по которым ищут часто.
                                                              Ну а без индекса поиск будет медленнее чем в RDBMS, безусловно.
                                                                0
                                                                Пользователь иногда ищет по полям, по которым индекса нет (потому что «иногда», а не «часто»). Вот и привет «с точки зрения логики нативная работа со структурами данных быстрее».
                                                                  0
                                                                  Если грамотно продумать структуру базы и архитектуру приложения, то преимущества от использования ООБД покроют недостатки медленного поиска по неиндексным полям.
                                                                    0
                                                                    Уверены, что не выйдет так, что если грамотно продумать структуру и архитектуру, то выигрыш по скорости от использования RDBMS покроет недостатки от использования не-нативного ORM?
                                                                      0
                                                                      У меня нет в этом сомнений :)

                                                                      Но безусловно, у каждого типа СУБД — своя область применения. В которой этот тип СУБД будет и быстрее и удобнее, чем другие.
                                                                        0
                                                                        Ну тогда приведите конкретный пример с цифрами.
                                                                          0
                                                                          К сожалению, у меня сейчас нет времени, чтобы проводить эксперименты :) Где-то на хабре проскакивали топики с цифрами на эту тему.
                                        0
                                        ООБД дает разработчику видимость хранения объектной модели.

                                        ООБД не дает видимости — ООБД хранит объектную модель, а не преобразовывает ее в реляционную и обратно на лету, как это делает ORM.
                                          0
                                          Вот лично вы знаете, во что ООБД преобразует объектную модель для хранения на диске?

                                          Так что это тоже видимость объектной модели, просто поверх какого-то другого хранилища. И преобразование, очевидно, тоже есть.
                                            0
                                            Следуя этой логике резоннно задать вопрос: а как же тогда реляционные СУБД, уж не думаете ли Вы, что они хранят данные в таблицах?
                                            Конечно на диске все хранится в виде 1 и 0, но пользователю неудобно с ними работать =)

                                            В таком случае реляционные СУБД — это просто видимость реляционной модели. Не надо уходить на такие низкие уровни абстракции.
                                              0
                                              Похоже, вы не уловили посыла.

                                              Смысл в следующем: для получения данных из ORM over RDBMS и для получения данных из ООБД я как программист выдаю более-менее одинаковый код. В обоих случаях я, как программист, думаю, что система, с которой я работаю, делает «все супер», и заморачиваться не надо.

                                              При этом что ООБД, что ORM легко могут все изгадить, но я, как программист, никакого контроля над этим не имею.
                                                0
                                                Вот как раз о контроле я и говорил. Программист имеет контроль в обоих случаях и туда приходиться лезть ручками чтобы поправить то, что было изгажено, НО:
                                                — в случае с ORM у вас два места, где могут быть косяки: ORM (автосгенеренные запросы и др.) и RDBMS (настрйока индексов и др.)
                                                — в случае с ООБД у вас только одно место, которое надо настроить: сама СУБД и если она предоставит удобный и мощный инструментарий для оптимизации и настройки, тогда будет толк.
                                                  0
                                                  … у меня есть два места, где есть косяки, и два места, где я могу улучшить.

                                                  «если она предоставит удобный и мощный инструментарий для оптимизации и настройки, тогда будет толк. „
                                                  Очень важное слово “если».

                                                  Возвращаясь к началу треда: иллюзия «все супер» есть (или нет) в обоих случаях, не надо приписывать ее только ORM.
                                                    0
                                                    Суть в том, что для ORM это именно «иллюзия», а для ООБД — это естественный процесс. Ключевое словое не «все супер», а «иллюзия».
                                                      0
                                                      А какая разница программисту, естественный это процесс, или иллюзия, если все и правда супер?
                                                        0
                                                        Разница в том, где потом надо будет латать дыры — только в базе, или в прослойке и базе.
                                                          0
                                                          Я сказал — если все и правда супер. Какие тогда дыры?
                                                            0
                                                            Под «все супер» подразумевалось незметное преобразование объектной модели в реляционное хранилище, а не что все работает очень надежно и мега-оптимально.
                                    +1
                                    Попробуйте улучшить статью, а не срывать злобу на моей карме ;) Говорят, второе более эффективно
                                      +5
                                      Пардон, отправилось раньше.
                                      Во-первых, более эффективно первое, а не второе, конечно :)
                                      Во-вторых, в статье вы сами признаетесь: «Что-то меня понесло в сторону».
                                      Я смею заметить, вас в нужном направлении никогда и не несло, похоже. Методом «с потолка» делаете какие-то выводы. Ни на одно серьезное исследование — да что там исследование, источник хотя бы — не опираетесь. Делаете тайну из того, какими промышленными ООСУБД пользовались сами.
                                      И в заключении вывод: «Что касается перспектив реляционных БД, то я полагаю, что они будут жить еще достаточно долго». Охренительно, дружище, просто охренительно. Можно было ничего больше не писать ;) А еще этот вывод абсолютно неконтекстен, и подходит к 99 из 100 существующим на данный момент техническим решениям, безотносительно их природы или решаемой задачи.
                                      Вода, просто вода, вам же написали выше…
                                        0
                                        Да, согласен, местами получилось не совсем обосновано, местами много воды, местами сбился с мысли. Но для того здесь и есть комментарии чтобы можно было покритиковать, но в предплах разумного, без перехода на оскорбления вроде
                                        Я смею заметить, вас в нужном направлении никогда и не несло, похоже

                                        откуда вы взяли такое умозаключение? Может Вы провели серьезное исследование моей биографии и знаете куда меня несло, а куда нет?

                                        Давайте закроем тему личностей — здесь обсуждаем реляционные и объектные БД.
                                          0
                                          Вы как-то сложно к моим словам относитесь. Я за рамки статьи и не выходил, а вы что-то про биографию вспомнили.
                                          Ок, ок, вернемся к контексту — словами про «несло/не несло» я хотел сказать, что статья ни о чем. Вот так понятнее будет, я думаю :)
                                        0
                                        К Вашей карме я и не притрагивался (не о том Вы печтесь, раз так серьезно реагируете на изменение кармы), так что не надо сразу переходить на личности.

                                        Злобу? к чему? к комментарию из четырех слов?

                                        Я уже давно вырос из того возраста, когда я срывался на подобного рода комментарии. Сейчас предпочитаю воспринимать их как критику и в первую очередь искать ошибки в себе, потому и попросил уточнить что же именно Вам не понравилось.
                                          +1
                                          У вас двоих обычная «асечная» болезнь. Когда интонации выражений нельзя выразить в тексте и каждый понимает их по своему… как правило не позитивно =) Я как 3-е лицо могу вам сказитьчто вы совсем о разном говорите между собой… да и я наверно тоже хе-хе-хе =)
                                            0
                                            да, видимо Вы правы, глухой слепого не поймет.
                                    +2
                                    >в последнее время все больше и больше идет разговоров об ООБД.
                                    где? По-моему ООБД все больше и больше забывают. Ваша статья косвенно содержит этому подтверждение. То есть, Вы корректно изложили все недостатки ООБД и ORM, но они секретами не являются уже много лет.
                                      0
                                      Конечно эти недостатки не являются секретами. Я в этой статье и не стремился открыть кому-то глаза или показать какие гениальные открытия с сделал. Просто меня очень интересует эта область, а на хабре я не нашел хороших статей на эту тему. Вот и решил начать обсуждение вопросов, касательно ООБД и смежных областей.
                                        0
                                        да, это правильно, но вот у меня в отношении например ORM для Delphi только печальные сведения. Bold вроде был жив, потом умер в Win32 и возродился в .Net, но сейчас, похоже, окончательно умер.

                                        Разработчики клепают собственные фреймворки, но эти фреймворки дальше внутренних проектов не идут.
                                          0
                                          есть хорошие ORM, но опять же везде есть множество НО, которые можно узнать, толкьо пощупав их руками и наступив на десяток граблей.
                                            0
                                            То же самое и с моделированием в CASE-инструментах. Когда-то был бум, а сейчас это уже мало кого интересует. Потому что
                                            — длительный процесс освоения
                                            — внедрение требует изменения и усложнения (и ужесточения) бизнес-процессов при разработке ПО
                                            — сложный и долгий вход для нового разработчика
                                        0
                                        У Ayende Rahien в последнее время много постов по MongoDB :-) На хабре были статьи про HTML5 и ООБД. Ну и в целом, habrahabr.ru/search/?q=NOSQL.
                                          0
                                          Не путайте ООСУБД и document-oriented. MongoDB — второе, RavenDb (от Ayende) — тоже document-oriented
                                            0
                                            Я в курсе различий object и document oriented, но в контексте данной статьи на мой взгляд вполне можно объединить эти понятия.
                                              0
                                              Автор с вами не согласен:
                                              >> В ООБД же, напротив должны храниться объекты, а объект это совокупность его свойств (параметры объекта) и методов (интерфейс объекта).
                                              Document-oriented не хранят «свойства и методы» (которые хранятся в ООСУБД по версии автора), а значит, в контексте статьи объединить их низзя :)
                                                0
                                                Вынужден согласиться :-) Эх, если бы не свойства и методы… Впрочем, тот же RavenDb, несмотря на документо-ориентированную направленность с учетом автоматической сериализации/дессериализации хранит свойства объектов. И, если честно, я пока что не встречал настолько объекто-ориентированных баз данных, которые бы хранили и методы сохраняемого объекта.
                                                  0
                                                  В чем вообще смысл хранения методов, если они общие для всех объектов класса?
                                                  Сериализация объекта всегда была сериализацией его полей.
                                                    0
                                                    Наверно я не совсем точно выразился. Под хранением методов подразумеловась хранение поведения целого класса обектов. Здесь на самом деле кроется самое распространенное логическое недоразумение — все привыкли в реляционным БД, все привыкли что БД хранят только данны и все. Однако в случае с ООБД элементом хранения должен быть объект, который состоит не только из данных, но и из описания поведения.

                                                    Таким образом, методы (программный интерфейс объекта) должны храниться в ООБД в виде неких метаданных целого класса объектов, а, разумеется, не с самим объектом (экземпляром класса).
                                                      +1
                                                      Ну я себе слабо представляю практическую пользу от хранения методов в базе.
                                                        0
                                                        Потому что Вы под базой на инуитивном уровне понимаете реляционную базу данных.
                                                          0
                                                          Не совсем, в последнее время мои симпатии на стороне документ-ориентированных БД.
                                          0
                                          а вот не скажите, что про ООБД забывают
                                          я сижу на форуме по Caché
                                          и последнее время, стало появляться все больше новичков, большинство из которых это студенты, которые пишут дипломные работы по этой субд, я думаю в институтах, похоже теперь знакомят студентов не только с реляционными субд, но и с ообд
                                            0
                                            У Intersystems есть программа для ВУЗов по обучению своей СУБД, лицензия дается бесплатно. Я сам учился в одном из таких.
                                              0
                                              ну в общем то, неплохой подход к распространению знания про Cache.
                                                0
                                                а еще студенты, раз в год могут участвовать в конкурсе разработок с применением технологий Intersystems. и выигрыш хороший, и плюс еще поездка на конференцию DevCon, которая в этом году проходила во флориде
                                              0
                                              Но Cache не ООБД ни разу!
                                                0
                                                Ну, они сами про себя говорят, что таки ООБД. А что за БД Caché на самом деле?
                                                  +1
                                                  Внизу там голые массивы, причем к ним есть прямой доступ из приложений. В ряде случаев за счет этого можно добиться роста производительности по сравнению с РСУБД. Интегрирован интерпретатор процедурного языка, к которому объекты прилеплены с помощью препроцессора. Система может представлять определенный интерес в качестве специфической базы или основы дешевого (относительно) интегратора (Ensemble = Cache+надстройка).
                                                  +1
                                                  она постреляционная СУБД
                                                  она объектно-ореинтированная субд
                                                    0
                                                    Это они сами себя так называют — на деле там скорее пре-реляционная с эмуляцией реляционности поверх.
                                                      0
                                                      ну так все правильно
                                                      «пост- — приставка, имеющая значение «после»»
                                                      реляционность в ней как надстройка над принятой в СУБД системой хранения
                                                      вот пре-реляцонной она была бы, если бы все было наооборот
                                                        0
                                                        Неправильно. Для того, чтобы заслужить приставку «пост-» по праву необходимо что-то НАД реляционностью или ВМЕСТО нее, а не доступ к банальным массивам ПОД ней.
                                                        Объектная ориентированность там в виде… препроцессора к встроенному языку. Где там ООБД — ума не приложу.
                                                        Хотя в слове «постиндустриальный» эта же приставка используется еще хлеще :)
                                                          0
                                                          ВМЕСТО нее

                                                          так, реляционный доступ там, только как фишка, типа пользуйся если хочешь
                                                          Объектная ориентированность там в виде… препроцессора к встроенному языку

                                                          почему это вдруг в виде препроцессора, объектный доступ организован в самом языке COS, и чем собственно он плох для вас я не понимаю

                                                          вы скажите, что конкретно вам не нравится в Cache', за что вы его так пытаетесь опустить
                                                          может быть вы с ней вообще не работали, так почитали литературу о ней и делаете свои выводы
                                                            0
                                                            >почему это вдруг в виде препроцессора
                                                            Если посмотреть на генерируемые файлы — то все будет понятно: там будут исходники без объектов.
                                                            >и чем собственно он плох для вас я не понимаю
                                                            Ну почему сразу плох-то? Пафосность рекламы еще не делает систему объективно плохой.
                                                            >вы скажите, что конкретно вам не нравится в Cache', за что вы его так пытаетесь опустить
                                                            может быть вы с ней вообще не работали, так почитали литературу о ней и делаете свои выводы
                                                            Я с ней работал — хоть продакшен писать и не довелось, и литературу читал — хорошая, кстати, у них литература и документация. И опускать никоим образом не пытаюсь — весьма интересная для некоторых применений система.
                                                            Но рекламу и факты путать крайне не рекомендуется.
                                                              0
                                                              ну вот не надо сравнивать генерируемый системный код класса, после его компиляции, и код с которым работает программист
                                                              ведь собственно класс и работает с данными хранимыми в глобалах, и то без объектов там мало где, а в основном идет работа с объектом, что то вы путаете
                                                                0
                                                                > ну вот не надо сравнивать генерируемый системный код класса, после его компиляции
                                                                Да какая там компиляция — даже синтаксисические ошибки нередко всплывают только во время выполнения!
                                                                И я ничего не путаю — Cache ООБД де-факто не является и методы в базе не хранит.
                                                                  0
                                                                  синтаксические ошибки да могут возникать во время выполнения, а чаще всего из-за использования Xecute
                                                                  а где по вашему хранятся методы в Cache, там все хранится в глобалах, нет ничего чтобы не хранилось там
                                              +1
                                              Что касается ORM: вы забыли одну простую вещь — хорошая ORM уменьшает затраты на поддержку приложения, поскольку позволяет автоматически или полуавтоматически отслеживать изменения СУБД и кода. Иными словами, используя хорошую ORM мы избавлены от проблемы «в базе поменялось название поля — система молча упала».
                                                0
                                                А я и не гооврил, что ORM это плохо. Есть очень много плюсов при их использовании, однако, в противовес им появляются и недостатки, которые я описал. При изменении названия поля в базе, если Вы делали оптимизацию запросов и прописывали иих руками, то Вам их тоже придется переписывать руками.

                                                Вообще в хорошо спроектированной системе не должны менять названия полей в базе.
                                                  0
                                                  «Есть очень много плюсов при их использовании, однако, в противовес им появляются и недостатки, которые я описал»
                                                  Это верно для любого инструмента. Я просто указал на забытый вами плюс. А минусы у них планомерно изживаются.

                                                  «Вообще в хорошо спроектированной системе не должны менять названия полей в базе. „
                                                  Чтобы система была хорошо спроектирована, в ней не должны меняться требования. Беда в том, что в реальной жизни требования меняются (иначе бы не было культа рефакторинга). А раз меняются требования, то и структура данных может меняться.
                                                    0
                                                    «А раз меняются требования, то и структура данных может меняться. „

                                                    Бывает и так, но только в том случае, если Вы недостаточно внимания уделили анализу предметной области и проектированию системы. Если изменения требований заставляет Вас изменять уже работающую часть системы, то что то идет не так.
                                                    Из последнего, года полтора назад спроектировали базу данных для одной подзадачи, и стало совсем некогда. Два месяца назад, пришел новый программист и на той модели реализовал великолепную подсистему, от которой пользователи просто в восторге.
                                                      +1
                                                      Надо же, оказывается, требования никогда не меняются, а экстремальное программирование придумали идиоты.
                                                        0
                                                        Я не пытаюсь этого сказать. Вы видимо меня не правильно поняли. Я пытался сказать, что если на этапе исследования предметной области, написания функциональной спецификации, проектирования базы данных, Вы нигде не накосячили, то в большинстве случаев у Вас не должна возникнуть ситуация, когда меняется имя столбца в базе данных. При изменении требований у Вас появляются новые поля, м.б. после проверки зависимостей исчезают старые, но на рабочей системе не меняется название столбца, в следствии чего эта система и падает.
                                                          0
                                                          Ну так изменение названия с точки зрения системы мало отличается от удаления столбца — и то, и другое приводит к падению системы.

                                                          Просто первый попавшийся пример.
                                                        0
                                                        «Бывает и так, но только в том случае, если Вы недостаточно внимания уделили анализу предметной области и проектированию системы.»
                                                        Не только. Просто вам везло с заказчиком. В моей практике, когда сначала в анализе бизнес-модели одни данные, а через полгода меняется представитель заказчика — и данные вместе с ним — регулярны.

                                                        К сожалению, такова реальность, с ней ничего нельзя поделать.
                                                        0
                                                        Хорошо спроектированная структура должна гибко реагировать на изменения требований. Возможность изменений должна быть в нее заложена и описана изначально. Иначе через полгода разработки Вы получите ситуацию, когда придется переписать большую часть приложения, когда вдруг выяснится, что телефон оказывается надо хранить в формате "+#(###) ###-##-##", а не полем типа лонгИнт.
                                                          0
                                                          Должна. Именно поэтому я предпочитаю те системы, которые умеют делать верификацию структуры данных при ее изменении.
                                                        0
                                                        Неправда, к хорошо спроектированной системе могут измениться требования. Реальный мир беспощаден, и качество системы тут ни при чем.
                                                        +1
                                                        сомневаюсь, что даже супер-хорошая ORM может при изменении структуры «низлежащих» таблиц сделать что-то кроме впадения в ступор. Допустим, средства типа Together (встроенные в Delphi, C++Builder) могут преобразовывать модель в код и код в модель. Но там уже везде объекты, поэтому мэппинг особой проблемы не представляет.
                                                        А в случае ORM over RDBMS можно идти только сверху вниз. Но если что-то поменял «внизу» (в РСУБД), то это придется вручную корректировать и вверху (в модели ORM).
                                                          0
                                                          Зря сомневаетесь. Валидация модели в компайл- (или тест-) тайме — нормальная практика. Да, после проваленной валидации придется править руками. Но мы узнаем об этом не из юнит-теста (в лучшем случае), а из валидатора модели, который конкретно скажет, что где не совпадает.
                                                            0
                                                            Это как? Для компиляции нужна база?
                                                              0
                                                              Для проверки валидности модели там, где эта проверка включена, нужен доступ к базе. На билд-сервере обычно.
                                                          0
                                                          В случае ООБД вы получите аналогичное поведение. Поменяли поле — проект не компилируется (в случае языка со статической типизацией), или падает (в динамическом языке).
                                                            0
                                                            Согласен, в случае хорошей ООБД — да.
                                                          0
                                                          Согласен на все 100%. ORM и прочие прослойки — это зло. Хочется именно вменяемой ООБД.
                                                          С прослойками уже был печальный опыт. Попросили знакомые посмотреть почему сайт медленно ползает. Оказалось, что при размере базы всего в пару мегабайт, выбранная ими при разработке прослойка, генерит запросы чуть ли не 5-6 уровней вложенности и кучу временых таблиц. Соответственно старый добрый MySQL при смешном количестве посетителей на вполне современном железе еле ползал, т.к. сжирал всю память :(
                                                          Поэтому приходится либо писать свою прослойку между базой и объектами, либо очень аккуратно использовать готовые, т.к. раскидывать по всему коду INSERT'ы и SELECT'ы (как любят делать разработчики многих халявных CMS и подобных движков) — прошлый век. Любая попытка модифицировать такой софт превращается в ад.
                                                            0
                                                            «Согласен на все 100%. ORM и прочие прослойки — это зло.»
                                                            Аргументируйте. Только не почему плохо написанная прослойка зло, а почему вообще прослойки — зло. А то как бы вы сейчас вообще отвергаете идею разделения слоев.
                                                              0
                                                              Не надо плодить дополнительные сущности без крайней необходимости :)
                                                              Я согласен с автором, что создание вменяемой ООБД и открытого стандарта на подобные базы это будущее баз данных (по крайней мере хотелось бы на это надеяться). Собственно это позволит убрать лишние прослойки между кодом и БД.
                                                              Пока же приходится выбирать меньшее зло :( То есть прослойки это плохо, но пока деваться некуда — приходится писать свои или использовать готовые.
                                                                0
                                                                Вопрос в том, для начала, что такое «хорошая ООБД», и как это вообще устроить без адских потерь производительности.

                                                                С ORM все как раз понятно — хорошо сделанный ORM объединяет максимум достоинств RDBMS и ООП. А вот в ООБД с первым обычно тяжело и плохо.
                                                                  0
                                                                  В статье как раз упоминается что необходимо решить для того, чтобы создать качественную ООБД. Возьму на себя смелость процитировать:
                                                                  # Язык запросов и его стандартизация.
                                                                  # Математический аппарат.
                                                                  # Проблема хранения данных и методов.
                                                                  Пока эти вопросы не будут решены, трудно говорит о том, что такое хорошая ООБД.
                                                                    0
                                                                    Беда в том, что все эти вещи — language-specific. Как следствие, практически невозможно создать ООБД, независящую от языка разработки — в то время как для RDBMS существует стандарт де-факто в виде SQL, являющегося языком-посредником.

                                                                    Вот мы и уперлись в то, почему хороших ООБД не будет еще долго.
                                                                +1
                                                                > Только не почему плохо написанная прослойка зло, а почему вообще прослойки — зло

                                                                Потому, что способ доступа к данным, предлагаемый ORM, нельзя оптимально реализовать с существующими реляционными БД по крайней мере. Потому что ORM как бы представляет базу в виде набора объектов, которыми она *не является*. Оптимальный способ доступа к БД — выборка всех интересующих данных хорошим запросом с индесом и их разбор — и нормально составить такой запрос ORM принципиально не способен, хотя бы потому, что не знает, какие данные понядобятся в будущем.

                                                                Кроме того, уровень многих программистов низок, и в ходе написания ORM они еще ухудшают ситуацию, делаю «прослойку» еще более неэфффективной и требовательной к ресурсам. Или создают неудобства врожде требования описать все поля всех таблиц в XML-файле (типа [field name=«person_id» db_name=«person_id»/]). Интересно, они сами пробовали это сделать для типичной БД хотя бы их 20 таблиц?

                                                                Есть определенные подходы, вроде кеширования сущностей, но это попытка ценой переноса части БД в память ускорить к ней доступ. Фактически, происходит дублирование кеша БД, однако хуже реализованного, так как например в нем нет поддержки индексов. В общем, БД умеют делать это куда как лучше.

                                                                Не говоря о том, что такой подход прокатывает только в языках типа Java, а в PHP, где скрипт запускается заново при каждом запросе. становится бесполезным.

                                                                Также ORM'ы плохо работают там, где надо работать с группами сущностей (особенно большими), а не отдельнми объектами. Опять же, БД с большими таблицами работают замечательно.

                                                                Вы можете придумывать какие угодно прослойки и абстракции, но физически данные в любой БД хранятся в таблицах с индексами (а те — в файлах или в памяти). И все попытки их как-то по-другому представить будут вести к низкой эффективности операций с ними.
                                                                  0
                                                                  «Потому, что способ доступа к данным, предлагаемый ORM, нельзя оптимально реализовать с существующими реляционными БД по крайней мере. „
                                                                  Аргументируйте.

                                                                  “Потому что ORM как бы представляет базу в виде набора объектов, которыми она *не является*.»
                                                                  Это верно для любого DAL, будь он ORM или не-ORM. Этот маппинг все равно есть.

                                                                  «Оптимальный способ доступа к БД — выборка всех интересующих данных хорошим запросом с индесом и их разбор — и нормально составить такой запрос ORM принципиально не способен, хотя бы потому, что не знает, какие данные понядобятся в будущем.»
                                                                  Почему же не знает? Вполне знает, если ORM написан хорошо и используется хорошо.

                                                                  «Кроме того, уровень многих программистов низок, и в ходе написания ORM они еще ухудшают ситуацию, делаю «прослойку» еще более неэфффективной и требовательной к ресурсам.»
                                                                  Это верно и для чистой RDBMS.

                                                                  «Также ORM'ы плохо работают там, где надо работать с группами сущностей (особенно большими), а не отдельнми объектами.»
                                                                  Почему? Аргументируйте.

                                                                  «Опять же, БД с большими таблицами работают замечательно.»
                                                                  На стороне клиента-то? И давно вы читали на клиентской стороне рекордсет записей так в миллион?

                                                                  «И все попытки их как-то по-другому представить будут вести к низкой эффективности операций с ними. „
                                                                  Вы забываете о том, что они уже “как-то иначе» представлены. Маппинг так или иначе существует, пусть он и идет на объект типа датасет. Единственный способ работать с данными без преобразований — это прямо в базе.
                                                                    0
                                                                    > «Потому, что способ доступа к данным, предлагаемый ORM, нельзя оптимально реализовать с существующими реляционными БД по крайней мере. „

                                                                    > Аргументируйте.
                                                                    > Почему же не знает? Вполне знает, если ORM написан хорошо и используется хорошо.

                                                                    Потому что, не знает, что программист захочет сделать. Допустим у нас есть 2 связанных таблицы, Posts и Authors :)

                                                                    $top_posts = Posts::findTopPosts();

                                                                    foreach ($top_posts as $post)
                                                                    {
                                                                    echo «Post: {$post->title} written by {$post->author->name} \n»;
                                                                    }

                                                                    Сколько тут будет SQL запросов? Даже если использовать исхищрения вроде lazy load, сначала будет сделан запрос на выборку записей из Posts по условию (причем выбраны скорее всего будут все поля. хотя нам нужны только title), а потом — N запросов на выборку из таблицы authors. В момент выполнения первого обращения к $post->title ORM не знает, что дальше программист полезет в $post->author->name, и не может заранее выбрать нужные данные.

                                                                    Заметьте, что мой пример предельно упрощен. В реальности количество операций доступа к объекту ORM намного больше и автоматически сгенерировать «хороший» запрос нельзя. Заметьте, что я описываю работу ORM, написанного хорошими программистами а в реальности их пишет кто попало и эффективность будет еще ниже.

                                                                    Кроме того, если вы посомтрите на исходный код любого ORM вы увидите, насколько он сложен и громоздок (хотя раз вы из защищаете, вы видимо этого не делали). Логика подсказывает, что городить кучу сложного неэффективного кода только для того чтобы сделать «переносимые» обращения к хранилищу — не стоит того.

                                                                    Еще одна странная особенность ORM — критерии. Вам никогда не казалось глупым городить кучу объектов, для того чтобы вместо «photos_count > 10» написать new Criteria(new CompareCriteria(PhotosModel::PHOTOS_COUNT, CompareCriteria::MORE, new CriteriaInterger(10)))? Какой смысл дублировать функционал, имеющийся в языке SQL?

                                                                    > Это верно и для чистой RDBMS.

                                                                    Правильно, а в случае с ORM прослоек больше и багов, и неэффективного кода — больше.

                                                                    > «Также ORM'ы плохо работают там, где надо работать с группами сущностей (особенно большими), а не отдельнми объектами.»
                                                                    > Почему? Аргументируйте.

                                                                    Потому что есть штуки вроде UPDATE posts SET deleted = 1 WHERE author_id = $id, а с ORM — будет цикл с чтением/записью объектов в БД по одному.

                                                                    > «Опять же, БД с большими таблицами работают замечательно.»
                                                                    > На стороне клиента-то? И давно вы читали на клиентской стороне рекордсет записей так в миллион?

                                                                    Зачем? Это ORM-подход — все прочитать, а потом уже разбираться. Можно использовать возможности SQL для обработки записей. Для миллиона записей это будет самый оптимальный способ.

                                                                    > «И все попытки их как-то по-другому представить будут вести к низкой эффективности операций с ними. „
                                                                    > Вы забываете о том, что они уже “как-то иначе» представлены. Маппинг так или иначе существует, пусть он и идет на объект типа датасет. Единственный способ работать с данными без преобразований — это прямо в базе.

                                                                    Есть большая разница, когда у нас есть сто миллионов объектов якобы где-то в памяти, и мы можем работать с ними как хотим( по крайней мере абстракция создает такое ложное ощущение), или же когда мы знаем, что мы работаем с явно выбранными до этого записями. С ORM мы даже не знаем, в сколько запросов (и будут ли они например использовать индексы) выльется та или иная операция.
                                                                      0
                                                                      «Потому что, не знает, что программист захочет сделать»
                                                                      Ну так программисту достаточно это сказать.

                                                                      "$top_posts = Posts::findTopPosts();

                                                                      foreach ($top_posts as $post)
                                                                      {
                                                                      echo «Post: {$post->title} written by {$post->author->name} \n»;
                                                                      }

                                                                      Сколько тут будет SQL запросов? Даже если использовать исхищрения вроде lazy load, сначала будет сделан запрос на выборку записей из Posts по условию (причем выбраны скорее всего будут все поля. хотя нам нужны только title), а потом — N запросов на выборку из таблицы authors. В момент выполнения первого обращения к $post->title ORM не знает, что дальше программист полезет в $post->author->name, и не может заранее выбрать нужные данные."

                                                                      $top_posts = Posts::findTopPosts();

                                                                      foreach ($top_posts as $post)
                                                                      {
                                                                      echo «Post: {$post->title} written by {$post->author->name} \n»;
                                                                      }

                                                                      Сколько тут будет SQL запросов? Даже если использовать исхищрения вроде lazy load, сначала будет сделан запрос на выборку записей из Posts по условию (причем выбраны скорее всего будут все поля. хотя нам нужны только title), а потом — N запросов на выборку из таблицы authors. В момент выполнения первого обращения к $post->title ORM не знает, что дальше программист полезет в $post->author->name, и не может заранее выбрать нужные данные."

                                                                      Берем и правим:

                                                                      Posts::findTopPosts().With($post->title).With($post->author.With($author->name))

                                                                      (если ваш язык не умеет лямбды — извините. Берите ORM, который умеет)

                                                                      Все, в базу уйдет ОДИН запрос.

                                                                      «хотя раз вы из защищаете, вы видимо этого не делали»
                                                                      Конечно не делал. Чукча не читатель, чукча писатель — я написал два разных универсальных ORM, не считая еще нескольких объектных DAL.

                                                                      «Логика подсказывает, что городить кучу сложного неэффективного кода только для того чтобы сделать «переносимые» обращения к хранилищу — не стоит того.»
                                                                      Вы просто не понимаете, что задача ORM — не «переносимые» обращения. Задача ORM — представить базу в виде объектов. Типизованных. Все. Больше ничего.

                                                                      «Вам никогда не казалось глупым городить кучу объектов, для того чтобы вместо «photos_count > 10» написать new Criteria(new CompareCriteria(PhotosModel::PHOTOS_COUNT, CompareCriteria::MORE, new CriteriaInterger(10)))?»
                                                                      Во-первых, не казалось, потому что критерий «photos_count > 10» не проверяем в компайл-тайме. Что на наличие поля photos_count, что на его тип.

                                                                      Во-вторых, я уже давно и спокойно пишу Context.Albums.Where(album => album.Photos.Count() > 10), и у меня все работает. Никакой кучи объектов — и полная проверка валидности обращения в компайл-тайм, если в альбоме нет коллекции фотографий, то и выражение не скомпилируется.

                                                                      «Потому что есть штуки вроде UPDATE posts SET deleted = 1 WHERE author_id = $id, а с ORM — будет цикл с чтением/записью объектов в БД по одному.»
                                                                      Во-первых, в любом адекватном ORM можно прочитать оптом и записать оптом. Во-вторых, такие операции надо делать на стороне БД, и для этого есть data methods. В-третьих, в реальности это наверняка бизнес-поведение, и его можно спрятать в объект, который и спроецирует его на базу.

                                                                      «Это ORM-подход — все прочитать, а потом уже разбираться.»
                                                                      Это подход плохого программиста (я вот как раз уже несколько месяцев чищу сугубо RDBMS-oriented код, в котором все делается именно так). Подход ORM — прочитать, преобразовать, отдать. «Все» нигде не фигурирует.

                                                                      «С ORM мы даже не знаем, в сколько запросов (и будут ли они например использовать индексы) выльется та или иная операция. „
                                                                      Ну так просто надо это знать. С RDBMS вы тоже это не всегда знаете.

                                                                      Любой механизм требует изучения. ORM — тоже. Нельзя работать с данными, отдаваемыми ORM так же, как с любыми другими данными, точно так же, как нельзя работать с данными из веб-сервиса так же, как с любыми другими. Точно так же, как надо учитывать особенности работы рекордсетов и курсоров при работе с ними. В момент, когда программист это понимает, работа становится прозрачной.
                                                                        0
                                                                        > Берем и правим:

                                                                        > Posts::findTopPosts().With($post->title).With($post->author.With($author->name))

                                                                        … и получаем тот же SQL только другими словами и с большой тяжелой библиотекой для его разбора.

                                                                        > Во-вторых, я уже давно и спокойно пишу Context.Albums.Where(album => album.Photos.Count() > 10), и у меня все работает. Никакой кучи объектов — и полная проверка валидности обращения в компайл-тайм, если в альбоме нет коллекции фотографий, то и выражение не скомпилируется.

                                                                        Гм, интересная конечно штука, но ведь все равно за ней скрывается множество классов (читай, дублирующих SQL) и в рантайме из них составляется (не мгновенно) запрос, только ради проверки типов?? Плюс, оно доступно только в проприетарном и тяжелом .NET. А как же Ява например? Там вроде этого нет, что делать? Я уж не говорю про PHP :)

                                                                        > Никакой кучи объектов — и полная проверка валидности обращения в компайл-тайм, если в альбоме нет коллекции фотографий, то и выражение не скомпилируется.

                                                                        Ну у нас в PHP нестрогая типизация. Компилируется практически все, что угодно :)
                                                                          0
                                                                          "… и получаем тот же SQL только другими словами"
                                                                          Не тот же, а типизованный на языке выполнения. Что круто.

                                                                          «только ради проверки типов?»
                                                                          Вы не поверите, сколько ошибок экономит это «только». Не говоря уже о том, что не только типов, но и свойст, собственно объектов и так далее. Это как перейти от языка с динамической типизацией к языку со статической — сразу количество ошибок кода уменьшается в разы. Это сильно перевешивает те доли процента производительности, которые нужны на пробег дерева выражений.

                                                                          «оно доступно только в проприетарном и тяжелом .NET»
                                                                          Это эти конкретные лямбды доступны только в .net (оставим эпитеты на вашей совести). А другие языки используют другие методы привязки. Всего-то. К ORM как парадигме это отношения не имеет.

                                                                          «у нас в PHP нестрогая типизация. Компилируется практически все, что угодно»
                                                                          Сочувствую. Неудивительно, что вам в PHP выгоды ORM неочевидны.
                                                                        0
                                                                        Еще одна странная особенность ORM — критерии.
                                                                        А, вы тоже об Propel обожглись? Ничего, он и так ещё то поделие. По крайней мере, был в 2008-2009.
                                                                          0
                                                                          не знает, что программист захочет сделать
                                                                          Ну, а так?
                                                                          Copy Source | Copy HTML
                                                                          <?php
                                                                          $posts = PostQuery::create('p')
                                                                              ->joinUsers()
                                                                              ->joinComments()
                                                                              ->limit(sfConfig::get('app_overview_page_post_count'))
                                                                              ->sortByCreatedAt()
                                                                              ->countComments()
                                                                              ->execute();
                                                                            0
                                                                            Кроме того, если вы посомтрите на исходный код любого ORM вы увидите, насколько он сложен и громоздок
                                                                            Конечно, сложен! Mapping-то ни разу не тривиальный, не?
                                                                              0
                                                                              с ORM — будет цикл с чтением/записью объектов в БД по одному.
                                                                              Вот, значит, как на самом деле работает Doctrine_Query::create()->update()->from('Post p')->set('p.deleted', 1)->where('p.author_id = ?', $id)->execute(). Спасибо, буду знать. Ещё бы разобраться, почему в логах сервера один запрос UPDATE…, как и заказывали — но это уже детали. Ведь истинный путь уже указан. И сговор этих недопрограммистов, которые пишут свои ORMы, с разработчиками СУБД обязательно будет разоблачён.
                                                                                0
                                                                                Так это и есть SQL запрос, только записанный в другом виде. Я сам такую библиотеку пишу (только без доктриновской монструозности). Тут нет ORM.

                                                                                ORM — это так: foreach (Posts::find('author = ?', $id) as $post) { $post->deleted = 1; }

                                                                                  0
                                                                                  Нет, это запрос, который транслируется в SQL. Разница есть, и уж вам-то это должно быть понятно без подсказок.
                                                                                  ORM — это так:…skip…
                                                                                  О, а это идея. «Есть ORM, есть хорошие ORM, и есть Doctrine».
                                                                                0
                                                                                Зачем? Это ORM-подход — все прочитать, а потом уже разбираться…
                                                                                Вы на вопрос не ответили.
                                                                          +1
                                                                          раскидывать по всему коду INSERT'ы и SELECT'ы
                                                                          — злее вот этого только Сатана.

                                                                          генерит запросы чуть ли не 5-6 уровней вложенности и кучу временых таблиц.

                                                                          Это ведь не проблема самого принципа ORM?
                                                                            0
                                                                            «одна прослойка у нас работает через одно место» ⇒ «все прослойки — зло».
                                                                            Я вас правильно понимаю ход ваших рассуждений?
                                                                            0
                                                                            По поводу распространения ПО на ООБД, его не так уж и мало, дело в том что большинство такого ПО создается например для гос.нужд (Служба занятости, Пенсионный фонд), в банках. ну в общем в сферах не самых распространенных. И там где была доказана их эффективность
                                                                            сам я работаю с субд Intersystems Cache, и принимал участие в нескольких разных разработках
                                                                            преимущества ообд перед реляционными, есть хотя бы в том, что имея в наличии только субд, без сторонних разработок, можно написать готовое приложение с использованием только языка оосубд
                                                                            а также наличие объектного доступа, добавляет кучу преимуществ, по манипуляции с данными
                                                                              0
                                                                              У нас в России до сих пор хватает решений, где бизнес-логика реализована в виде хранимых процедур (в основном используют Oracle). Но я не считаю это преимуществом реляционных БД и вам не рекомендую считать преимуществом ООБД. Спорный это момент. Обычно — в производительности выигрываешь, в скорости разработки проигрываешь.
                                                                                0
                                                                                А не поделитесь ли здесь опытом использования, какой-нибудь «нутрянкой»? Например, за счет чего они декларируют себя быстрее SQL? Тема интересует.
                                                                                  0
                                                                                  декларируют себя быстрее SQL, в основном на основе сравнительных тестов
                                                                                  дело в том еще как сравнивать Cache и реляционные БД, в ней используется несколько способов доступа к данным
                                                                                  к примеру в Cache, если нужно получить данные по которым построен индекс, обойти эти данные можно используя SQL, либо обратившись напрямую к данным где хранится индекс и самому программно пройтись по нему, если случаи когда это оправдано.
                                                                                –1
                                                                                занятно.
                                                                                  0
                                                                                  Я за то, чтобы не перемешивать контроллер с моделью. В то же время считаю реляционную концепцию гениальной. В любых сущностях абстракции никогда не претендовали на замену собой низкого уровня.
                                                                                    0
                                                                                    Ассемблер тоже гениален, никто не спорит. Все от задач, масштабов и сроков зависит.
                                                                                    +2
                                                                                    1. Делая запрос в релационных рбд каждый раз приходится полностью или частично указывать модель данных (пересечение таблиц, импортируемые ключи), а это не есть хорошо. В ообд модель данных определяется один раз и используется автоматически при запросах.
                                                                                    2. Рбд не поддерживают наследование в полной мере.
                                                                                    3. Попытка реализовать иерархическую модель в рбд также упирается в сложности, особенно если модель с нечеткой структурой.
                                                                                    4. Для ОРМ можно легко и прозрачно использовать кэш-прослойку между бизнес леером и datastore (JBoss Cache, Oracle Coherence). Как показывают тесты, производительность в таком случае увеличивается в разы.
                                                                                    5. ОРМ-объекты могут предоставлять бизнес приложению более гибкие средства доступа к данным, например можно мепить значения полей в свои типы. Тогда как набор типов в SQL очень ограничен (например далеко не все поддерживают тип поля Array).
                                                                                    6. Реальная переносимость у SQL никакая. Приложение, написанное для Oracle, 100% не будет работать на MSSQL. Тогда как для ORM нужно поменять всего лишь пару строчек.
                                                                                    7. И последнее. Даже если использовать голый SQL, на каком-то этапе приложения все-равно придется меппинг полей в бизнес-объекты (напр. для представления или для отдачи вебсервису). Так или иначе придется организовывать свой уровень DAO. И ORM здесь возьмет на себя всю рутинную часть задачи.
                                                                                      0
                                                                                      боже, как все всё всегда усложняют
                                                                                      «select name, value from MyTable where id = ?»
                                                                                      скажите, этот запрос разве непереносим?
                                                                                      зачем писать то, что не переносимо?
                                                                                        0
                                                                                        А вы попробуйте написать переносимый запрос, эффективно работающий с иерархическими данными. Или с блобами. Или с полнотекстовым поиском.

                                                                                        Сразу становится понятно, зачем писать то, что непереносимо.
                                                                                          0
                                                                                          1. в приведенном выше запросе ничто не мешает полям name или value быть типа blob
                                                                                          2. о каких эффективных запросах вы говорите? select? можно, например для oracle, написать что-то типа «select oracle_super_performance_magic_key name, value as blob from MyTable where id = ?» и такой запрос в oracle вытянет blob с потрясающей быстротой?
                                                                                          3. как вы работаете с иерархическими данными? вытягиваете всю иерархию сразу? если нет, то какая разница: иерархия это или нет? вытянул объект и забыл. надо у него потомков — вытянул и их: опять-таки одним простым запросом.
                                                                                            0
                                                                                            «о каких эффективных запросах вы говорите? select? можно, например для oracle, написать что-то типа «select oracle_super_performance_magic_key name, value as blob from MyTable where id = ?» и такой запрос в oracle вытянет blob с потрясающей быстротой?»
                                                                                            А вот нет. Я хочу читать данные секторами (и писать секторами). И вот сделать это переносимо — нельзя. Поэтому и выше в запросе name и value могут быть блобом, только нафиг мне нужен двухгиговый блоб в памяти?

                                                                                            «если нет, то какая разница: иерархия это или нет?»
                                                                                            Большая. Напишите мне один простой запрос, возвращающий всех предков заданной точки дерева. Удалось? Теперь напишите такой же простой запрос, который вставит узел в это дерево в произвольную точку.
                                                                                              0
                                                                                              ну два запроса… сначала вставить узел, а потом обновить указатели на родителя у узлов-потомков, чтобы они ссылались на новый узел
                                                                                              кроме того, я не понимаю зачем в базе данных хранить объекты размеров в 2 гб. в таком случае я храню их в файлах, а в базе делаю ссылку на файл. чем это хуже?
                                                                                                0
                                                                                                «ну два запроса… сначала вставить узел, а потом обновить указатели на родителя у узлов-потомков, чтобы они ссылались на новый узел»
                                                                                                Схема с pattern id? Таки покажите мне запрос, которым вы выберете всех предков одного узла. Вверх до корня. Одним запросом.

                                                                                                «кроме того, я не понимаю зачем в базе данных хранить объекты размеров в 2 гб. в таком случае я храню их в файлах, а в базе делаю ссылку на файл. чем это хуже?»
                                                                                                Потерей целостности, например. Проблемами с блокировками. Проблемами при разнесении на фермы. Да мало ли чем еще.
                                                                                                0
                                                                                                > Большая. Напишите мне один простой запрос, возвращающий всех предков заданной точки дерева.

                                                                                                Nested Trees? Materialized Path? там вроде 1 запросом это делается.

                                                                                                А вообще, вы так говорите, как будто только от наличия ООБД эти проблемы с хранением иерархических данных сами собой решатся. Все равно данные физически где-то хранятся, и для эффективной работы с ними нужны всякие хитрости, и реляционные БД дают нам возможность их применять (за счет более низкоуровневого доступа к данным), а ООБД просто будут их прятать. Не факт, что оптимальным образом.
                                                                                                  0
                                                                                                  Я же специально сказал — и один запрос на вставку узла (если удалось — на перемещение). Там, где можно сделать выборку одним запросом, нельзя сделать вставку одним запросом. Там, где можно сделать вставку, нельзя выборку. Плавали.

                                                                                                  «А вообще, вы так говорите, как будто только от наличия ООБД эти проблемы с хранением иерархических данных сами собой решатся.»
                                                                                                  Вы немного потеряли тему. Речь шла исключительно о том, зачем писать непереносимые запросы. ООБД тут уже не при чем.
                                                                                                    +1
                                                                                                    > Речь шла исключительно о том, зачем писать непереносимые запросы.

                                                                                                    Ок, я вас понял. Разве что замечу, что ORM — плохой способ решения проблемы абстракции от особенностей БД в силу неэффективности своей реализации и изначально неудачной концепции (представление всех данных в виде набора объекта, при том что физически данные лежат в таблицах где-то на диске).
                                                                                                      0
                                                                                                      … а это мы с вами обсудим выше.

                                                                                                      И, спешу заметить, задача ORM — не в том, чтобы абстрагироваться от особенностей БД (хотя, конечно, это приятный бонус).
                                                                                          0
                                                                                          > 2. Рбд не поддерживают наследование в полной мере.

                                                                                          А по-моему очень даже поддерживает. Я использую даже множественное наследование и всю логику пишу руками (пока, уже пишу собственный генератор) на T-SQL ввиде хранимок, функций и вьюх. Пример (sql-скрипт): webfile.ru/4486966
                                                                                            0
                                                                                            Это не совсем наследование, это что-то вроде «костыля» для наследования, а тем более для множественного. На практике у Вас выходит что у Персоны и у Партнера должны быть одинаковые ИДы, а если Вы уже занесли в базу человека (допустим с ИД = 5), потом занесли в базу несколько Партнеров (с ИДами 5,6,7), а потом пытаетесь устроить того человека на работу, то у Вас возникнет косяк с органичениями на ключи, потому что ФК идет от одного поля к двум таблицам. У Вас получилась неявная, нигде в СУБД не контролируемая связь таблиц Персона — Партнер. Это черевато большими проблемами в будущем.
                                                                                              0
                                                                                              Да, Вы правы, но одиночное наследование по этой схеме пока работает безотказно. И не только у меня — этот подход применяется, например, в Entity Framework.
                                                                                          0
                                                                                          в чем проблемы с доступом к объектам, если есть orm наподобие hibernate?
                                                                                          кроме того, излишняя нормализация вредна в большинстве случаев и приводит с десяткам бесполезных раздробленных таблиц для каждого чиха
                                                                                            0
                                                                                            Быть может какое-то странное мнение о ООБД, но мне кажется, что эта идея умрёт быстрее, чем появится нормальная теория. Пик ООП, как идеи, уже прошёл (понятно что как технология он используется повсеместно), новых идей уже не видно, кучи проблем очевидны (сколько книг написано о патернах использования, очень напоминает рекомендации в стиле, goto используйте только вот так, в до структурную эпоху). Сейчас всё больший оборот набирает функциональщина, и, быть может, когда-нибудь через 10-ок другой лет она станет мэйнстримом.
                                                                                              0
                                                                                              достаточно интересных стаей? =) начало топика
                                                                                                0
                                                                                                ORM — гадость (по крайней мере сделанные на PHP), тяжелые, содранные с Ява-аналогов и неповоротливые. В чем смысл хранимых процедур тоже кстати особо не понимаю.

                                                                                                Ну а насчет ООБД — не знаю, мне кажется традиционные системы вроде MySQL не первый год существуют, хорошо изучены и всяко лучше.
                                                                                                  0
                                                                                                  Если учесть, что в мускуле до 5-й версии ХП и в помине не было, а в пятой их писать было большим гемороем, то неудивительно что не понимаете в чем их смысл. Я бы Вам посоветовал почитать про T-SQL или PL\SQL и оптимизатор запросов в них, как строятся планы запросов для ХП и для прямых запросов, как оптимизатор использует таблицы индексов — тогда поймете для чего нужны ХП.
                                                                                                    0
                                                                                                    До того, как в MySQL 4 появились внешние ключи, я не понимал в чём смысл MySQL и вообще не считал её серьёзной СУБД :-)
                                                                                                    0
                                                                                                    > В чем смысл хранимых процедур тоже кстати особо не понимаю.

                                                                                                    Не думаю что здесь есть чем похвастаться, возможно это у Вас ещё впереди. Лично я только с опытом (которого, признаюсь, мне всё ещё недостаёт, но я активно работаю над этим), на практике, я начал понимать смысл не только хранимых процедур, но и вьюшек и функуий и триггеров. Сейчас мне очень нехватает возможности использовать исключения в функциях на T-SQL, в то время как когда я впервые познакомился с исключениями 8 лет назад в С++, я не понимал зачем городить лишние сущности когда можно просто возвратить -1.
                                                                                                      –1
                                                                                                      > Лично я только с опытом (которого, признаюсь, мне всё ещё недостаёт, но я активно работаю над этим), на практике, я начал понимать смысл не только хранимых процедур, но и вьюшек и функуий и триггеров.

                                                                                                      Касательно процедур и триггеров, просто у меня есть мнение, что какую-то логику проще закладывать в код приложения, где мы можем пользвоаться всеми возможностями языка, отладкой, ООП и прочими радостями (плюс SVN :) ), а не в примитивный SQL, не находите?
                                                                                                        –1
                                                                                                        согласен с вами полностью.
                                                                                                        хранимки — это прошлый век, от которого пахнет большими скучными корпорациями.
                                                                                                        особенно считаю бессмысленным писать автогенераторы хранимок, использовать всякие вьюшки и пр. мутотень.
                                                                                                        полезно иногда следовать принципу kiss — keep it simple, stupid
                                                                                                          0
                                                                                                          А что же Вы тогда предлагаете использовать вместо хранимок, раз уж это прошлый век?
                                                                                                            0
                                                                                                            вместо них можно использовать обычные sql-запросы :)
                                                                                                            а логику хранимок зашивать в код на ЯВУ (как сказали выше), в ООП, полиморфизм и прочие страшные слова
                                                                                                              +1
                                                                                                              А как же оптимизатор запросов, план выполнения запроса (в частнсти сохраненный план запроса для ХП)? Или Вам эти понятия ни о чем не говорят?
                                                                                                                –1
                                                                                                                да, ни о чем почти не говорят
                                                                                                          0
                                                                                                          А никто и не говорит при написании ХП о закладывании логики в SQL — ХП для выборки данных это не логика, а они ускоряют работу существенно (почитайте все же про оптимизатор запросов).

                                                                                                          примитивный SQL, не находите?

                                                                                                          где Вы нашли примитивный SQL? В MySQL когда-то он и был примитивным, но уж поверьте мне T-SQL и уж тем более PL\SQL далеко не примиитивные языки (если сомневаетесь — почитайте доки на эту тему).

                                                                                                          К тому же, как вы собираетесь использовать все возможности языка для построения объединений таблиц? SQL это сделает гораздо быстрее, будет использовать индексы и ключи.

                                                                                                          Причем тут SVN я вообще не понял.
                                                                                                            0
                                                                                                            > А никто и не говорит при написании ХП о закладывании логики в SQL — ХП для выборки данных это не логика, а они ускоряют работу существенно (почитайте все же про оптимизатор запросов).

                                                                                                            По моему есть только один способ оптимизации запросов на выборку — выбирать по индексу. Если требуется fullscan — БД все равно придется проходить по всем записям, хоть вызывай запрос с клиента, хоть из ХП.

                                                                                                            > где Вы нашли примитивный SQL?

                                                                                                            Ну допустим я его в совершенстве не знаю, но примеры, которые есть в википедии, напоминают скорее порядком устаревший бейсик, чем современные языки с ООП, примесями, замыканиями и прочими хитростями. Хотя наверно оно в БД и не требуется.

                                                                                                            > К тому же, как вы собираетесь использовать все возможности языка для построения объединений таблиц? SQL это сделает гораздо быстрее, будет использовать индексы и ключи.

                                                                                                            Я отрицательно отношусь к идее объединения таблиц, по моему оно тормозит и сложно оптимизируется, особенно если этих таблиц много.
                                                                                                              0
                                                                                                              поддерживаю, чувак! объединение таблиц — зло! я серьезно. все эти left join-ы до добра не доведут…
                                                                                                                0
                                                                                                                Правильно! все данные надо хранить вообще в денормализованной таблице Excel, чтобы в любой момент можно было открыть без написания всяких запросов на примитивном SQL.
                                                                                                                  0
                                                                                                                  А вы в курсе, что для серьезных систем это обязательное требование, дублировать всю информацию в plain-text? На случай, если СУБД внезапно наебнется или ключевой человек (который все знает и умеет) изчезнет, и не будет возможности оперативно вытаскивать ценные данные из бесформенной груды байтов.
                                                                                                                    +2
                                                                                                                    На случай если СУБД наебнется делаются бекапы, миррор-сервера, рейд-массивы (если еще и за железо боитесь.

                                                                                                                    Если ключевой человек (который все знает и умеет) один на весь проект, то это несерьезная система. А если к тому же нет нормальной документации, то это 200% не серьезная система.
                                                                                                                      +1
                                                                                                                      Поясняю подробнее. Вот есть, к примеру, база данных, в которой хранятся всякие сведения по нефтяным скважинам — там сотни разных параметров. И хранятся они не один год. А лет через 20 вдруг понадобилось эти данные куда-то перегнать, а их хрен вытащишь — в прикладном софте это не предусмотрено, да и сам софт уже нерабочий, автор изчез, прога заблокирована, админских логинов-паролей никто не знает. Зато все бекапы, рейд-массивы и кластеры в полном порядке. И документация к ним есть, но только это не описание структуры файлов хранилища и структуры метаданных приложения, а простое руководство пользователя.

                                                                                                                      Скажу проще, у меня торговая первичка (порядка 30 000 документов в день) в CSV дублируется, а ее потом можно и Экзель пихать, и вообще куда угодно. Понадобились мне данные за 2001 год, когда еще в лохматом Парусе работали — я эту базу парусную и не смогу открыть, она на Netware. А так — у меня есть текстовый реестр клиентов, реестры документов, которые можно обычным блокнотом открыть и поиском найти нужного клиента, и если его там немного, что ручками скопипастить в экзель. А если много, то скорость обработки текстового файла ~= скорости чтения с диска.
                                                                                                                +1
                                                                                                                По моему есть только один способ оптимизации запросов на выборку — выбирать по индексу.
                                                                                                                Вы ошибаетесь — почитайте про оптимизатор запросов в таких СУБД как MS SQL или Oracle.

                                                                                                                Ну допустим я его в совершенстве не знаю, но примеры, которые есть в википедии
                                                                                                                Познакомтесь не только с примерами в википедии, а лучше поработайте с ним года два-три и тогда поймете всю его мощь.

                                                                                                                Я отрицательно отношусь к идее объединения таблиц, по моему оно тормозит и сложно оптимизируется,
                                                                                                                А структуру данных вы не нормализуете? Или нормализация — это лишняя трата времени на проектирование?
                                                                                                              +1
                                                                                                              Во-первых я не нахожу SQL (по крайней-мере T-SQL) примитивным, я нахожу его восхитительным, хотя там и есть что расширить (например те же исключения). Часто на SQL можно записаит задачу гораздо короче и красивее чем на обычном алгоритмическом языке. По моему мнению пренебрежение использования domain-specific языками и стремления описать всё, к примеру, на C++ или PHP — распространённая ошибка.

                                                                                                              Кроме того не вижу причин не хранить SQL-скрипты в SVN вместе с остальным кодом. Всегда так делали. Все SQL-файлы (создающие структуру базы с нуля, заполняющие базу тестовыми данными, создающие (а перед директивой создания идёт директива удаления если она уже есть) процедуры и т.п. включаются в проект в Visual Studio или NetBeans на оавне с другими файлами и версионируются как и все остальные).
                                                                                                                0
                                                                                                                По поводу языка для процедур и триггеров. Допустим, мы решили все таки часть логики перенести в БД, там при добавлении комментария увеличиваетя значение поля, и т.д. Допустим, у нас есть поле content, которое содержит текст комментария с BB-code. При любом обновлении этого поля в content_html надо записать этот же текст в HTML формате. Вот тут то хранимые процедуры и оказываются бесполезными. Это к фразе «Часто на SQL можно записаит задачу гораздо короче и красивее чем на обычном алгоритмическом языке»

                                                                                                                Бейсикоподобный язык уровня 80-х годов (SET @VAR = 10) я никак красивым назвать не могу, уж извините.

                                                                                                                Ну и не очень понимаю, какая польза от процедур при выборках, если индексированные запросы они не ускорят, а запросы без индексов лучше вообще не делать.
                                                                                                                  0
                                                                                                                  > при добавлении комментария увеличиваетя значение поля, и т.д. Допустим, у нас есть поле content, которое содержит текст комментария с BB-code. При любом обновлении этого поля в content_html надо записать этот же текст в HTML формате. Вот тут то хранимые процедуры и оказываются бесполезными

                                                                                                                  Извините, не понял.

                                                                                                                  > Вот тут то хранимые процедуры и оказываются бесполезными. Это к фразе «Часто на SQL можно записаит задачу гораздо короче и красивее чем на обычном алгоритмическом языке»

                                                                                                                  Даже если вы привели пример (которого я, в прочем, не понял и прошу пояснить) задачи, которую рациональнее решить на C# или PHP чем на SQL, это не опровергает того, что всё ещё есть множество задачь, которые рациональнее решить на SQL.

                                                                                                                  > Бейсикоподобный язык уровня 80-х годов (SET @VAR = 10) я никак красивым назвать не могу, уж извините.

                                                                                                                  Я не говорю о словаре языка. Я говорю о концепции его интерпретации. SQL — декларативный язык, который ближе по своей сути, на сколько я понимаю, к Prolog и Lisp чем к C, PHP, Pascal или BASIC. Это совершенно разные вещи, требующие иного порядка мышления.

                                                                                                                  Когда я был совсем новичком и меня посадили писать одну хранимку, я начал городить в ней цикл на курсорах, потому, что я привыкмыслить в терминах алглоитмисеских языков таких как Basic и C++. Моё решение работало. Но та же задача гораздо быстрее решалась одним SELECT-ом в несколько строк. Это как последоватльно сложить n раз или одномоментно умножить на n.

                                                                                                                  Не зря в C# добавили Linq, теперь некоторые циклы конвертируются в одну строчку.
                                                                                                                    0
                                                                                                                    Ну и не очень понимаю, какая польза от процедур при выборках, если индексированные запросы они не ускорят, а запросы без индексов лучше вообще не делать.
                                                                                                                    Запрос, вызванный из языка и запрос, сохраненный в виде ХП это разные вещи по быстродействию, потому для любого запроса составляется план выполнения (если в двух словах — последовательность обхода индексов, таблиц и условий) — на составление этого плана тратится время. Но вот при «компиляции» ХП этот план составляется один раз и сохраняется в базе вместе с ХП, а при вызове запроса он строится каждый раз.

                                                                                                                    Запросы без индексов приходится делать по двадцать раз на дню, потому что существует много критериев фильтров и для всех полей бессмысленно делать индексы.

                                                                                                                    Еще раз повторюсь — чтобы не выглядеть, мягко говоря, дилетантом, потрудитесь почитать базовые вещи, а еще лучше потрудитесь из пощупать своими руками, чтобы понять что к чему.
                                                                                                                      0
                                                                                                                      Есть мнение, что вы имеете в виду сугубо конкретную СУБД (MSSQL или Oracle). Это вовсе не значит, что в других СУБД все точно так же.
                                                                                                                        0
                                                                                                                        Конечно. Говоря о ХП, я не рассматриваю СУБД, в которых их поддержка появилась «примерно вчера», как например в MySQL.
                                                                                                            0
                                                                                                            А я самописные ОРМы использую и не жужжу… У меня их даже две — статическая и динамическая.

                                                                                                            Статическая с нативными объектами языка, для больших объемов, — читает и пишет сразу целыми таблицами, относительно сложная но быстрая. По сути — классический ОРМ, когда у объекта/коллекции есть методы для записи в / чтения из БД.

                                                                                                            Динамическая — объекты могут создаваться «на лету» с любым набором полей. Значения полей в виде ассоциативного массива. Удобно, но много накладных расходов. Идеально для хранения настроек, построения сложных конфигов.
                                                                                                              0
                                                                                                              а как кешируете?
                                                                                                                0
                                                                                                                Это от задачи зависит. В статическом варианте кеширование не требуется, там данные и так в памяти сидят после первого обращения к объекту. В динамическом элементы самоубиваемые (со счетчиком ссылок). Если он вдруг заново понадобится, то проще его заново родить и из базы прочитать. А для кеширования можно завести глобальный список (вектор) созданных объектов, в котором они будут хранится, пока их оттуда не «вытеснят».
                                                                                                              0
                                                                                                              >> И только спустя некоторое время, когда база наполнится реальными данными, пройдет пару месяцев, заказчик (да и разработчик тоже) с удивлением обнаруживает, что время выборок увеличилась почти вдвое, при работе 10-20 пользователей одновременно СУБД пытается покончить жизнь самоубийством и т.д. и т.п.

                                                                                                              А и не нужно заниматься преждевременной оптимизацией. Не факт, что через пару месяцев будет именно так. А если будет — дешевле докупить еще одну железку, чем писать ручками sql.
                                                                                                                0
                                                                                                                Какую железку Вы собираетесь покупать, если за месяц объем одной таблицы вырастает до 60-90млн заисей? Здесь покупка железяки не поможет никак.
                                                                                                                  0
                                                                                                                  Поднять еще один сервер и расшардить таблицу между ними. Современные scallability-технологии в реляционных БД рулят и педалят.

                                                                                                                  Конечно, если все в таком виде, как Вы описали (10-20 пользователей вешают СУБД) то тут да, действительно проще застрелить программиста и пересесть на ООБД.

                                                                                                                  Но обычно, расходы на программиста, который строит 15-этажные SQL-запросы ручками, вместо того, чтобы доверить это нормальной ORM превышают расходы на новый сервак, при том же подъеме производительности (а в случае с дальнейшем расширением — не факт, что супероптимизированный костыль, сляпаный вручную окажется столь же масштабируемым, как средства ORM).
                                                                                                                    0
                                                                                                                    Поднять еще один сервер и расшардить таблицу между ними. Современные scallability-технологии в реляционных БД рулят и педалят.
                                                                                                                    Когда у вас каждую миллисекунду должно падать в базу 3-5 значений, то наличие второго сервера не поможет — только потреяете на взаимодействии между серверами.
                                                                                                                0
                                                                                                                Gemstone/S
                                                                                                                Если память не изменяет, то была впервые выпущена в коммерческое использование как продукт в 1991. Представляла из себя симбиоз виртуальной машины и ООБД. Современен превратилась в то, что сейчас называют distributed storage (правда не совсем честный, но зато ACID).
                                                                                                                Также можете поискать информацию про Objectivity

                                                                                                                Этим я хотел сказать, что человек который заинтересуется вопросом всерьез — найдет информацию о том, что продукты давно разработаны.
                                                                                                                  0
                                                                                                                  А я разве говорил что нет продуктов?
                                                                                                                  Есть продукты конечно же, взять ту же Jasmine от CA, но речь была о том, почему при большой популярности ООП, базы данных все равно остаются на реляционной платформе и не массово не переходят на ООБД.