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

Question

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

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

Итак, два вопроса:

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

Answer 1

«Правильно ли я считаю, что при использовании ORM лучше использовать простые таблицы?»

Да.

СУБД должна быть ориентирована на постоянное хранилище, и ничего более.

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

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

Oracle обладает некоторыми OO-подобными функциями PL / SQL.

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

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

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

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

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

Answer 2

Этот вопрос не имеет четкого черно-белого ответа. Существует множество противоречивых аргументов с обеих сторон, и я (imho) пока не вижу четкого консенсуса. Для противоположного взгляда, с рациональными аргументами за-против, см. ORM - Вьетнам CS , или другая ссылка ORM .

Answer 3

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

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

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

Answer 4

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

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

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

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