як backend-розробник, ми досить знайомі з Activerecord/Gorm/Hibernate. Використання ORM для взаємодії з базою даних значно полегшує процес розробки бекенду, але, звісно, за цією зручністю стоять певні компроміси. Ось кілька недоліків використання ORM:
Photo by Daphné Be Frenchie on Unsplash
Виконання менш ефективних SQL запитів
ORM часто генерує SQL запити, які є більш складними, ніж це необхідно, що може призвести до проблем з продуктивністю.
Приклад при отриманні таблиці, яка асоційована з іншою таблицею, використовуючи Join:
SELECT u.id, u.name, o.id, o.total
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE u.id = 1;
ORM, якщо не використовувати метод join:
SELECT * FROM users WHERE id = 1;
SELECT * FROM orders WHERE user_id = 1;
Запит буде виконано вдвічі більше, ніж при використанні запиту join.
Абстракція приховує специфічні можливості бази даних
ORM розроблені для того, щоб бути незалежними від бази даних, тому деякі можливості, які є тільки в конкретних базах даних, не можна оптимізувати.
У PostgreSQL можна використовувати стовпці JSONB та індекси для швидкого пошуку JSON даних.
Крива навчання для налагодження
Через використання абстракцій, іноді потрібно перевіряти документацію, щоб дізнатися, який запит викликається. Деякі ORM можуть вести журнал запитів, що викликаються функцією.
Можливість виникнення проблеми N+1 запитів
ORM може неосвідомлено використовувати неефективні запити для отримання пов’язаних даних.
Приклад на Activerecord Ruby:
const users = await User.findAll();
for (const user of users) {
const orders = await user.getOrders();
}
В результаті один запит для отримання даних користувачів і N запитів для отримання даних замовлень, що значно сповільнює процес.
Висновок
Звісно, всі ці проблеми можна вирішити, якщо бути свідомим того, які функції використовуються в ORM. Хоча ORM зручні для швидкої розробки, Native Query пропонують кращий контроль, продуктивність і гнучкість у складних або високо-продуктивних сценаріях. Розуміння переваг і недоліків допомагає вибрати правильні інструменти.
Перекладено з: Mengapa sebaiknya Tidak Menggunakan ORM(Object Relation Mapping)