Вопрос по nhibernate, entity-framework, orm, linq-to-sql – Убеждение жесткого администратора базы данных в использовании ORM для большинства CRUD против хранимых процедур, представлений и функций

10

Я работаю с NHibernate, LINQ to SQL и Entity Framework уже довольно давно. И хотя я вижу преимущества использования ORM для ускорения процесса разработки, простой код инесоответствие реляционного сопротивления объекта по крайней мере, я все еще нахожу очень трудным убедить сильного SQL dba в сильных сторонах ORM. С моей точки зрения, ORM может использоваться как минимум для 90-95% всего вашего доступа к данным, оставляя эти действительно сложные вещи в процедурах или функциях, где это уместно. Я ни в коем случае не парень, который говорит, что мы должны делать все в ORM!

Question: Каковы некоторые из лучших аргументов для убеждения старой школы в том, что использование ORM - не самая худшая идея, когда-либо задуманная программистом!

Ответ. Администратор базы данных может контролировать специальные чтения, определяя VIEW, которые ORM может использовать для этих операций чтения. После того, как указанные VIEW созданы для этих чтений, программисту не нужно беспокоиться о DBA, когда они хотят разные сортировки / фильтры или возвращать определенные столбцы и т. Д. DML может быть передан sprocs, чтения могут быть переданы в VIEWS, к которым обращается ORM. , Я согласен, что во многих случаяхmost из того, что приложение должно сделать, читает. MikeM

Ваш Ответ

4   ответа
6

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

If the schema changes it's difficult to track down all the stored procedures that are affected. It's impossible ensure that multiple stored procedures aren't created to do the same thing, or if slightly altering an existing stored procedure is going to have serious ramifications. It's difficult to make sure that the application and database are in sync after a deploy.

Динамический SQL имеет все эти проблемы и многое другое.

Если ваша команда не использует БД, отличную от SQL Server, в этом случае использование проекта БД в VS2008 не вариант для вас. Тогда эти пункты имеют смысл.
Не объясни это. Докажите это.
# 1, Существуют инструменты для отслеживания зависимостей в изменениях схемы для большинства основных СУБД, эти инструменты проверяют не только sprocs, но также UDF и триггеры. # 2, многие из нас, вероятно, видели бесчисленное множество .NET / PHP / Java (и др.) Функций, созданных для того же, или если немного изменить существующую [function / class / struct / enum ...] будет иметь серьезные последствия. & quot; Очевидно, что принцип относится кANY программирование ситуации, а не только базы данных. # 3, Нет, это не сложно. Это то, для чего предназначены автоматизированные тесты.
Один парень, с которым я работал, говорит: «Мы должны использовать хранимые процедуры, чтобы изолировать зависимые приложения от изменений». Затем он изменил то, что хранимая процедура вернула одному из моих приложений и сломал его! А? Andrew Siemer
Если вы используете проект БД, такой как в VS2008, он фактически компилирует базу данных и предупредит вас о любых ошибках из-за изменений схемы (например, доступ к измененным столбцам и т. Д.), Поэтому ваша точка 1 недействительна. Точно так же пункт 2 является недействительным, если кто-то отвечает за БД и не позволяет вмешиваться. А 3 сводится на нет при наличии надлежащего автоматического развертывания. Так что я действительно не покупаю ни один из этих аргументов.
0

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

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

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

@ Совят, хотя я полностью согласен с логикой, которую вы представляете ... Я должен признать, что во всех местах, где я был, я никогда не менял свой SQL Server на сервер Oracle ... или MySQL. Я слышал этот аргумент в пользу ORM очень много раз, но на самом деле я никогда не был там, где это оправдывалось! +1 любой как! Andrew Siemer
Я согласен, что это случается не часто. Однако заменяемые серверные части в основном бесплатны, если вы используете ORM, который их поддерживает. Я предполагаю, что на самом деле моя точка зрения заключалась в том, что процедуры тесно связаны между собой, а ORM развязаны.
2

«Убедить сурового администратора базы данных»to use an ORM& Quot; было бы: является ли администратор БД также программистом, который также работает вне БД, чтобы он / она "использовал ORM"? Если нет, то почему администратор БД отдает основную часть своей работы кому-то другому и тем самым значительно снижает их общую полезность для компании? Они бы не ".

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

С другой стороны, я думаю, что вы не получите объектную дилемму реляционного импеданса, если вы пытаетесь использовать это в качестве аргумента для использованияObject-Relation-Mapper, Администратор базы данных может процитировать по той ссылке, которую вы разместили, где он говорит "Отображение такого представления частного объекта в таблицы базы данных"makes such databases fragile according to OOP philosophy& Quot; и что проблема еще более ярко выражена, "в частности, когда объекты или определения классов отображаются (ORM) прямым способом в таблицы базы данных или реляционные схемы". Таким образом, продвигая ORM, вы продвигаете проблему по своей ссылке.

Используя sprocs, администратор базы данных может вносить изменения в базовую схему, если sproc по-прежнему возвращает те же столбцы с теми же типами. Таким образом, благодаря этой абстракции, которую добавляют sprocs, проблемы с непосредственным отображением схемы сводятся на нет. Это не означает, однако, что вам нужно отказаться от вашего любимого EF, так как теперь EF можно довольно счастливо использовать со звездочками.

11

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

Однако мое первое предположение относительно его проблемы будет состоять в том, что он не позволяет ему выполнять какую-либо оптимизацию, поскольку вы обращаетесь к таблицам напрямую, поэтому у него нет уровня абстракции, за которым нужно работать, поэтому, если таблицу нужно изменить или (де) нормализовать, тогда он не может сделать это, не нарушив вашу заявку.

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

Мне нравится ваша точка зрения. Однако вещь, которую я никогда не понимал, заключается в том, что администраторы баз данных и программисты не являются «одной командой». Почему в большинстве мест, где я работаю, есть администраторы баз данных, и разработчики отделены друг от друга, когда их обязанности превышают SOOO. В случае, если вы настроены на оптимизацию - стандартным способом для этого является ORM все (99%?), Определение потребностей для оптимизации и перенос запроса в процесс, где это необходимо. Но в большинстве случаев я считаю, что ORM генерируют отличный SQL! Andrew Siemer
Мы все работаем вместе, и у нас нет никаких трений. Но вы должны понимать разницу в ролях. Администраторы баз данных несут ответственность за правильную работу, резервное копирование и работу баз данных. Если операции с БД медленны из-за неправильной структуры таблицы и необходимости ее изменения, то кто получит вину, если она не может быть исправлена? DBA. Но он ничего не может с этим поделать, потому что люди получают прямой доступ к столам. Это одна из причин, почему многие из них против прямого доступа к таблицам.

Похожие вопросы