Каковы преимущества использования абстракции базы данных ORM? [закрыто]

Я начинаю использовать ORM, рекомендованный выбранной средой, и, хотя мне нравится идея добавления уровня абстракции, предоставляемого ORM, я начинаю понимать, что это на самом деле означает. Это означает, что я больше не работаю со своей базой данных (mysql), и все специфичные для mysql функции исчезли из окна, как будто их не существует.

Идея ORM состоит в том, что он пытается помочь мне, делая все, что не зависит от базы данных. Это звучит замечательно, но часто есть причина, по которой я выбираю конкретную систему баз данных. Но, следуя независимому от базы данных маршруту, ORM выбирает наименьший общий знаменатель, что означает, что я получаю наименьший набор функций (поддерживаемых всеми базами данных).

Что если я знаю, что в течение долгого времени я не буду переключать основную базу данных? Почему бы также не получить доступ к функциям базы данных?

Я вижу это так же. Любая абстракция, которая не позволяет вам оказаться под ней, когда это необходимо, является злом, потому что она приводит ко всем видам отвратительных инверсий абстракции в вашем коде.

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

IMO любой ORM, у которого нет этой функции, не стоит тех битов, из которых он скомпилирован.

ОРМ принимает наименьший общий знаменатель

Я должен не согласиться с вашим утверждением. Я возьму Hibernate в качестве примера. Эта структура поддерживает множество баз данных, включая самые популярные, независимо от версии (и поддерживаемых функций), как и большинство ORM.

Краткое примечание: вы упоминаете только абстракцию базы данных. Это одно из многих преимуществ, но я действительно считаю, что объектно-ориентированные функции более мощные (например, наследование). И You design your domain model first...

... Вернуться к абстракции. Это не самый низкий общий знаменатель. В nHibernate у вас есть диалекты. Это позволяет использовать один и тот же код для запроса разных баз данных. Диалекты позаботятся о функции управления для вас. Правильное утверждение таково a given dialect will try to use all the power of a given database system.

В качестве примера возьмем SqlServer2005диалект, который при внедрении использовал преимущества новых функций подкачки SQL Server 2005. Использование этого диалекта вместо того, чтобы SqlServer2000просто повысить ваши выступления.

Конечно, есть исключения, но я не встречал ни одного за многие годы работы с nHibernate, и мои приложения ориентированы на данные.

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

Итак, я думаю, что вопросы должны быть, прежде чем перейти к одному:

Вы действительно что-нибудь получаете от их использования? То есть, экономите ли вы достаточное количество усилий, внедряя инструмент ORM, чтобы сделать его достойным использования и сделать его более сложным для вашей системы? (это особенно верно для коммерческих приложений, где этот дополнительный «кусок» теперь является дополнительным вектором для потенциальных проблем поддержки)

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

O / RM регулярно подвергается критике. Тед Ньюард назвал это « Вьетнамом информатики » несколько лет назад. O / RM

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

Если вы просто не напишите свое собственное специальное отображение (которое во многих случаях является хорошим решением, как уже говорили другие), вы можете рассмотреть альтернативы, такие как использование нереляционной базы данных. Некоторые говорят, что действительно объектная база данных лучше, другие умные слова, упомянутые в этом контексте, это LINQ, Ruby и Tutorial D. Я полагаю, что в отличие от действительно реляционных баз данных, существуют действительно объектные базы данных. Но на практике я обнаружил, что концептуальное моделирование данных - то есть выяснение, о каких объектах реального мира вы хотите хранить данные и как эти объекты связаны друг с другом - важнее, чем выяснить, как выразить вашу концептуальную модель в любом язык программирования или базы данных.

Какая альтернатива?

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

В конце дня вы должны спросить себя - какая альтернатива?

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

ORM в основном равносильно « несохраненным процедурам ». Там я придумал термин.

Все, что делает ORM, вы можете воспроизвести с помощью представлений, триггеров и хранимых процедур. Они помогают абстрагироваться от необработанного SQL и поддерживать согласованность нормализованных баз данных. Но это работает только для простых случаев. Если данных для обработки слишком много, они могут привести к снижению производительности. (ORM в PHP часто принимают сторону сценария данных, потому что цепочки построителя SQL не могут абстрагировать все).

Но, как обычно, все зависит от приложения и поставленной задачи.

Одна вещь, которая вредит использованию ORM, заключается в том, что многие их поклонники утверждают, что нам больше не нужно знать теорию SQL и RDB. Результаты варьируются от забавных до совершенно катастрофических. И это несмотря на то, что миллионы раз ORM 'производят и утверждают, что мы должны хорошо знать теорию SQL и RDB, чтобы правильно использовать и настраивать ORM.

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

В прошлом году я работал над собственным приложением, которое часто менялось, и я был очень рад, что мы использовали ORM. Приложение было вспомогательным приложением для команды управления изменениями, и по мере развития более крупного проекта наше маленькое приложение предъявляло новые требования к ситуациям, которых не было и которые нельзя было предвидеть несколькими месяцами ранее.

