Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 201
С удовольствием опишу механику работы. В ближайшее время соберусь с мыслями и напишу статью на эту тему, даже наврено из этого получится цикл статей.
Будем ждать.
Аккурат сейчас сижу и свой генератор пишу. Только как раз отличающийся универсальностью. Он будет по логической схеме сущностей генерить что угодно что из неё может следовать (create-запросы для создания новой бд, хранимки, web-сервисы, scaffold-заготовки приложений на любом нужном мне языке).
Недавно понял что слишком много времени я трачу на написание очень похожего кода и решил это автоматизировать. Погуглил, ничего готового подходящего мне не нашёл, так что вроде не велик. Говорят для написания таких штук здорово подходит Prolog, но мне пока страшновато за него браться, пишу на родных C#+LINQ+TSQL.
Недавно понял что слишком много времени я трачу на написание очень похожего кода и решил это автоматизировать. Погуглил, ничего готового подходящего мне не нашёл, так что вроде не велик. Говорят для написания таких штук здорово подходит Prolog, но мне пока страшновато за него браться, пишу на родных C#+LINQ+TSQL.
Prolog построен на правилах. Фактически, любая система, которая полностью описывается набором правил и приоритетами, может быть легко описана на Prolog.
Для изучения концепций языка потребуется:
1) Учебный курс, хотя бы простельнький
2) 1 месяц обучения (предполагается, что общие сведения о языках, построенных на правилах вывода, имеются)
После этого его уже вполне можно использовать.
Для изучения концепций языка потребуется:
1) Учебный курс, хотя бы простельнький
2) 1 месяц обучения (предполагается, что общие сведения о языках, построенных на правилах вывода, имеются)
После этого его уже вполне можно использовать.
Не могли бы вы сделал обзор существующих ООБД? Я видел что они уже существуют, но доверия не вызывают совершенно.
Правильно ли я понимаю, что документо-ориентированные ДБ — это нечто среднее между реляционными ДБ и тем, что имеете ввиду вы?
Правильно ли я понимаю, что документо-ориентированные ДБ — это нечто среднее между реляционными ДБ и тем, что имеете ввиду вы?
Можно было бы и обзор написать.
насколько я понимаю (mnogodb, lotus notes) — документоориентированные — это просто недоделанные ООБД :)
в документах есть поля данных, но нет никакой связи с методами класса (кроме типа документа)
ну и наследования никакого (развечто включать отдельным полем ссылку на экземпляр базового класса.
в документах есть поля данных, но нет никакой связи с методами класса (кроме типа документа)
ну и наследования никакого (развечто включать отдельным полем ссылку на экземпляр базового класса.
Перенесите в какой-нибудь профильный блог, пожалуйста. (Да и предыдущий свой топик можете в «Образование» перенести.)
Извините, ни о чем
И что же Вам не понравилось?
Вы как-то растеклись мыслею по древу, и фактически не произвели сравнения Реляционных БД и ООБД. Мало фактов, процентов на 90 ваш пост состоит из воды.
В самом начале раздела «Влияние ORM» вы громко декларировали что ORM сильно тормозит развитие ООБД, но дальше вы описываете чем же ORM плох. Так, а чем же он тормозит развитие?
Сравнивая СУБД и ООБД, вы описали плюсы СУБД, но где же все остальное?
Сравнивая СУБД и ООБД, вы описали плюсы СУБД, но где же все остальное?
Пардон, как можно сравнивать СУБД и ООБД? (:
Тормозит тем, что наличие ORM предоставляет разработчику иллюзию хранения объектной модели. А следовательно, конечные разработчики думают что все супер и не заморачиваются.
Наличие с++ предоставляет разработчику иллюзию присутствия в адресном пространстве программы объектной модели, а не одномерного массива байт. А, следовательно, конечные разработчики… ну, вы поняли =)
так давайте всё писать на асме или сразу в двоичном/хекс коде?
Нет, давайте все на plain sql, и никаких ORM ;)
А давайте без давайте? )
Думаю, дело не в том, что предоставляется иллюзия объектной модели, а в том, что покрытие неполное. В итоге при возникновении проблем приходится детально разбираться, что происходит и почему, и требует для использования серьезной подготовки не только в части ORM framework'а, а также в структуре и принципах работы самих реляционных БД.
А насчет иллюзии объектной модели в памяти — там-таки данная полнота присутствует, и при отсутствии хаков (а именно — отсутствии прямой работы с памятью, отведенной под объект, и магических cast'ов) данных функционал работает именно так, как ожидается.
Думаю, дело не в том, что предоставляется иллюзия объектной модели, а в том, что покрытие неполное. В итоге при возникновении проблем приходится детально разбираться, что происходит и почему, и требует для использования серьезной подготовки не только в части ORM framework'а, а также в структуре и принципах работы самих реляционных БД.
А насчет иллюзии объектной модели в памяти — там-таки данная полнота присутствует, и при отсутствии хаков (а именно — отсутствии прямой работы с памятью, отведенной под объект, и магических cast'ов) данных функционал работает именно так, как ожидается.
… можно подумать, ООБД не делает того же самого.
Поясню: ООБД дает разработчику видимость хранения объектной модели. Разработчик думает, что все супер. Но беда в том, что никто не знает, насколько все супер, и что с этим делать.
В этом отношении ОРМ и ООБД совершенно идентичны (а ООБД, как закрытая система, еще и хуже).
Мораль: что ОРМ, что ООБД просто надо тестировать под нагрузкой. И выбирать по результатам.
Поясню: ООБД дает разработчику видимость хранения объектной модели. Разработчик думает, что все супер. Но беда в том, что никто не знает, насколько все супер, и что с этим делать.
В этом отношении ОРМ и ООБД совершенно идентичны (а ООБД, как закрытая система, еще и хуже).
Мораль: что ОРМ, что ООБД просто надо тестировать под нагрузкой. И выбирать по результатам.
ООБД дает разработчику видимость хранения объектной модели
По этой логике SQL Server + ORM — это ООБД?
А вот вы подумайте с точки зрения разработчика: ему ли не пофиг, вызвал он метод ORM, вернувший набор объектов по заданному критерию, или же вызвал он метод ООБД-провайдера, вернувший тот же набор объектов по тому же критерию?
В обоих случаях мы дернули черный ящик, получили результат, только в первом случае черный ящик состоит из двух известных нам слоев (ORM — RDBMS), а в другом — из одного (ООДБ, причем какая у нея внутре неонка, мы не знаем).
В обоих случаях мы дернули черный ящик, получили результат, только в первом случае черный ящик состоит из двух известных нам слоев (ORM — RDBMS), а в другом — из одного (ООДБ, причем какая у нея внутре неонка, мы не знаем).
Давайте не будем думать с т.з. разработчика, а все-таки посмотрим с т.з. того, что говорит теория. Есть различные модели данных, на их основе строятся соответствующие БД и СУБД.
А вы утверждаете, что при использовании ООП и соответствующей прослойки любая БД — это ООБД. Вы неправы. Термин «объектно-ориентированная БД» лежит на том же уровне, что и реляционная БД, сетевая, иерархическая и т.д., но никак не выше.
А вы утверждаете, что при использовании ООП и соответствующей прослойки любая БД — это ООБД. Вы неправы. Термин «объектно-ориентированная БД» лежит на том же уровне, что и реляционная БД, сетевая, иерархическая и т.д., но никак не выше.
«вы утверждаете, что при использовании ООП и соответствующей прослойки любая БД — это ООБД»
Я этого не утверждаю. Я говорю, что недостаток «предоставляет разработчику иллюзию хранения объектной модели. А следовательно, конечные разработчики думают что все супер и не заморачиваются» равно присущ как ORM+RDBMS, так и ООБД (и чистым RDBMS тоже, кстати).
Теория — это хорошо, но в теории ORM, например, генерит «чистый код».
Нам интереснее практика.
Я этого не утверждаю. Я говорю, что недостаток «предоставляет разработчику иллюзию хранения объектной модели. А следовательно, конечные разработчики думают что все супер и не заморачиваются» равно присущ как ORM+RDBMS, так и ООБД (и чистым RDBMS тоже, кстати).
Теория — это хорошо, но в теории ORM, например, генерит «чистый код».
Нам интереснее практика.
А на какой именно модели данных строится ООБД?
Как ни странно, на объектно-ориентированной :).
шутник… Как они так данные на диске хранят, чтоб доступ был быстрый, и при этом не модель была не реляционной?
Без шуток. Потому что модель данных и способ их хранения на диске — это в общем-то перпендикулярные вещи. ООБД внутри данные может хранить точно так же, как и РБД.
Про внутренности — это все так давно было, что я уже могу и позабыть. Кто-то использует append write, кто-то деревья, кто-то это все комбинирует. Вариантов много. К сожалению, я не могу сейчас дать каких-то конкретных ссылок. Это можно попробовать погуглить по фразам "<название БД> internals".
Про внутренности — это все так давно было, что я уже могу и позабыть. Кто-то использует append write, кто-то деревья, кто-то это все комбинирует. Вариантов много. К сожалению, я не могу сейчас дать каких-то конкретных ссылок. Это можно попробовать погуглить по фразам "<название БД> internals".
Ну я полагаю что ООДБ будет быстрее чем связка ORM+RDBMS в данном случае.
А вы это полагаете, полагаю, исключительно из теоретических соображений? А как это реально обосновать?
С точки зрения логики, нативная работа со структурами данных должна быть быстрее чем их преобразование с помощью прослойки в другую форму и потом уже работа с ними.
Это когда вы решаете задачу «прочитать-записать».
А когда вы решаете задачу «найти все, удовлетворяющие условию», как тогда?
А когда вы решаете задачу «найти все, удовлетворяющие условию», как тогда?
тогда скорость сравнима. это я по опыту работы с документ-ориентированными сужу.
Вот и возникает вопрос — а за счет чего она сравнима? «Что у нея внутре»? Ведь «с точки зрения логики», сканирование табличных данных выгоднее, нежели сканирование произвольных структур. Не выходит ли так, что внутри там, на самом деле, неявная генерация табличного представления для каждого «типа» документов?
В частности, шарпойнт — тоже в каком-то смысле документоориентированная СУБД (как и TFS). Но внутри там RDBMS, просто специальным образом организованная.
В частности, шарпойнт — тоже в каком-то смысле документоориентированная СУБД (как и TFS). Но внутри там RDBMS, просто специальным образом организованная.
известно за счет чего. за счет индексов.
А без индексов? Запрос бывает и не по индексированному полю.
(а еще бывают трюки с покрывающими индексами, скажем, или полнотекстовыми, или xml — в итоге выходит, что для реализации всего этого проще взять движок RDBMS и немного допилить напильником. Смотри на шарпойнт.)
(а еще бывают трюки с покрывающими индексами, скажем, или полнотекстовыми, или xml — в итоге выходит, что для реализации всего этого проще взять движок RDBMS и немного допилить напильником. Смотри на шарпойнт.)
А без индексов будет феерический звездец по производительности)))
Не спорю с этим.
Но есть несомненный выигрыш изза нативности хранения данных. Я лично щупал монгодб, там данные хранятся в BSON, никакого отношения к RDBMS оно не имеет.
Не спорю с этим.
Но есть несомненный выигрыш изза нативности хранения данных. Я лично щупал монгодб, там данные хранятся в BSON, никакого отношения к RDBMS оно не имеет.
«А без индексов будет феерический звездец по производительности»
… что, давайте покроем все поля индексами?
«Я лично щупал монгодб, там данные хранятся в BSON, никакого отношения к RDBMS оно не имеет. „
И как bson реагирует на запрос по неидексированному полю?
… что, давайте покроем все поля индексами?
«Я лично щупал монгодб, там данные хранятся в BSON, никакого отношения к RDBMS оно не имеет. „
И как bson реагирует на запрос по неидексированному полю?
Я не предлагаю покрывать все поля индексами оО
Вы что, по всем полям ищете обычно?
Индексы должны быть для полей, по которым ищут часто.
Ну а без индекса поиск будет медленнее чем в RDBMS, безусловно.
Вы что, по всем полям ищете обычно?
Индексы должны быть для полей, по которым ищут часто.
Ну а без индекса поиск будет медленнее чем в RDBMS, безусловно.
Пользователь иногда ищет по полям, по которым индекса нет (потому что «иногда», а не «часто»). Вот и привет «с точки зрения логики нативная работа со структурами данных быстрее».
Если грамотно продумать структуру базы и архитектуру приложения, то преимущества от использования ООБД покроют недостатки медленного поиска по неиндексным полям.
Уверены, что не выйдет так, что если грамотно продумать структуру и архитектуру, то выигрыш по скорости от использования RDBMS покроет недостатки от использования не-нативного ORM?
ООБД дает разработчику видимость хранения объектной модели.
ООБД не дает видимости — ООБД хранит объектную модель, а не преобразовывает ее в реляционную и обратно на лету, как это делает ORM.
Вот лично вы знаете, во что ООБД преобразует объектную модель для хранения на диске?
Так что это тоже видимость объектной модели, просто поверх какого-то другого хранилища. И преобразование, очевидно, тоже есть.
Так что это тоже видимость объектной модели, просто поверх какого-то другого хранилища. И преобразование, очевидно, тоже есть.
Следуя этой логике резоннно задать вопрос: а как же тогда реляционные СУБД, уж не думаете ли Вы, что они хранят данные в таблицах?
Конечно на диске все хранится в виде 1 и 0, но пользователю неудобно с ними работать =)
В таком случае реляционные СУБД — это просто видимость реляционной модели. Не надо уходить на такие низкие уровни абстракции.
Конечно на диске все хранится в виде 1 и 0, но пользователю неудобно с ними работать =)
В таком случае реляционные СУБД — это просто видимость реляционной модели. Не надо уходить на такие низкие уровни абстракции.
Похоже, вы не уловили посыла.
Смысл в следующем: для получения данных из ORM over RDBMS и для получения данных из ООБД я как программист выдаю более-менее одинаковый код. В обоих случаях я, как программист, думаю, что система, с которой я работаю, делает «все супер», и заморачиваться не надо.
При этом что ООБД, что ORM легко могут все изгадить, но я, как программист, никакого контроля над этим не имею.
Смысл в следующем: для получения данных из ORM over RDBMS и для получения данных из ООБД я как программист выдаю более-менее одинаковый код. В обоих случаях я, как программист, думаю, что система, с которой я работаю, делает «все супер», и заморачиваться не надо.
При этом что ООБД, что ORM легко могут все изгадить, но я, как программист, никакого контроля над этим не имею.
Вот как раз о контроле я и говорил. Программист имеет контроль в обоих случаях и туда приходиться лезть ручками чтобы поправить то, что было изгажено, НО:
— в случае с ORM у вас два места, где могут быть косяки: ORM (автосгенеренные запросы и др.) и RDBMS (настрйока индексов и др.)
— в случае с ООБД у вас только одно место, которое надо настроить: сама СУБД и если она предоставит удобный и мощный инструментарий для оптимизации и настройки, тогда будет толк.
— в случае с ORM у вас два места, где могут быть косяки: ORM (автосгенеренные запросы и др.) и RDBMS (настрйока индексов и др.)
— в случае с ООБД у вас только одно место, которое надо настроить: сама СУБД и если она предоставит удобный и мощный инструментарий для оптимизации и настройки, тогда будет толк.
… у меня есть два места, где есть косяки, и два места, где я могу улучшить.
«если она предоставит удобный и мощный инструментарий для оптимизации и настройки, тогда будет толк. „
Очень важное слово “если».
Возвращаясь к началу треда: иллюзия «все супер» есть (или нет) в обоих случаях, не надо приписывать ее только ORM.
«если она предоставит удобный и мощный инструментарий для оптимизации и настройки, тогда будет толк. „
Очень важное слово “если».
Возвращаясь к началу треда: иллюзия «все супер» есть (или нет) в обоих случаях, не надо приписывать ее только ORM.
Попробуйте улучшить статью, а не срывать злобу на моей карме ;) Говорят, второе более эффективно
Пардон, отправилось раньше.
Во-первых, более эффективно первое, а не второе, конечно :)
Во-вторых, в статье вы сами признаетесь: «Что-то меня понесло в сторону».
Я смею заметить, вас в нужном направлении никогда и не несло, похоже. Методом «с потолка» делаете какие-то выводы. Ни на одно серьезное исследование — да что там исследование, источник хотя бы — не опираетесь. Делаете тайну из того, какими промышленными ООСУБД пользовались сами.
И в заключении вывод: «Что касается перспектив реляционных БД, то я полагаю, что они будут жить еще достаточно долго». Охренительно, дружище, просто охренительно. Можно было ничего больше не писать ;) А еще этот вывод абсолютно неконтекстен, и подходит к 99 из 100 существующим на данный момент техническим решениям, безотносительно их природы или решаемой задачи.
Вода, просто вода, вам же написали выше…
Во-первых, более эффективно первое, а не второе, конечно :)
Во-вторых, в статье вы сами признаетесь: «Что-то меня понесло в сторону».
Я смею заметить, вас в нужном направлении никогда и не несло, похоже. Методом «с потолка» делаете какие-то выводы. Ни на одно серьезное исследование — да что там исследование, источник хотя бы — не опираетесь. Делаете тайну из того, какими промышленными ООСУБД пользовались сами.
И в заключении вывод: «Что касается перспектив реляционных БД, то я полагаю, что они будут жить еще достаточно долго». Охренительно, дружище, просто охренительно. Можно было ничего больше не писать ;) А еще этот вывод абсолютно неконтекстен, и подходит к 99 из 100 существующим на данный момент техническим решениям, безотносительно их природы или решаемой задачи.
Вода, просто вода, вам же написали выше…
Да, согласен, местами получилось не совсем обосновано, местами много воды, местами сбился с мысли. Но для того здесь и есть комментарии чтобы можно было покритиковать, но в предплах разумного, без перехода на оскорбления вроде
откуда вы взяли такое умозаключение? Может Вы провели серьезное исследование моей биографии и знаете куда меня несло, а куда нет?
Давайте закроем тему личностей — здесь обсуждаем реляционные и объектные БД.
Я смею заметить, вас в нужном направлении никогда и не несло, похоже
откуда вы взяли такое умозаключение? Может Вы провели серьезное исследование моей биографии и знаете куда меня несло, а куда нет?
Давайте закроем тему личностей — здесь обсуждаем реляционные и объектные БД.
К Вашей карме я и не притрагивался (не о том Вы печтесь, раз так серьезно реагируете на изменение кармы), так что не надо сразу переходить на личности.
Злобу? к чему? к комментарию из четырех слов?
Я уже давно вырос из того возраста, когда я срывался на подобного рода комментарии. Сейчас предпочитаю воспринимать их как критику и в первую очередь искать ошибки в себе, потому и попросил уточнить что же именно Вам не понравилось.
Злобу? к чему? к комментарию из четырех слов?
Я уже давно вырос из того возраста, когда я срывался на подобного рода комментарии. Сейчас предпочитаю воспринимать их как критику и в первую очередь искать ошибки в себе, потому и попросил уточнить что же именно Вам не понравилось.
>в последнее время все больше и больше идет разговоров об ООБД.
где? По-моему ООБД все больше и больше забывают. Ваша статья косвенно содержит этому подтверждение. То есть, Вы корректно изложили все недостатки ООБД и ORM, но они секретами не являются уже много лет.
где? По-моему ООБД все больше и больше забывают. Ваша статья косвенно содержит этому подтверждение. То есть, Вы корректно изложили все недостатки ООБД и ORM, но они секретами не являются уже много лет.
Конечно эти недостатки не являются секретами. Я в этой статье и не стремился открыть кому-то глаза или показать какие гениальные открытия с сделал. Просто меня очень интересует эта область, а на хабре я не нашел хороших статей на эту тему. Вот и решил начать обсуждение вопросов, касательно ООБД и смежных областей.
да, это правильно, но вот у меня в отношении например ORM для Delphi только печальные сведения. Bold вроде был жив, потом умер в Win32 и возродился в .Net, но сейчас, похоже, окончательно умер.
Разработчики клепают собственные фреймворки, но эти фреймворки дальше внутренних проектов не идут.
Разработчики клепают собственные фреймворки, но эти фреймворки дальше внутренних проектов не идут.
У Ayende Rahien в последнее время много постов по MongoDB :-) На хабре были статьи про HTML5 и ООБД. Ну и в целом, habrahabr.ru/search/?q=NOSQL.
Не путайте ООСУБД и document-oriented. MongoDB — второе, RavenDb (от Ayende) — тоже document-oriented
Я в курсе различий object и document oriented, но в контексте данной статьи на мой взгляд вполне можно объединить эти понятия.
Автор с вами не согласен:
>> В ООБД же, напротив должны храниться объекты, а объект это совокупность его свойств (параметры объекта) и методов (интерфейс объекта).
Document-oriented не хранят «свойства и методы» (которые хранятся в ООСУБД по версии автора), а значит, в контексте статьи объединить их низзя :)
>> В ООБД же, напротив должны храниться объекты, а объект это совокупность его свойств (параметры объекта) и методов (интерфейс объекта).
Document-oriented не хранят «свойства и методы» (которые хранятся в ООСУБД по версии автора), а значит, в контексте статьи объединить их низзя :)
Вынужден согласиться :-) Эх, если бы не свойства и методы… Впрочем, тот же RavenDb, несмотря на документо-ориентированную направленность с учетом автоматической сериализации/дессериализации хранит свойства объектов. И, если честно, я пока что не встречал настолько объекто-ориентированных баз данных, которые бы хранили и методы сохраняемого объекта.
В чем вообще смысл хранения методов, если они общие для всех объектов класса?
Сериализация объекта всегда была сериализацией его полей.
Сериализация объекта всегда была сериализацией его полей.
Наверно я не совсем точно выразился. Под хранением методов подразумеловась хранение поведения целого класса обектов. Здесь на самом деле кроется самое распространенное логическое недоразумение — все привыкли в реляционным БД, все привыкли что БД хранят только данны и все. Однако в случае с ООБД элементом хранения должен быть объект, который состоит не только из данных, но и из описания поведения.
Таким образом, методы (программный интерфейс объекта) должны храниться в ООБД в виде неких метаданных целого класса объектов, а, разумеется, не с самим объектом (экземпляром класса).
Таким образом, методы (программный интерфейс объекта) должны храниться в ООБД в виде неких метаданных целого класса объектов, а, разумеется, не с самим объектом (экземпляром класса).
а вот не скажите, что про ООБД забывают
я сижу на форуме по Caché
и последнее время, стало появляться все больше новичков, большинство из которых это студенты, которые пишут дипломные работы по этой субд, я думаю в институтах, похоже теперь знакомят студентов не только с реляционными субд, но и с ообд
я сижу на форуме по Caché
и последнее время, стало появляться все больше новичков, большинство из которых это студенты, которые пишут дипломные работы по этой субд, я думаю в институтах, похоже теперь знакомят студентов не только с реляционными субд, но и с ообд
У Intersystems есть программа для ВУЗов по обучению своей СУБД, лицензия дается бесплатно. Я сам учился в одном из таких.
Но Cache не ООБД ни разу!
Внизу там голые массивы, причем к ним есть прямой доступ из приложений. В ряде случаев за счет этого можно добиться роста производительности по сравнению с РСУБД. Интегрирован интерпретатор процедурного языка, к которому объекты прилеплены с помощью препроцессора. Система может представлять определенный интерес в качестве специфической базы или основы дешевого (относительно) интегратора (Ensemble = Cache+надстройка).
она постреляционная СУБД
она объектно-ореинтированная субд
она объектно-ореинтированная субд
Это они сами себя так называют — на деле там скорее пре-реляционная с эмуляцией реляционности поверх.
ну так все правильно
«пост- — приставка, имеющая значение «после»»
реляционность в ней как надстройка над принятой в СУБД системой хранения
вот пре-реляцонной она была бы, если бы все было наооборот
«пост- — приставка, имеющая значение «после»»
реляционность в ней как надстройка над принятой в СУБД системой хранения
вот пре-реляцонной она была бы, если бы все было наооборот
Неправильно. Для того, чтобы заслужить приставку «пост-» по праву необходимо что-то НАД реляционностью или ВМЕСТО нее, а не доступ к банальным массивам ПОД ней.
Объектная ориентированность там в виде… препроцессора к встроенному языку. Где там ООБД — ума не приложу.
Хотя в слове «постиндустриальный» эта же приставка используется еще хлеще :)
Объектная ориентированность там в виде… препроцессора к встроенному языку. Где там ООБД — ума не приложу.
Хотя в слове «постиндустриальный» эта же приставка используется еще хлеще :)
ВМЕСТО нее
так, реляционный доступ там, только как фишка, типа пользуйся если хочешь
Объектная ориентированность там в виде… препроцессора к встроенному языку
почему это вдруг в виде препроцессора, объектный доступ организован в самом языке COS, и чем собственно он плох для вас я не понимаю
вы скажите, что конкретно вам не нравится в Cache', за что вы его так пытаетесь опустить
может быть вы с ней вообще не работали, так почитали литературу о ней и делаете свои выводы
>почему это вдруг в виде препроцессора
Если посмотреть на генерируемые файлы — то все будет понятно: там будут исходники без объектов.
>и чем собственно он плох для вас я не понимаю
Ну почему сразу плох-то? Пафосность рекламы еще не делает систему объективно плохой.
>вы скажите, что конкретно вам не нравится в Cache', за что вы его так пытаетесь опустить
может быть вы с ней вообще не работали, так почитали литературу о ней и делаете свои выводы
Я с ней работал — хоть продакшен писать и не довелось, и литературу читал — хорошая, кстати, у них литература и документация. И опускать никоим образом не пытаюсь — весьма интересная для некоторых применений система.
Но рекламу и факты путать крайне не рекомендуется.
Если посмотреть на генерируемые файлы — то все будет понятно: там будут исходники без объектов.
>и чем собственно он плох для вас я не понимаю
Ну почему сразу плох-то? Пафосность рекламы еще не делает систему объективно плохой.
>вы скажите, что конкретно вам не нравится в Cache', за что вы его так пытаетесь опустить
может быть вы с ней вообще не работали, так почитали литературу о ней и делаете свои выводы
Я с ней работал — хоть продакшен писать и не довелось, и литературу читал — хорошая, кстати, у них литература и документация. И опускать никоим образом не пытаюсь — весьма интересная для некоторых применений система.
Но рекламу и факты путать крайне не рекомендуется.
ну вот не надо сравнивать генерируемый системный код класса, после его компиляции, и код с которым работает программист
ведь собственно класс и работает с данными хранимыми в глобалах, и то без объектов там мало где, а в основном идет работа с объектом, что то вы путаете
ведь собственно класс и работает с данными хранимыми в глобалах, и то без объектов там мало где, а в основном идет работа с объектом, что то вы путаете
Что касается ORM: вы забыли одну простую вещь — хорошая ORM уменьшает затраты на поддержку приложения, поскольку позволяет автоматически или полуавтоматически отслеживать изменения СУБД и кода. Иными словами, используя хорошую ORM мы избавлены от проблемы «в базе поменялось название поля — система молча упала».
А я и не гооврил, что ORM это плохо. Есть очень много плюсов при их использовании, однако, в противовес им появляются и недостатки, которые я описал. При изменении названия поля в базе, если Вы делали оптимизацию запросов и прописывали иих руками, то Вам их тоже придется переписывать руками.
Вообще в хорошо спроектированной системе не должны менять названия полей в базе.
Вообще в хорошо спроектированной системе не должны менять названия полей в базе.
«Есть очень много плюсов при их использовании, однако, в противовес им появляются и недостатки, которые я описал»
Это верно для любого инструмента. Я просто указал на забытый вами плюс. А минусы у них планомерно изживаются.
«Вообще в хорошо спроектированной системе не должны менять названия полей в базе. „
Чтобы система была хорошо спроектирована, в ней не должны меняться требования. Беда в том, что в реальной жизни требования меняются (иначе бы не было культа рефакторинга). А раз меняются требования, то и структура данных может меняться.
Это верно для любого инструмента. Я просто указал на забытый вами плюс. А минусы у них планомерно изживаются.
«Вообще в хорошо спроектированной системе не должны менять названия полей в базе. „
Чтобы система была хорошо спроектирована, в ней не должны меняться требования. Беда в том, что в реальной жизни требования меняются (иначе бы не было культа рефакторинга). А раз меняются требования, то и структура данных может меняться.
«А раз меняются требования, то и структура данных может меняться. „
Бывает и так, но только в том случае, если Вы недостаточно внимания уделили анализу предметной области и проектированию системы. Если изменения требований заставляет Вас изменять уже работающую часть системы, то что то идет не так.
Из последнего, года полтора назад спроектировали базу данных для одной подзадачи, и стало совсем некогда. Два месяца назад, пришел новый программист и на той модели реализовал великолепную подсистему, от которой пользователи просто в восторге.
Бывает и так, но только в том случае, если Вы недостаточно внимания уделили анализу предметной области и проектированию системы. Если изменения требований заставляет Вас изменять уже работающую часть системы, то что то идет не так.
Из последнего, года полтора назад спроектировали базу данных для одной подзадачи, и стало совсем некогда. Два месяца назад, пришел новый программист и на той модели реализовал великолепную подсистему, от которой пользователи просто в восторге.
Надо же, оказывается, требования никогда не меняются, а экстремальное программирование придумали идиоты.
Я не пытаюсь этого сказать. Вы видимо меня не правильно поняли. Я пытался сказать, что если на этапе исследования предметной области, написания функциональной спецификации, проектирования базы данных, Вы нигде не накосячили, то в большинстве случаев у Вас не должна возникнуть ситуация, когда меняется имя столбца в базе данных. При изменении требований у Вас появляются новые поля, м.б. после проверки зависимостей исчезают старые, но на рабочей системе не меняется название столбца, в следствии чего эта система и падает.
«Бывает и так, но только в том случае, если Вы недостаточно внимания уделили анализу предметной области и проектированию системы.»
Не только. Просто вам везло с заказчиком. В моей практике, когда сначала в анализе бизнес-модели одни данные, а через полгода меняется представитель заказчика — и данные вместе с ним — регулярны.
К сожалению, такова реальность, с ней ничего нельзя поделать.
Не только. Просто вам везло с заказчиком. В моей практике, когда сначала в анализе бизнес-модели одни данные, а через полгода меняется представитель заказчика — и данные вместе с ним — регулярны.
К сожалению, такова реальность, с ней ничего нельзя поделать.
Хорошо спроектированная структура должна гибко реагировать на изменения требований. Возможность изменений должна быть в нее заложена и описана изначально. Иначе через полгода разработки Вы получите ситуацию, когда придется переписать большую часть приложения, когда вдруг выяснится, что телефон оказывается надо хранить в формате "+#(###) ###-##-##", а не полем типа лонгИнт.
Неправда, к хорошо спроектированной системе могут измениться требования. Реальный мир беспощаден, и качество системы тут ни при чем.
сомневаюсь, что даже супер-хорошая ORM может при изменении структуры «низлежащих» таблиц сделать что-то кроме впадения в ступор. Допустим, средства типа Together (встроенные в Delphi, C++Builder) могут преобразовывать модель в код и код в модель. Но там уже везде объекты, поэтому мэппинг особой проблемы не представляет.
А в случае ORM over RDBMS можно идти только сверху вниз. Но если что-то поменял «внизу» (в РСУБД), то это придется вручную корректировать и вверху (в модели ORM).
А в случае ORM over RDBMS можно идти только сверху вниз. Но если что-то поменял «внизу» (в РСУБД), то это придется вручную корректировать и вверху (в модели ORM).
В случае ООБД вы получите аналогичное поведение. Поменяли поле — проект не компилируется (в случае языка со статической типизацией), или падает (в динамическом языке).
Согласен на все 100%. ORM и прочие прослойки — это зло. Хочется именно вменяемой ООБД.
С прослойками уже был печальный опыт. Попросили знакомые посмотреть почему сайт медленно ползает. Оказалось, что при размере базы всего в пару мегабайт, выбранная ими при разработке прослойка, генерит запросы чуть ли не 5-6 уровней вложенности и кучу временых таблиц. Соответственно старый добрый MySQL при смешном количестве посетителей на вполне современном железе еле ползал, т.к. сжирал всю память :(
Поэтому приходится либо писать свою прослойку между базой и объектами, либо очень аккуратно использовать готовые, т.к. раскидывать по всему коду INSERT'ы и SELECT'ы (как любят делать разработчики многих халявных CMS и подобных движков) — прошлый век. Любая попытка модифицировать такой софт превращается в ад.
С прослойками уже был печальный опыт. Попросили знакомые посмотреть почему сайт медленно ползает. Оказалось, что при размере базы всего в пару мегабайт, выбранная ими при разработке прослойка, генерит запросы чуть ли не 5-6 уровней вложенности и кучу временых таблиц. Соответственно старый добрый MySQL при смешном количестве посетителей на вполне современном железе еле ползал, т.к. сжирал всю память :(
Поэтому приходится либо писать свою прослойку между базой и объектами, либо очень аккуратно использовать готовые, т.к. раскидывать по всему коду INSERT'ы и SELECT'ы (как любят делать разработчики многих халявных CMS и подобных движков) — прошлый век. Любая попытка модифицировать такой софт превращается в ад.
«Согласен на все 100%. ORM и прочие прослойки — это зло.»
Аргументируйте. Только не почему плохо написанная прослойка зло, а почему вообще прослойки — зло. А то как бы вы сейчас вообще отвергаете идею разделения слоев.
Аргументируйте. Только не почему плохо написанная прослойка зло, а почему вообще прослойки — зло. А то как бы вы сейчас вообще отвергаете идею разделения слоев.
Не надо плодить дополнительные сущности без крайней необходимости :)
Я согласен с автором, что создание вменяемой ООБД и открытого стандарта на подобные базы это будущее баз данных (по крайней мере хотелось бы на это надеяться). Собственно это позволит убрать лишние прослойки между кодом и БД.
Пока же приходится выбирать меньшее зло :( То есть прослойки это плохо, но пока деваться некуда — приходится писать свои или использовать готовые.
Я согласен с автором, что создание вменяемой ООБД и открытого стандарта на подобные базы это будущее баз данных (по крайней мере хотелось бы на это надеяться). Собственно это позволит убрать лишние прослойки между кодом и БД.
Пока же приходится выбирать меньшее зло :( То есть прослойки это плохо, но пока деваться некуда — приходится писать свои или использовать готовые.
Вопрос в том, для начала, что такое «хорошая ООБД», и как это вообще устроить без адских потерь производительности.
С ORM все как раз понятно — хорошо сделанный ORM объединяет максимум достоинств RDBMS и ООП. А вот в ООБД с первым обычно тяжело и плохо.
С ORM все как раз понятно — хорошо сделанный ORM объединяет максимум достоинств RDBMS и ООП. А вот в ООБД с первым обычно тяжело и плохо.
В статье как раз упоминается что необходимо решить для того, чтобы создать качественную ООБД. Возьму на себя смелость процитировать:
# Язык запросов и его стандартизация.
# Математический аппарат.
# Проблема хранения данных и методов.
Пока эти вопросы не будут решены, трудно говорит о том, что такое хорошая ООБД.
# Язык запросов и его стандартизация.
# Математический аппарат.
# Проблема хранения данных и методов.
Пока эти вопросы не будут решены, трудно говорит о том, что такое хорошая ООБД.
> Только не почему плохо написанная прослойка зло, а почему вообще прослойки — зло
Потому, что способ доступа к данным, предлагаемый ORM, нельзя оптимально реализовать с существующими реляционными БД по крайней мере. Потому что ORM как бы представляет базу в виде набора объектов, которыми она *не является*. Оптимальный способ доступа к БД — выборка всех интересующих данных хорошим запросом с индесом и их разбор — и нормально составить такой запрос ORM принципиально не способен, хотя бы потому, что не знает, какие данные понядобятся в будущем.
Кроме того, уровень многих программистов низок, и в ходе написания ORM они еще ухудшают ситуацию, делаю «прослойку» еще более неэфффективной и требовательной к ресурсам. Или создают неудобства врожде требования описать все поля всех таблиц в XML-файле (типа [field name=«person_id» db_name=«person_id»/]). Интересно, они сами пробовали это сделать для типичной БД хотя бы их 20 таблиц?
Есть определенные подходы, вроде кеширования сущностей, но это попытка ценой переноса части БД в память ускорить к ней доступ. Фактически, происходит дублирование кеша БД, однако хуже реализованного, так как например в нем нет поддержки индексов. В общем, БД умеют делать это куда как лучше.
Не говоря о том, что такой подход прокатывает только в языках типа Java, а в PHP, где скрипт запускается заново при каждом запросе. становится бесполезным.
Также ORM'ы плохо работают там, где надо работать с группами сущностей (особенно большими), а не отдельнми объектами. Опять же, БД с большими таблицами работают замечательно.
Вы можете придумывать какие угодно прослойки и абстракции, но физически данные в любой БД хранятся в таблицах с индексами (а те — в файлах или в памяти). И все попытки их как-то по-другому представить будут вести к низкой эффективности операций с ними.
Потому, что способ доступа к данным, предлагаемый ORM, нельзя оптимально реализовать с существующими реляционными БД по крайней мере. Потому что ORM как бы представляет базу в виде набора объектов, которыми она *не является*. Оптимальный способ доступа к БД — выборка всех интересующих данных хорошим запросом с индесом и их разбор — и нормально составить такой запрос ORM принципиально не способен, хотя бы потому, что не знает, какие данные понядобятся в будущем.
Кроме того, уровень многих программистов низок, и в ходе написания ORM они еще ухудшают ситуацию, делаю «прослойку» еще более неэфффективной и требовательной к ресурсам. Или создают неудобства врожде требования описать все поля всех таблиц в XML-файле (типа [field name=«person_id» db_name=«person_id»/]). Интересно, они сами пробовали это сделать для типичной БД хотя бы их 20 таблиц?
Есть определенные подходы, вроде кеширования сущностей, но это попытка ценой переноса части БД в память ускорить к ней доступ. Фактически, происходит дублирование кеша БД, однако хуже реализованного, так как например в нем нет поддержки индексов. В общем, БД умеют делать это куда как лучше.
Не говоря о том, что такой подход прокатывает только в языках типа Java, а в PHP, где скрипт запускается заново при каждом запросе. становится бесполезным.
Также ORM'ы плохо работают там, где надо работать с группами сущностей (особенно большими), а не отдельнми объектами. Опять же, БД с большими таблицами работают замечательно.
Вы можете придумывать какие угодно прослойки и абстракции, но физически данные в любой БД хранятся в таблицах с индексами (а те — в файлах или в памяти). И все попытки их как-то по-другому представить будут вести к низкой эффективности операций с ними.
«Потому, что способ доступа к данным, предлагаемый ORM, нельзя оптимально реализовать с существующими реляционными БД по крайней мере. „
Аргументируйте.
“Потому что ORM как бы представляет базу в виде набора объектов, которыми она *не является*.»
Это верно для любого DAL, будь он ORM или не-ORM. Этот маппинг все равно есть.
«Оптимальный способ доступа к БД — выборка всех интересующих данных хорошим запросом с индесом и их разбор — и нормально составить такой запрос ORM принципиально не способен, хотя бы потому, что не знает, какие данные понядобятся в будущем.»
Почему же не знает? Вполне знает, если ORM написан хорошо и используется хорошо.
«Кроме того, уровень многих программистов низок, и в ходе написания ORM они еще ухудшают ситуацию, делаю «прослойку» еще более неэфффективной и требовательной к ресурсам.»
Это верно и для чистой RDBMS.
«Также ORM'ы плохо работают там, где надо работать с группами сущностей (особенно большими), а не отдельнми объектами.»
Почему? Аргументируйте.
«Опять же, БД с большими таблицами работают замечательно.»
На стороне клиента-то? И давно вы читали на клиентской стороне рекордсет записей так в миллион?
«И все попытки их как-то по-другому представить будут вести к низкой эффективности операций с ними. „
Вы забываете о том, что они уже “как-то иначе» представлены. Маппинг так или иначе существует, пусть он и идет на объект типа датасет. Единственный способ работать с данными без преобразований — это прямо в базе.
Аргументируйте.
“Потому что ORM как бы представляет базу в виде набора объектов, которыми она *не является*.»
Это верно для любого DAL, будь он ORM или не-ORM. Этот маппинг все равно есть.
«Оптимальный способ доступа к БД — выборка всех интересующих данных хорошим запросом с индесом и их разбор — и нормально составить такой запрос ORM принципиально не способен, хотя бы потому, что не знает, какие данные понядобятся в будущем.»
Почему же не знает? Вполне знает, если ORM написан хорошо и используется хорошо.
«Кроме того, уровень многих программистов низок, и в ходе написания ORM они еще ухудшают ситуацию, делаю «прослойку» еще более неэфффективной и требовательной к ресурсам.»
Это верно и для чистой RDBMS.
«Также ORM'ы плохо работают там, где надо работать с группами сущностей (особенно большими), а не отдельнми объектами.»
Почему? Аргументируйте.
«Опять же, БД с большими таблицами работают замечательно.»
На стороне клиента-то? И давно вы читали на клиентской стороне рекордсет записей так в миллион?
«И все попытки их как-то по-другому представить будут вести к низкой эффективности операций с ними. „
Вы забываете о том, что они уже “как-то иначе» представлены. Маппинг так или иначе существует, пусть он и идет на объект типа датасет. Единственный способ работать с данными без преобразований — это прямо в базе.
> «Потому, что способ доступа к данным, предлагаемый 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 мы даже не знаем, в сколько запросов (и будут ли они например использовать индексы) выльется та или иная операция.
> Аргументируйте.
> Почему же не знает? Вполне знает, если 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 мы даже не знаем, в сколько запросов (и будут ли они например использовать индексы) выльется та или иная операция.
«Потому что, не знает, что программист захочет сделать»
Ну так программисту достаточно это сказать.
"$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 так же, как с любыми другими данными, точно так же, как нельзя работать с данными из веб-сервиса так же, как с любыми другими. Точно так же, как надо учитывать особенности работы рекордсетов и курсоров при работе с ними. В момент, когда программист это понимает, работа становится прозрачной.
Ну так программисту достаточно это сказать.
"$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 так же, как с любыми другими данными, точно так же, как нельзя работать с данными из веб-сервиса так же, как с любыми другими. Точно так же, как надо учитывать особенности работы рекордсетов и курсоров при работе с ними. В момент, когда программист это понимает, работа становится прозрачной.
> Берем и правим:
> Posts::findTopPosts().With($post->title).With($post->author.With($author->name))
… и получаем тот же SQL только другими словами и с большой тяжелой библиотекой для его разбора.
> Во-вторых, я уже давно и спокойно пишу Context.Albums.Where(album => album.Photos.Count() > 10), и у меня все работает. Никакой кучи объектов — и полная проверка валидности обращения в компайл-тайм, если в альбоме нет коллекции фотографий, то и выражение не скомпилируется.
Гм, интересная конечно штука, но ведь все равно за ней скрывается множество классов (читай, дублирующих SQL) и в рантайме из них составляется (не мгновенно) запрос, только ради проверки типов?? Плюс, оно доступно только в проприетарном и тяжелом .NET. А как же Ява например? Там вроде этого нет, что делать? Я уж не говорю про PHP :)
> Никакой кучи объектов — и полная проверка валидности обращения в компайл-тайм, если в альбоме нет коллекции фотографий, то и выражение не скомпилируется.
Ну у нас в PHP нестрогая типизация. Компилируется практически все, что угодно :)
> Posts::findTopPosts().With($post->title).With($post->author.With($author->name))
… и получаем тот же SQL только другими словами и с большой тяжелой библиотекой для его разбора.
> Во-вторых, я уже давно и спокойно пишу Context.Albums.Where(album => album.Photos.Count() > 10), и у меня все работает. Никакой кучи объектов — и полная проверка валидности обращения в компайл-тайм, если в альбоме нет коллекции фотографий, то и выражение не скомпилируется.
Гм, интересная конечно штука, но ведь все равно за ней скрывается множество классов (читай, дублирующих SQL) и в рантайме из них составляется (не мгновенно) запрос, только ради проверки типов?? Плюс, оно доступно только в проприетарном и тяжелом .NET. А как же Ява например? Там вроде этого нет, что делать? Я уж не говорю про PHP :)
> Никакой кучи объектов — и полная проверка валидности обращения в компайл-тайм, если в альбоме нет коллекции фотографий, то и выражение не скомпилируется.
Ну у нас в PHP нестрогая типизация. Компилируется практически все, что угодно :)
"… и получаем тот же SQL только другими словами"
Не тот же, а типизованный на языке выполнения. Что круто.
«только ради проверки типов?»
Вы не поверите, сколько ошибок экономит это «только». Не говоря уже о том, что не только типов, но и свойст, собственно объектов и так далее. Это как перейти от языка с динамической типизацией к языку со статической — сразу количество ошибок кода уменьшается в разы. Это сильно перевешивает те доли процента производительности, которые нужны на пробег дерева выражений.
«оно доступно только в проприетарном и тяжелом .NET»
Это эти конкретные лямбды доступны только в .net (оставим эпитеты на вашей совести). А другие языки используют другие методы привязки. Всего-то. К ORM как парадигме это отношения не имеет.
«у нас в PHP нестрогая типизация. Компилируется практически все, что угодно»
Сочувствую. Неудивительно, что вам в PHP выгоды ORM неочевидны.
Не тот же, а типизованный на языке выполнения. Что круто.
«только ради проверки типов?»
Вы не поверите, сколько ошибок экономит это «только». Не говоря уже о том, что не только типов, но и свойст, собственно объектов и так далее. Это как перейти от языка с динамической типизацией к языку со статической — сразу количество ошибок кода уменьшается в разы. Это сильно перевешивает те доли процента производительности, которые нужны на пробег дерева выражений.
«оно доступно только в проприетарном и тяжелом .NET»
Это эти конкретные лямбды доступны только в .net (оставим эпитеты на вашей совести). А другие языки используют другие методы привязки. Всего-то. К ORM как парадигме это отношения не имеет.
«у нас в PHP нестрогая типизация. Компилируется практически все, что угодно»
Сочувствую. Неудивительно, что вам в PHP выгоды ORM неочевидны.
раскидывать по всему коду INSERT'ы и SELECT'ы— злее вот этого только Сатана.
генерит запросы чуть ли не 5-6 уровней вложенности и кучу временых таблиц.
Это ведь не проблема самого принципа ORM?
По поводу распространения ПО на ООБД, его не так уж и мало, дело в том что большинство такого ПО создается например для гос.нужд (Служба занятости, Пенсионный фонд), в банках. ну в общем в сферах не самых распространенных. И там где была доказана их эффективность
сам я работаю с субд Intersystems Cache, и принимал участие в нескольких разных разработках
преимущества ообд перед реляционными, есть хотя бы в том, что имея в наличии только субд, без сторонних разработок, можно написать готовое приложение с использованием только языка оосубд
а также наличие объектного доступа, добавляет кучу преимуществ, по манипуляции с данными
сам я работаю с субд Intersystems Cache, и принимал участие в нескольких разных разработках
преимущества ообд перед реляционными, есть хотя бы в том, что имея в наличии только субд, без сторонних разработок, можно написать готовое приложение с использованием только языка оосубд
а также наличие объектного доступа, добавляет кучу преимуществ, по манипуляции с данными
У нас в России до сих пор хватает решений, где бизнес-логика реализована в виде хранимых процедур (в основном используют Oracle). Но я не считаю это преимуществом реляционных БД и вам не рекомендую считать преимуществом ООБД. Спорный это момент. Обычно — в производительности выигрываешь, в скорости разработки проигрываешь.
А не поделитесь ли здесь опытом использования, какой-нибудь «нутрянкой»? Например, за счет чего они декларируют себя быстрее SQL? Тема интересует.
декларируют себя быстрее SQL, в основном на основе сравнительных тестов
дело в том еще как сравнивать Cache и реляционные БД, в ней используется несколько способов доступа к данным
к примеру в Cache, если нужно получить данные по которым построен индекс, обойти эти данные можно используя SQL, либо обратившись напрямую к данным где хранится индекс и самому программно пройтись по нему, если случаи когда это оправдано.
дело в том еще как сравнивать Cache и реляционные БД, в ней используется несколько способов доступа к данным
к примеру в Cache, если нужно получить данные по которым построен индекс, обойти эти данные можно используя SQL, либо обратившись напрямую к данным где хранится индекс и самому программно пройтись по нему, если случаи когда это оправдано.
занятно.
Я за то, чтобы не перемешивать контроллер с моделью. В то же время считаю реляционную концепцию гениальной. В любых сущностях абстракции никогда не претендовали на замену собой низкого уровня.
1. Делая запрос в релационных рбд каждый раз приходится полностью или частично указывать модель данных (пересечение таблиц, импортируемые ключи), а это не есть хорошо. В ообд модель данных определяется один раз и используется автоматически при запросах.
2. Рбд не поддерживают наследование в полной мере.
3. Попытка реализовать иерархическую модель в рбд также упирается в сложности, особенно если модель с нечеткой структурой.
4. Для ОРМ можно легко и прозрачно использовать кэш-прослойку между бизнес леером и datastore (JBoss Cache, Oracle Coherence). Как показывают тесты, производительность в таком случае увеличивается в разы.
5. ОРМ-объекты могут предоставлять бизнес приложению более гибкие средства доступа к данным, например можно мепить значения полей в свои типы. Тогда как набор типов в SQL очень ограничен (например далеко не все поддерживают тип поля Array).
6. Реальная переносимость у SQL никакая. Приложение, написанное для Oracle, 100% не будет работать на MSSQL. Тогда как для ORM нужно поменять всего лишь пару строчек.
7. И последнее. Даже если использовать голый SQL, на каком-то этапе приложения все-равно придется меппинг полей в бизнес-объекты (напр. для представления или для отдачи вебсервису). Так или иначе придется организовывать свой уровень DAO. И ORM здесь возьмет на себя всю рутинную часть задачи.
2. Рбд не поддерживают наследование в полной мере.
3. Попытка реализовать иерархическую модель в рбд также упирается в сложности, особенно если модель с нечеткой структурой.
4. Для ОРМ можно легко и прозрачно использовать кэш-прослойку между бизнес леером и datastore (JBoss Cache, Oracle Coherence). Как показывают тесты, производительность в таком случае увеличивается в разы.
5. ОРМ-объекты могут предоставлять бизнес приложению более гибкие средства доступа к данным, например можно мепить значения полей в свои типы. Тогда как набор типов в SQL очень ограничен (например далеко не все поддерживают тип поля Array).
6. Реальная переносимость у SQL никакая. Приложение, написанное для Oracle, 100% не будет работать на MSSQL. Тогда как для ORM нужно поменять всего лишь пару строчек.
7. И последнее. Даже если использовать голый SQL, на каком-то этапе приложения все-равно придется меппинг полей в бизнес-объекты (напр. для представления или для отдачи вебсервису). Так или иначе придется организовывать свой уровень DAO. И ORM здесь возьмет на себя всю рутинную часть задачи.
боже, как все всё всегда усложняют
«select name, value from MyTable where id = ?»
скажите, этот запрос разве непереносим?
зачем писать то, что не переносимо?
«select name, value from MyTable where id = ?»
скажите, этот запрос разве непереносим?
зачем писать то, что не переносимо?
А вы попробуйте написать переносимый запрос, эффективно работающий с иерархическими данными. Или с блобами. Или с полнотекстовым поиском.
Сразу становится понятно, зачем писать то, что непереносимо.
Сразу становится понятно, зачем писать то, что непереносимо.
1. в приведенном выше запросе ничто не мешает полям name или value быть типа blob
2. о каких эффективных запросах вы говорите? select? можно, например для oracle, написать что-то типа «select oracle_super_performance_magic_key name, value as blob from MyTable where id = ?» и такой запрос в oracle вытянет blob с потрясающей быстротой?
3. как вы работаете с иерархическими данными? вытягиваете всю иерархию сразу? если нет, то какая разница: иерархия это или нет? вытянул объект и забыл. надо у него потомков — вытянул и их: опять-таки одним простым запросом.
2. о каких эффективных запросах вы говорите? select? можно, например для oracle, написать что-то типа «select oracle_super_performance_magic_key name, value as blob from MyTable where id = ?» и такой запрос в oracle вытянет blob с потрясающей быстротой?
3. как вы работаете с иерархическими данными? вытягиваете всю иерархию сразу? если нет, то какая разница: иерархия это или нет? вытянул объект и забыл. надо у него потомков — вытянул и их: опять-таки одним простым запросом.
«о каких эффективных запросах вы говорите? select? можно, например для oracle, написать что-то типа «select oracle_super_performance_magic_key name, value as blob from MyTable where id = ?» и такой запрос в oracle вытянет blob с потрясающей быстротой?»
А вот нет. Я хочу читать данные секторами (и писать секторами). И вот сделать это переносимо — нельзя. Поэтому и выше в запросе name и value могут быть блобом, только нафиг мне нужен двухгиговый блоб в памяти?
«если нет, то какая разница: иерархия это или нет?»
Большая. Напишите мне один простой запрос, возвращающий всех предков заданной точки дерева. Удалось? Теперь напишите такой же простой запрос, который вставит узел в это дерево в произвольную точку.
А вот нет. Я хочу читать данные секторами (и писать секторами). И вот сделать это переносимо — нельзя. Поэтому и выше в запросе name и value могут быть блобом, только нафиг мне нужен двухгиговый блоб в памяти?
«если нет, то какая разница: иерархия это или нет?»
Большая. Напишите мне один простой запрос, возвращающий всех предков заданной точки дерева. Удалось? Теперь напишите такой же простой запрос, который вставит узел в это дерево в произвольную точку.
ну два запроса… сначала вставить узел, а потом обновить указатели на родителя у узлов-потомков, чтобы они ссылались на новый узел
кроме того, я не понимаю зачем в базе данных хранить объекты размеров в 2 гб. в таком случае я храню их в файлах, а в базе делаю ссылку на файл. чем это хуже?
кроме того, я не понимаю зачем в базе данных хранить объекты размеров в 2 гб. в таком случае я храню их в файлах, а в базе делаю ссылку на файл. чем это хуже?
«ну два запроса… сначала вставить узел, а потом обновить указатели на родителя у узлов-потомков, чтобы они ссылались на новый узел»
Схема с pattern id? Таки покажите мне запрос, которым вы выберете всех предков одного узла. Вверх до корня. Одним запросом.
«кроме того, я не понимаю зачем в базе данных хранить объекты размеров в 2 гб. в таком случае я храню их в файлах, а в базе делаю ссылку на файл. чем это хуже?»
Потерей целостности, например. Проблемами с блокировками. Проблемами при разнесении на фермы. Да мало ли чем еще.
Схема с pattern id? Таки покажите мне запрос, которым вы выберете всех предков одного узла. Вверх до корня. Одним запросом.
«кроме того, я не понимаю зачем в базе данных хранить объекты размеров в 2 гб. в таком случае я храню их в файлах, а в базе делаю ссылку на файл. чем это хуже?»
Потерей целостности, например. Проблемами с блокировками. Проблемами при разнесении на фермы. Да мало ли чем еще.
> Большая. Напишите мне один простой запрос, возвращающий всех предков заданной точки дерева.
Nested Trees? Materialized Path? там вроде 1 запросом это делается.
А вообще, вы так говорите, как будто только от наличия ООБД эти проблемы с хранением иерархических данных сами собой решатся. Все равно данные физически где-то хранятся, и для эффективной работы с ними нужны всякие хитрости, и реляционные БД дают нам возможность их применять (за счет более низкоуровневого доступа к данным), а ООБД просто будут их прятать. Не факт, что оптимальным образом.
Nested Trees? Materialized Path? там вроде 1 запросом это делается.
А вообще, вы так говорите, как будто только от наличия ООБД эти проблемы с хранением иерархических данных сами собой решатся. Все равно данные физически где-то хранятся, и для эффективной работы с ними нужны всякие хитрости, и реляционные БД дают нам возможность их применять (за счет более низкоуровневого доступа к данным), а ООБД просто будут их прятать. Не факт, что оптимальным образом.
Я же специально сказал — и один запрос на вставку узла (если удалось — на перемещение). Там, где можно сделать выборку одним запросом, нельзя сделать вставку одним запросом. Там, где можно сделать вставку, нельзя выборку. Плавали.
«А вообще, вы так говорите, как будто только от наличия ООБД эти проблемы с хранением иерархических данных сами собой решатся.»
Вы немного потеряли тему. Речь шла исключительно о том, зачем писать непереносимые запросы. ООБД тут уже не при чем.
«А вообще, вы так говорите, как будто только от наличия ООБД эти проблемы с хранением иерархических данных сами собой решатся.»
Вы немного потеряли тему. Речь шла исключительно о том, зачем писать непереносимые запросы. ООБД тут уже не при чем.
> Речь шла исключительно о том, зачем писать непереносимые запросы.
Ок, я вас понял. Разве что замечу, что ORM — плохой способ решения проблемы абстракции от особенностей БД в силу неэффективности своей реализации и изначально неудачной концепции (представление всех данных в виде набора объекта, при том что физически данные лежат в таблицах где-то на диске).
Ок, я вас понял. Разве что замечу, что ORM — плохой способ решения проблемы абстракции от особенностей БД в силу неэффективности своей реализации и изначально неудачной концепции (представление всех данных в виде набора объекта, при том что физически данные лежат в таблицах где-то на диске).
> 2. Рбд не поддерживают наследование в полной мере.
А по-моему очень даже поддерживает. Я использую даже множественное наследование и всю логику пишу руками (пока, уже пишу собственный генератор) на T-SQL ввиде хранимок, функций и вьюх. Пример (sql-скрипт): webfile.ru/4486966
А по-моему очень даже поддерживает. Я использую даже множественное наследование и всю логику пишу руками (пока, уже пишу собственный генератор) на T-SQL ввиде хранимок, функций и вьюх. Пример (sql-скрипт): webfile.ru/4486966
Это не совсем наследование, это что-то вроде «костыля» для наследования, а тем более для множественного. На практике у Вас выходит что у Персоны и у Партнера должны быть одинаковые ИДы, а если Вы уже занесли в базу человека (допустим с ИД = 5), потом занесли в базу несколько Партнеров (с ИДами 5,6,7), а потом пытаетесь устроить того человека на работу, то у Вас возникнет косяк с органичениями на ключи, потому что ФК идет от одного поля к двум таблицам. У Вас получилась неявная, нигде в СУБД не контролируемая связь таблиц Персона — Партнер. Это черевато большими проблемами в будущем.
в чем проблемы с доступом к объектам, если есть orm наподобие hibernate?
кроме того, излишняя нормализация вредна в большинстве случаев и приводит с десяткам бесполезных раздробленных таблиц для каждого чиха
кроме того, излишняя нормализация вредна в большинстве случаев и приводит с десяткам бесполезных раздробленных таблиц для каждого чиха
Быть может какое-то странное мнение о ООБД, но мне кажется, что эта идея умрёт быстрее, чем появится нормальная теория. Пик ООП, как идеи, уже прошёл (понятно что как технология он используется повсеместно), новых идей уже не видно, кучи проблем очевидны (сколько книг написано о патернах использования, очень напоминает рекомендации в стиле, goto используйте только вот так, в до структурную эпоху). Сейчас всё больший оборот набирает функциональщина, и, быть может, когда-нибудь через 10-ок другой лет она станет мэйнстримом.
достаточно интересных стаей? =) начало топика
ORM — гадость (по крайней мере сделанные на PHP), тяжелые, содранные с Ява-аналогов и неповоротливые. В чем смысл хранимых процедур тоже кстати особо не понимаю.
Ну а насчет ООБД — не знаю, мне кажется традиционные системы вроде MySQL не первый год существуют, хорошо изучены и всяко лучше.
Ну а насчет ООБД — не знаю, мне кажется традиционные системы вроде MySQL не первый год существуют, хорошо изучены и всяко лучше.
Если учесть, что в мускуле до 5-й версии ХП и в помине не было, а в пятой их писать было большим гемороем, то неудивительно что не понимаете в чем их смысл. Я бы Вам посоветовал почитать про T-SQL или PL\SQL и оптимизатор запросов в них, как строятся планы запросов для ХП и для прямых запросов, как оптимизатор использует таблицы индексов — тогда поймете для чего нужны ХП.
> В чем смысл хранимых процедур тоже кстати особо не понимаю.
Не думаю что здесь есть чем похвастаться, возможно это у Вас ещё впереди. Лично я только с опытом (которого, признаюсь, мне всё ещё недостаёт, но я активно работаю над этим), на практике, я начал понимать смысл не только хранимых процедур, но и вьюшек и функуий и триггеров. Сейчас мне очень нехватает возможности использовать исключения в функциях на T-SQL, в то время как когда я впервые познакомился с исключениями 8 лет назад в С++, я не понимал зачем городить лишние сущности когда можно просто возвратить -1.
Не думаю что здесь есть чем похвастаться, возможно это у Вас ещё впереди. Лично я только с опытом (которого, признаюсь, мне всё ещё недостаёт, но я активно работаю над этим), на практике, я начал понимать смысл не только хранимых процедур, но и вьюшек и функуий и триггеров. Сейчас мне очень нехватает возможности использовать исключения в функциях на T-SQL, в то время как когда я впервые познакомился с исключениями 8 лет назад в С++, я не понимал зачем городить лишние сущности когда можно просто возвратить -1.
> Лично я только с опытом (которого, признаюсь, мне всё ещё недостаёт, но я активно работаю над этим), на практике, я начал понимать смысл не только хранимых процедур, но и вьюшек и функуий и триггеров.
Касательно процедур и триггеров, просто у меня есть мнение, что какую-то логику проще закладывать в код приложения, где мы можем пользвоаться всеми возможностями языка, отладкой, ООП и прочими радостями (плюс SVN :) ), а не в примитивный SQL, не находите?
Касательно процедур и триггеров, просто у меня есть мнение, что какую-то логику проще закладывать в код приложения, где мы можем пользвоаться всеми возможностями языка, отладкой, ООП и прочими радостями (плюс SVN :) ), а не в примитивный SQL, не находите?
согласен с вами полностью.
хранимки — это прошлый век, от которого пахнет большими скучными корпорациями.
особенно считаю бессмысленным писать автогенераторы хранимок, использовать всякие вьюшки и пр. мутотень.
полезно иногда следовать принципу kiss — keep it simple, stupid
хранимки — это прошлый век, от которого пахнет большими скучными корпорациями.
особенно считаю бессмысленным писать автогенераторы хранимок, использовать всякие вьюшки и пр. мутотень.
полезно иногда следовать принципу kiss — keep it simple, stupid
А никто и не говорит при написании ХП о закладывании логики в SQL — ХП для выборки данных это не логика, а они ускоряют работу существенно (почитайте все же про оптимизатор запросов).
где Вы нашли примитивный SQL? В MySQL когда-то он и был примитивным, но уж поверьте мне T-SQL и уж тем более PL\SQL далеко не примиитивные языки (если сомневаетесь — почитайте доки на эту тему).
К тому же, как вы собираетесь использовать все возможности языка для построения объединений таблиц? SQL это сделает гораздо быстрее, будет использовать индексы и ключи.
Причем тут SVN я вообще не понял.
примитивный SQL, не находите?
где Вы нашли примитивный SQL? В MySQL когда-то он и был примитивным, но уж поверьте мне T-SQL и уж тем более PL\SQL далеко не примиитивные языки (если сомневаетесь — почитайте доки на эту тему).
К тому же, как вы собираетесь использовать все возможности языка для построения объединений таблиц? SQL это сделает гораздо быстрее, будет использовать индексы и ключи.
Причем тут SVN я вообще не понял.
> А никто и не говорит при написании ХП о закладывании логики в SQL — ХП для выборки данных это не логика, а они ускоряют работу существенно (почитайте все же про оптимизатор запросов).
По моему есть только один способ оптимизации запросов на выборку — выбирать по индексу. Если требуется fullscan — БД все равно придется проходить по всем записям, хоть вызывай запрос с клиента, хоть из ХП.
> где Вы нашли примитивный SQL?
Ну допустим я его в совершенстве не знаю, но примеры, которые есть в википедии, напоминают скорее порядком устаревший бейсик, чем современные языки с ООП, примесями, замыканиями и прочими хитростями. Хотя наверно оно в БД и не требуется.
> К тому же, как вы собираетесь использовать все возможности языка для построения объединений таблиц? SQL это сделает гораздо быстрее, будет использовать индексы и ключи.
Я отрицательно отношусь к идее объединения таблиц, по моему оно тормозит и сложно оптимизируется, особенно если этих таблиц много.
По моему есть только один способ оптимизации запросов на выборку — выбирать по индексу. Если требуется fullscan — БД все равно придется проходить по всем записям, хоть вызывай запрос с клиента, хоть из ХП.
> где Вы нашли примитивный SQL?
Ну допустим я его в совершенстве не знаю, но примеры, которые есть в википедии, напоминают скорее порядком устаревший бейсик, чем современные языки с ООП, примесями, замыканиями и прочими хитростями. Хотя наверно оно в БД и не требуется.
> К тому же, как вы собираетесь использовать все возможности языка для построения объединений таблиц? SQL это сделает гораздо быстрее, будет использовать индексы и ключи.
Я отрицательно отношусь к идее объединения таблиц, по моему оно тормозит и сложно оптимизируется, особенно если этих таблиц много.
поддерживаю, чувак! объединение таблиц — зло! я серьезно. все эти left join-ы до добра не доведут…
Правильно! все данные надо хранить вообще в денормализованной таблице Excel, чтобы в любой момент можно было открыть без написания всяких запросов на примитивном SQL.
А вы в курсе, что для серьезных систем это обязательное требование, дублировать всю информацию в plain-text? На случай, если СУБД внезапно наебнется или ключевой человек (который все знает и умеет) изчезнет, и не будет возможности оперативно вытаскивать ценные данные из бесформенной груды байтов.
На случай если СУБД наебнется делаются бекапы, миррор-сервера, рейд-массивы (если еще и за железо боитесь.
Если ключевой человек (который все знает и умеет) один на весь проект, то это несерьезная система. А если к тому же нет нормальной документации, то это 200% не серьезная система.
Если ключевой человек (который все знает и умеет) один на весь проект, то это несерьезная система. А если к тому же нет нормальной документации, то это 200% не серьезная система.
Поясняю подробнее. Вот есть, к примеру, база данных, в которой хранятся всякие сведения по нефтяным скважинам — там сотни разных параметров. И хранятся они не один год. А лет через 20 вдруг понадобилось эти данные куда-то перегнать, а их хрен вытащишь — в прикладном софте это не предусмотрено, да и сам софт уже нерабочий, автор изчез, прога заблокирована, админских логинов-паролей никто не знает. Зато все бекапы, рейд-массивы и кластеры в полном порядке. И документация к ним есть, но только это не описание структуры файлов хранилища и структуры метаданных приложения, а простое руководство пользователя.
Скажу проще, у меня торговая первичка (порядка 30 000 документов в день) в CSV дублируется, а ее потом можно и Экзель пихать, и вообще куда угодно. Понадобились мне данные за 2001 год, когда еще в лохматом Парусе работали — я эту базу парусную и не смогу открыть, она на Netware. А так — у меня есть текстовый реестр клиентов, реестры документов, которые можно обычным блокнотом открыть и поиском найти нужного клиента, и если его там немного, что ручками скопипастить в экзель. А если много, то скорость обработки текстового файла ~= скорости чтения с диска.
Скажу проще, у меня торговая первичка (порядка 30 000 документов в день) в CSV дублируется, а ее потом можно и Экзель пихать, и вообще куда угодно. Понадобились мне данные за 2001 год, когда еще в лохматом Парусе работали — я эту базу парусную и не смогу открыть, она на Netware. А так — у меня есть текстовый реестр клиентов, реестры документов, которые можно обычным блокнотом открыть и поиском найти нужного клиента, и если его там немного, что ручками скопипастить в экзель. А если много, то скорость обработки текстового файла ~= скорости чтения с диска.
По моему есть только один способ оптимизации запросов на выборку — выбирать по индексу.Вы ошибаетесь — почитайте про оптимизатор запросов в таких СУБД как MS SQL или Oracle.
Ну допустим я его в совершенстве не знаю, но примеры, которые есть в википедииПознакомтесь не только с примерами в википедии, а лучше поработайте с ним года два-три и тогда поймете всю его мощь.
Я отрицательно отношусь к идее объединения таблиц, по моему оно тормозит и сложно оптимизируется,А структуру данных вы не нормализуете? Или нормализация — это лишняя трата времени на проектирование?
Во-первых я не нахожу SQL (по крайней-мере T-SQL) примитивным, я нахожу его восхитительным, хотя там и есть что расширить (например те же исключения). Часто на SQL можно записаит задачу гораздо короче и красивее чем на обычном алгоритмическом языке. По моему мнению пренебрежение использования domain-specific языками и стремления описать всё, к примеру, на C++ или PHP — распространённая ошибка.
Кроме того не вижу причин не хранить SQL-скрипты в SVN вместе с остальным кодом. Всегда так делали. Все SQL-файлы (создающие структуру базы с нуля, заполняющие базу тестовыми данными, создающие (а перед директивой создания идёт директива удаления если она уже есть) процедуры и т.п. включаются в проект в Visual Studio или NetBeans на оавне с другими файлами и версионируются как и все остальные).
Кроме того не вижу причин не хранить SQL-скрипты в SVN вместе с остальным кодом. Всегда так делали. Все SQL-файлы (создающие структуру базы с нуля, заполняющие базу тестовыми данными, создающие (а перед директивой создания идёт директива удаления если она уже есть) процедуры и т.п. включаются в проект в Visual Studio или NetBeans на оавне с другими файлами и версионируются как и все остальные).
По поводу языка для процедур и триггеров. Допустим, мы решили все таки часть логики перенести в БД, там при добавлении комментария увеличиваетя значение поля, и т.д. Допустим, у нас есть поле content, которое содержит текст комментария с BB-code. При любом обновлении этого поля в content_html надо записать этот же текст в HTML формате. Вот тут то хранимые процедуры и оказываются бесполезными. Это к фразе «Часто на SQL можно записаит задачу гораздо короче и красивее чем на обычном алгоритмическом языке»
Бейсикоподобный язык уровня 80-х годов (SET @VAR = 10) я никак красивым назвать не могу, уж извините.
Ну и не очень понимаю, какая польза от процедур при выборках, если индексированные запросы они не ускорят, а запросы без индексов лучше вообще не делать.
Бейсикоподобный язык уровня 80-х годов (SET @VAR = 10) я никак красивым назвать не могу, уж извините.
Ну и не очень понимаю, какая польза от процедур при выборках, если индексированные запросы они не ускорят, а запросы без индексов лучше вообще не делать.
> при добавлении комментария увеличиваетя значение поля, и т.д. Допустим, у нас есть поле 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, теперь некоторые циклы конвертируются в одну строчку.
Извините, не понял.
> Вот тут то хранимые процедуры и оказываются бесполезными. Это к фразе «Часто на SQL можно записаит задачу гораздо короче и красивее чем на обычном алгоритмическом языке»
Даже если вы привели пример (которого я, в прочем, не понял и прошу пояснить) задачи, которую рациональнее решить на C# или PHP чем на SQL, это не опровергает того, что всё ещё есть множество задачь, которые рациональнее решить на SQL.
> Бейсикоподобный язык уровня 80-х годов (SET @VAR = 10) я никак красивым назвать не могу, уж извините.
Я не говорю о словаре языка. Я говорю о концепции его интерпретации. SQL — декларативный язык, который ближе по своей сути, на сколько я понимаю, к Prolog и Lisp чем к C, PHP, Pascal или BASIC. Это совершенно разные вещи, требующие иного порядка мышления.
Когда я был совсем новичком и меня посадили писать одну хранимку, я начал городить в ней цикл на курсорах, потому, что я привыкмыслить в терминах алглоитмисеских языков таких как Basic и C++. Моё решение работало. Но та же задача гораздо быстрее решалась одним SELECT-ом в несколько строк. Это как последоватльно сложить n раз или одномоментно умножить на n.
Не зря в C# добавили Linq, теперь некоторые циклы конвертируются в одну строчку.
Ну и не очень понимаю, какая польза от процедур при выборках, если индексированные запросы они не ускорят, а запросы без индексов лучше вообще не делать.Запрос, вызванный из языка и запрос, сохраненный в виде ХП это разные вещи по быстродействию, потому для любого запроса составляется план выполнения (если в двух словах — последовательность обхода индексов, таблиц и условий) — на составление этого плана тратится время. Но вот при «компиляции» ХП этот план составляется один раз и сохраняется в базе вместе с ХП, а при вызове запроса он строится каждый раз.
Запросы без индексов приходится делать по двадцать раз на дню, потому что существует много критериев фильтров и для всех полей бессмысленно делать индексы.
Еще раз повторюсь — чтобы не выглядеть, мягко говоря, дилетантом, потрудитесь почитать базовые вещи, а еще лучше потрудитесь из пощупать своими руками, чтобы понять что к чему.
А я самописные ОРМы использую и не жужжу… У меня их даже две — статическая и динамическая.
Статическая с нативными объектами языка, для больших объемов, — читает и пишет сразу целыми таблицами, относительно сложная но быстрая. По сути — классический ОРМ, когда у объекта/коллекции есть методы для записи в / чтения из БД.
Динамическая — объекты могут создаваться «на лету» с любым набором полей. Значения полей в виде ассоциативного массива. Удобно, но много накладных расходов. Идеально для хранения настроек, построения сложных конфигов.
Статическая с нативными объектами языка, для больших объемов, — читает и пишет сразу целыми таблицами, относительно сложная но быстрая. По сути — классический ОРМ, когда у объекта/коллекции есть методы для записи в / чтения из БД.
Динамическая — объекты могут создаваться «на лету» с любым набором полей. Значения полей в виде ассоциативного массива. Удобно, но много накладных расходов. Идеально для хранения настроек, построения сложных конфигов.
а как кешируете?
Это от задачи зависит. В статическом варианте кеширование не требуется, там данные и так в памяти сидят после первого обращения к объекту. В динамическом элементы самоубиваемые (со счетчиком ссылок). Если он вдруг заново понадобится, то проще его заново родить и из базы прочитать. А для кеширования можно завести глобальный список (вектор) созданных объектов, в котором они будут хранится, пока их оттуда не «вытеснят».
>> И только спустя некоторое время, когда база наполнится реальными данными, пройдет пару месяцев, заказчик (да и разработчик тоже) с удивлением обнаруживает, что время выборок увеличилась почти вдвое, при работе 10-20 пользователей одновременно СУБД пытается покончить жизнь самоубийством и т.д. и т.п.
А и не нужно заниматься преждевременной оптимизацией. Не факт, что через пару месяцев будет именно так. А если будет — дешевле докупить еще одну железку, чем писать ручками sql.
А и не нужно заниматься преждевременной оптимизацией. Не факт, что через пару месяцев будет именно так. А если будет — дешевле докупить еще одну железку, чем писать ручками sql.
Какую железку Вы собираетесь покупать, если за месяц объем одной таблицы вырастает до 60-90млн заисей? Здесь покупка железяки не поможет никак.
Поднять еще один сервер и расшардить таблицу между ними. Современные scallability-технологии в реляционных БД рулят и педалят.
Конечно, если все в таком виде, как Вы описали (10-20 пользователей вешают СУБД) то тут да, действительно проще застрелить программиста и пересесть на ООБД.
Но обычно, расходы на программиста, который строит 15-этажные SQL-запросы ручками, вместо того, чтобы доверить это нормальной ORM превышают расходы на новый сервак, при том же подъеме производительности (а в случае с дальнейшем расширением — не факт, что супероптимизированный костыль, сляпаный вручную окажется столь же масштабируемым, как средства ORM).
Конечно, если все в таком виде, как Вы описали (10-20 пользователей вешают СУБД) то тут да, действительно проще застрелить программиста и пересесть на ООБД.
Но обычно, расходы на программиста, который строит 15-этажные SQL-запросы ручками, вместо того, чтобы доверить это нормальной ORM превышают расходы на новый сервак, при том же подъеме производительности (а в случае с дальнейшем расширением — не факт, что супероптимизированный костыль, сляпаный вручную окажется столь же масштабируемым, как средства ORM).
Gemstone/S
Если память не изменяет, то была впервые выпущена в коммерческое использование как продукт в 1991. Представляла из себя симбиоз виртуальной машины и ООБД. Современен превратилась в то, что сейчас называют distributed storage (правда не совсем честный, но зато ACID).
Также можете поискать информацию про Objectivity
Этим я хотел сказать, что человек который заинтересуется вопросом всерьез — найдет информацию о том, что продукты давно разработаны.
Если память не изменяет, то была впервые выпущена в коммерческое использование как продукт в 1991. Представляла из себя симбиоз виртуальной машины и ООБД. Современен превратилась в то, что сейчас называют distributed storage (правда не совсем честный, но зато ACID).
Также можете поискать информацию про Objectivity
Этим я хотел сказать, что человек который заинтересуется вопросом всерьез — найдет информацию о том, что продукты давно разработаны.
Да, воды и впрямь многовато. Странно, почему не упомянута «тонкая» модель, в которой персистентные сущности не имеют поведения, а потому не нуждаются в сложной ORM и могут не противопоставлять РБД и ООБД
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реляционные БД vs Объектно-ориентированные БД