Перемещение локальных баз данных SQL Server 2008 на один интернет-сервер - PullRequest
1 голос
/ 10 ноября 2009

Кто-нибудь имел опыт переноса нескольких идентичных баз данных SQL Server (с уникальными данными) с отдельных локальных серверов на один интернет-сервер?

В настоящее время у нас есть 10 компаний, использующих наше приложение для Windows, которое использует SQL Server 2008 для хранения данных, но мы находим, что поддержание баз данных и обеспечение их резервного копирования и т. Д. Является большой головной болью, поскольку все они находятся на отдельных локальных LANS.

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

Если бы мы просто создали 50 идентичных баз данных на нашем собственном интернет-сервере, мы могли бы достичь этого без особых изменений, но является ли это лучшим подходом?

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

Каждая организация имеет от 2 до 10 сотрудников и вводит около 5000-10000 записей в год, состоящих из 20 полей, состоящих в основном из символов и целых, поэтому оно не слишком велико.

Любое руководство будет оценено.

Ответы [ 3 ]

1 голос
/ 10 ноября 2009

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

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

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

1 голос
/ 10 ноября 2009

Скорее всего, вам лучше обслуживать базы данных отдельно. У нас была похожая проблема, и необходимость в том, чтобы клиенты не смешивали свои данные (в случае проблем с безопасностью), была главной задачей, хотя возможность переместить некоторых клиентов на другой сервер также является хорошей. Кроме того, с отдельными базами данных вы можете вносить незначительные изменения в одного клиента, не затрагивая их всех (либо для индивидуальных решений, либо для разных версий, если один не хочет обновляться и т. Д.).

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

Мы также создали несколько сценариев / пакетных программ, которые выполняли бы запросы SQL ко всем (или заданным) базам данных, чтобы обновления или отчеты по запросам могли выполняться очень быстро для 50+ баз данных без какой-либо дополнительной работы. Эти сценарии определенно стоят усилий для разработки, и могут быть сторонние приложения, которые делают то же самое.

0 голосов
/ 10 ноября 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...