Благодаря ORM ( Propel , в PHP) мы разделили некоторую логику кода, поэтому одна функция добавила часть запроса «is record valid», а другая часть безопасности («показывать эти записи только в том случае, если пользователь имеет эти возможности "), ... Если базовая структура изменилась (дополнительное поле, которое следует учитывать для" достоверности записи "), нам нужно было изменить только одну функцию, а не двадцать предложений SQL.

Мы пришли из ситуации, когда все (ну, большинство) предложений SQL были сохранены в отдельном XML-файле, поэтому «изменения базы данных будут легко обрабатывать». Поверьте мне, они не были. Одна часть была настолько ужасной, что мне пришлось представить ее в The Daily WTF .

Если запрос был слишком сложен для выражения с помощью Propel Criteria, или нам нужны были некоторые специфические для поставщика функции (в основном, полнотекстовый поиск, так как мы использовали MySQL), это не было проблемой для Propel. Вы можете добавить пользовательские критерии , или, когда это действительно необходимо, мы использовали сырой SQL ( теперь еще проще комбинировать с реальными объектами Propel). Вы можете легко добавить свои специфичные для поставщика надстройки в сгенерированные классы, чтобы у вас было лучшее из обоих миров: в коде приложения нет SQL, но есть все возможности вашего механизма базы данных.

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

Я сейчас работаю в C # и много использую LINQ, поэтому очень много беглых методов. Мне не нужно думать о том, как мои объекты хранятся или обнаруживаются, или даже сохраняются на уровне программы, и очень мало на уровне бизнес-уровня.

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

Вы все еще можете написать функции DB-стороне. Часто вы можете просто отобразить их.

И, прежде всего, такое разделение позволяет тестируемость и заставляет вас (немного) писать более структурированный код

ORM также могут предоставить вам доступ к определенным функциям базы данных, это зависит от того, какой ORM вы используете и какие функции он предоставляет.

Например, в текущем проекте, над которым я работаю, мы используем Java Persistence API и Hibernate. Тем не менее, мы используем несколько специфических функций базы данных, таких как поиск в таблицах с soundex.

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

Тем не менее , в какой-то момент вам, скорее всего, придется все равно подумать об этом, в зависимости от требований вашего приложения. ОРМ не волшебство.

Я написал свой собственный, который помогает мне легче делать выборки и вставки.

Evey db конкретная вещь доступна. Мне просто нужно написать запрос, с которым мне помогает библиотека (я могу использовать «?» И params вместо того, чтобы вручную называть параметр и использовать .Add)

Я думаю, моя половина сосет половину полезной. Я получаю некоторую помощь в мире ORM и занимаюсь значительными вопросами в мире запросов.

Написание кода для вставки и выбора, обновления встроенного или с сохраненными процессами и сопоставление их обратно через DAL является более длительной нормой, а в исключительном случае выгоднее. Доступные ORM, поддерживающие базы данных и языки - вопрос, который вы должны задать, почему вы не используете ORM?

Они стандартизированы, универсальны, либо указаны, либо являются общими. Кроме того, его быстрее и проще в реализации. Я использовал subsonic, linq-to-sql и структуру сущностей. Это позволяет разработчику сосредоточиться на логике и бизнес-правилах вместо отображения базы данных.

Мои (простые) два цента:

1: есть ORMS и есть ORMS. Некоторые ORMS основаны на Active Record, другие основаны на Data Mapper - это само по себе является важным фактором, но требует понимания, чтобы понять последствия. В целом, мой опыт в PHP заключается в том, что ORMS поддерживают первое, немногие поддерживают второе. ORM на основе Active Record, по-видимому, имеют один из двух эффектов: они либо нормализуют базу данных, либо вызывают множество классов для поддержки взаимодействия объектов.

2: Преимущество ORM уменьшается в прямой зависимости от сложности запроса, который вам нужно выполнить. Когда у вас хорошие приятные отношения - например, Пользователи -> Сообщения, они могут работать очень хорошо. Это (IMO), поэтому большинство ORM / каркасов используют подобные примеры. Однако, когда вам нужно выполнить сложные запросы, объем ORMQL, который вам нужно сгенерировать, сопоставим с длиной строки обычного запроса SQL - но менее производительный из-за того, что граф объектов, запускающий запрос, вызывает, что побеждает точку абстракция. Итак, в двух словах - ORM великолепны для первых 30-50% задач вашей базы данных - но ужасны для последних. Я думаю, что это еще одна причина, почему AR так распространен.

3: зачем прятаться от базы данных? Вы бы использовали язык на стороне сервера для абстрагирования JavaScript?

Лично я смешиваю эти подходы:

• используйте ORM для основ, загружая "пользователей"
• используйте DAO, содержащий несколько предварительно запеченных SQL-запросов (т.е. selectLike, selectWhere).
• расширить DAO, где это необходимо, чтобы добавить более конкретные, но повторно используемые пользовательские запросы
• Обеспечьте простой доступ к базе данных через DAO - то есть $ data = Dao-> запрос (ваша строка sql) для выполнения однократных запросов.

Сказав все это, Doctrine 2 скоро выйдет, что выглядит действительно интересно.

Вы можете использовать SQL Mapper Frameworks, такие как myBatis, если вы хотите использовать функции SQL.