Использование ORM с хранимыми процедурами, противоречие?

Question

Я унаследовал веб-приложение, которое строго использует хранимые процедуры для выполнения своей работы. Мне нравится подход, позволяющий разработчикам frontend разбивать базу данных, но я устал писать вызовы на SP с помощью простых SQL-запросов и хотел иметь что-то здравомыслящее. Хотя я искал достойную ORM (для Perl в этом случае, но это не относится к вопросу) с поддержкой хранимых процедур, я понял, что ORM может быть прямым противоречием с SP.

Мое мышление состоит в том, что SP, как и имя, уже говорит нам, процедуры, то есть представители процедурного программирования Pascal, фактически, что одно веб-приложение выглядит точно так же, как Pascal на стороне SQL-Server - многие функций, нет реального пространства имен. В отличие от этого, мы пытаемся выполнить большую часть нашего программирования OOP-стиля (или функционального, что является еще одной темой), поэтому на самом деле процедурные SP не очень подходят для чистых иерархий объектов. В то же время реляционная логика может быть легко преобразована в объекты (через ORM), но не процедурная, поэтому, вероятно, большинство ORM не поддерживают SPs очень хорошо (но я не эксперт в этой области). В некотором смысле, SP являются ORMs.

Так эти два вопроса:

1. я прав предполагая, что мы лучше использовать простые таблицы при работе ОРМ?
2. Существуют ли какие-либо «объектно-ориентированные хранимые процедуры» на рынке, основываясь на реляционной модели? Ясно, что существуют объектно-ориентированные базы данных, но меня интересует «ORM на стороне сервера».

Answer 1

«Правильно ли мы полагаем, что нам лучше использовать обычные таблицы при работе с ОРМ?»

Да.

RDBMS следует сосредоточить на постоянном хранении и не более того.

Если вы сделаете это, вы обнаружите, что можете - легко - создать слой доступа на языке OO. Все разработчики «front-end» должны использовать уровень доступа и не могут разорвать базу данных.

"Объектно-ориентированные хранимые процедуры?"

У Oracle есть некоторые OO-подобные функции PL/SQL.

Не тратьте на него никакого вреда. Сосредоточьтесь на четком разделении между сохранением (в РСУБД) и обработкой приложения (а не в СУБД).

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

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

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

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

Answer 2

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

Обычно существуют способы оптимизации вызовов SPROC в инструментах ORM, поэтому им не нужно выбирать все столбцы, однако это обычно более продвинуто.

Я бы сказал, что это безопасно, но, как правило, вам нужно только это/нужно делать, когда вам нужно оптимизировать что-то, что будет медленным с помощью обычных методов ORM.

Answer 3

В .NET класс данных LINQ будет генерировать строго типизированный класс для процедуры. Вы вызываете следующую процедуру:

foreach (var customer in db.GetCustomers()) 
    Console.WriteLine(customer.firstName); 

Где GetCustomers() - это хранимая процедура в базе данных. Но вы не можете обновить возвращаемого клиента и внести изменения в базу данных. ORM может делать это только с помощью обычных таблиц.

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

Answer 4

В этом выпуске нет четкого черно-белого ответа. Есть много противоречивых аргументов с обеих сторон, и я, (imho), пока не вижу ясного консенсуса. Для противоположного мнения, с рациональными аргументами про-го, см. ORM - Vietnam of CS, или another ORM link.