Які переваги використання абстракції баз даних ORM? [зачинено]

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

Ідея ORM полягає в тому, що він намагається допомогти мені, зробивши все бази даних агностичними. Це звучить чудово, але часто є причина, чому я обираю конкретну систему баз даних. Але, пройшовши шлях агностики бази даних, ORM приймає найменший загальний знаменник, що означає, що я закінчую найменшим набором функцій (тих, які підтримуються всіма базами даних).

Що робити, якщо я знаю, що тривалий час я не буду перемикати базу даних? Чому також не отримати доступ до особливостей, що стосуються бази даних?

Я бачу це так само. Будь-яка абстракція, яка не дозволяє потрапити під неї, коли це необхідно, є злом, оскільки вона призводить до різного роду потворних інверсій абстракції у вашому коді.

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

IMO будь-який ORM, який не має цієї функції, не вартий бітів, з яких складається.

ORM приймає найменший загальний знаменник

Я повинен не погодитися з вашою заявою. Я візьму nHibernate як приклад. Цей фреймворк підтримує безліч баз даних, включаючи найпопулярніші, незалежно від версії (та підтримуваних функцій), як і більшість 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 в основному означає " Unstored Procedure ". Там я ввів термін.

Все, що робить ORM, ви можете повторити за допомогою Views, Triggers та Stored Procedure. Вони допомагають абстрагувати необроблений SQL і можуть підтримувати нормалізовані бази даних. Але це добре працює лише для простих випадків. Якщо є занадто оброблюваних даних для оброблення, вони можуть стати збитком продуктивності. (ORM в PHP часто приймають на увазі скрипт даних, оскільки ланцюги SQL Builder не можуть все абстрагувати.)

Але, як завжди, все залежить від застосування та завдання, що знаходиться під рукою.

Одне, що шкодить використанню ORM, - це те, що багато їхніх шанувальників схильні стверджувати, що нам більше не потрібно знати теорію SQL та RDB. Результати варіюються від смішних до зовсім катастрофічних. І це незважаючи на мільйон разів, які ORM виробляє і вказує, що ми повинні добре знати теорію SQL і RDB, щоб правильно використовувати та налаштувати ORM.

Чому люди використовують інструмент, який використовує його у багатьох, але не у всіх контекстах, у магічну, загальноприйняту срібну кулю - це поза мною.

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

Завдяки ORM ( Propel , у PHP) ми розділили частину логіки коду, тому до однієї функції додано частину запиту "є дійсно записана", інша - частина безпеки ("показувати ці записи лише якщо користувач має ці можливості "), ... Якщо основна структура змінилася (додаткове поле, яке слід враховувати для" дійсності запису "), нам довелося змінити лише одну функцію, а не двадцять SQL-пропозицій.

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

Якщо запит був надто складним для висловлення з критеріями Propel, або нам потрібні деякі особливості постачальника (в основному повнотекстовий пошук, оскільки ми використовували MySQL), це не було проблемою з Propel. Ви можете додати спеціальні критерії , або коли це дійсно потрібно, ми використовували необроблений SQL ( тепер ще простіше поєднувати з фактичними об'єктами Propel). Ви можете легко додати додатки, характерні для вашого постачальника, до створених класів, щоб у вас було найкраще з обох світів: немає коду SQL у вашому коді додатка, але з усіма можливостями вашої бази даних.

Але справа в тому, що ти повинен програмуватися далеко від бази даних, тобто не потрібно думати, як ти в базі даних.

Я зараз працюю в C # і дуже багато використовую LINQ, тому багато і безліч вільних методів. Мені не потрібно думати про те, як мої об’єкти зберігаються чи знаходяться або навіть зберігаються на програмному рівні, і дуже мало на рівні бізнес-рівня.

Досить часто методи, надані самими конкретними базами даних, використовуються в роз'ємі DB, тому ви отримуєте ці оптимізації, не знаючи, що вони є.

Ви все ще можете записати функції на стороні DB. Часто їх можна просто накреслити.

І, перш за все, поділ подібного роду дозволяє перевірити і змусити вас (трохи) написати краще структурований код

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

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

Для мене головна перевага використання ORM - це не обов'язково те, що він робить агностиком бази даних додатків (хоча це теж добре), а те, що я здебільшого не мушу думати про те, як зберігаються речі та вилучено.

Однак в якийсь момент вам, швидше за все, доведеться подумати над цим, залежно від вимог до вашої заявки. ОРМ - це не магія.

Я написав своє, що допомагає мені робити вибір і вставляти простіше.

Доступна річ для кожного конкретного db. Мені просто потрібно написати запит, з яким мені допомагає бібліотека (я можу використовувати "?" Та парами, а не вручну називати параметр і використовувати .Add)

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

Введення коду для вставки та вибору, оновлення в онлайні чи із збереженими документами та відображення їх назад через DAL - це довше норма, а корисна лише у винятковому випадку. Наявні ORM, підтримувані бази даних та мови, питання, яке ви повинні задати, чому ви не використовуєте ORM?

Вони стандартизовані, універсальні, або визначені, або загальні. крім того, його швидше та простіше у виконанні. Я використовував дозвукові, linq-sql та сутнісні рамки. Це дозволяє розробнику зосередитись на логіці та бізнес-правилах, а не на базі даних.

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

1: Є ORMS і є ORMS. Деякі ORMS базуються на Active Record, інші - на базі даних Mapper - це саме по собі є релевантним фактором, але той, який потребує певного дослідження, щоб зрозуміти наслідки. Взагалі - мій досвід роботи в PHP полягає в тому, що ORMS підтримують перше, мало хто підтримує останній. ОРМ, що базуються на активному записі, мають один із двох ефектів - вони або денормалізують базу даних, або викликають безліч класів для підтримки об’єктних взаємодій.

2: Перевага ORM зменшується в прямій залежності від складності запиту, який потрібно запустити. Коли у вас хороші прості стосунки - тобто користувачі -> повідомлення, вони можуть працювати дуже добре. Це (IMO), тому більшість ORM / фреймворків використовують подібні приклади. Однак, коли вам потрібно запустити складні запити, кількість ORMQL, який потрібно створити, порівнянна з довжиною рядка звичайного запиту SQL - але менш ефективною завдяки графіку об'єктів, що виконує виклик запиту, який вражає точку абстракція. Отже, у двох словах - ORM є блискучими для перших 30-50% завдань у вашій базі даних - але жахливих для останніх. Я думаю, це ще одна причина, чому АР так поширений.

3: Навіщо ховатися від бази даних? Чи використовуєте ви мову сервера на абстрактному javascript?

Особисто я змішую такі підходи:

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

Сказавши все це, незабаром виходить Доктрина 2, яка виглядає дуже цікаво.

Ви можете використовувати рамки SQL mapper, такі як myBatis, якщо ви хочете використовувати функції sql.