#sql-server-2008 #stored-procedures #replication #merge-replication
#sql-server-2008 #хранимые процедуры #репликация #слияние-репликация
Вопрос:
У меня есть проект, в котором SPS являются единственным способом, который приложение использует для доступа или изменения базы данных Sql Server 2008. У меня есть разработчики, просящие отказаться от подхода, основанного только на SP, и позволить им напрямую использовать Linq to Sql в БД. Я должен решить, разрешить это или нет. Я должен добавить еще одну информацию, проект растет, и в ближайшем будущем нам может понадобиться вторая машина Sql Server с репликацией слиянием.
Я сказал это, потому что я полагал (но я не нахожу никакой поддержки этому в Интернете сейчас), что подход, основанный только на SP, полезен в сценарии репликации слиянием, поскольку это позволит избежать конфликтов и приведет к повышению производительности.
Есть ли доля правды в этом утверждении? Не могли бы вы сослаться на ссылку, которая подтверждает или опровергает это утверждение? Каково ваше мнение?
Это стало решающим фактором для принятия решения.
Комментарии:
1. Какие шаблоны используются для доступа к данным? т.е., Если вы используете шаблон репозитория для защиты своих приложений от деталей доступа к данным, это может быть меньше беспокойства, поскольку вы знаете, что вы можете заменить репозитории чем угодно , будь то Linq to Sql, обычный старый ADO.NET или ORM.
2. На данный момент на уровне доступа к данным нет хороших подключаемых шаблонов. Однако весь новый код, добавленный к этому устаревшему коду, начнет реализовывать интерфейсы только для того, чтобы разрешить то, что вы упомянули. Однако при переходе с SPS на другие решения всегда требуется немало работы, поэтому я хочу выбрать правильное решение сейчас. Есть ли у вас какая-либо информация о том, есть ли какие-либо преимущества или недостатки в том, что в БД есть только SP-система с репликацией слиянием?
Ответ №1:
Я не думаю, что хранимые процедуры или любой другой метод изменения данных действительно являются фактором репликации слиянием, поскольку выполнение обновления напрямую не запускает внесение изменений в базу данных распространения.
Например, если вы редактируете строку с помощью хранимой процедуры или с помощью Linq to Sql, отслеживание изменений, объединение и публикация одинаковы.
Возникает вопрос о потенциальных проблемах параллелизма, и рекомендуется протестировать этот сценарий.
Если вы используете Linq to SQL, вам нужно убедиться, что вы понимаете, когда будет выполняться оператор — это не относится к репликации слиянием.
Мой последний пункт — позаботиться о разработчиках, которые хотят изменений ради изменений. Какую пользу Linq to SQL принесет вашему конкретному приложению? Какие другие решения для доступа к данным вы рассмотрели, прежде чем выбрать Linq to SQL.
Просто потому, что Linq to SQL отлично подходит для некоторых приложений, это не значит, что он идеально подходит для каждого приложения, и это то, что, я думаю, должно влиять на ваше решение.
Лично в вашем случае я бы сохранил хранимые процедуры до тех пор, пока вы полностью не изолируете доступ к данным — это более важная задача на данном этапе.