Объединение базы данных нескольких клиентов в одной облачной БД - PullRequest
Новая
       51

Объединение базы данных нескольких клиентов в одной облачной БД

1 голос
/ 20 июля 2011

Надеюсь, некоторые из вас, возможно, столкнулись с этим требованием: - У меня есть настольный продукт, который мы планируем перенести в облако.Мы будем использовать только одну базу данных в SQL-Azure и объединять базы данных всех клиентов.Для слияния у нас есть следующие опции: -

*.Наличие NewCustomerID и существующего TableID в качестве составного первичного ключа.

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

cons - почти у каждой таблицы будет составной первичный ключ и - сомнение в наличии проблемы с перфорированием (многие считают, что после поиска в Googleсоставной ключ шуд не вызывает перф проблем).Сначала код EF может вызвать некоторые проблемы.

*.Имея новый первичный ключ с автоинкрементом и сохраняя его, NewCustomerID и OLD TableID key

pros - связь между таблицами будет основываться на одном ключе и легко писать запросыи EF кодируют первые отношения.

cons - один дополнительный ключ и сохранение старого ключа

Пожалуйста, предложите свой выбор или если вы ищете совершенно новый способ справиться с таким сценариемв лазурной воде

Ответы [ 3 ]

2 голосов
/ 20 июля 2011

Это растущая потребность в SQL Azure.Однако я хотел бы отметить одну вещь: объединение всех ваших клиентских баз данных в одну базу данных SQL Azure не обязательно является масштабируемой конструкцией.Действительно, облачные вычисления - это масштабирование, а не масштабирование.В результате проектирование базы данных с целью расширения является довольно рискованным предложением.Обратите внимание, что SQL Azure имеет встроенный механизм регулирования, который блокирует длительные запросы, чрезмерное использование ресурсов и т. Д .;этот механизм регулирования является своего рода защитой от масштабируемых шаблонов проектирования.

Когда речь идет о разработке базы данных с использованием SQL Azure, у вас по существу есть следующие параметры:

  • Консолидация записей о клиентах в одной базе данных по идентификатору клиента, а затем планирование использования федерации данных SQL Azure в более позднее время (примечание: применяются некоторые ключевые ограничения; доступность этой функции пока не ясна, но публичное объявление несколько ожидается позжев этом году). Читать в статье от Cihan

  • Использовать инфраструктуру масштабируемости, такую ​​как Enzo Framework, для создания прозрачных сегментов как можно более прозрачно (отказ от ответственности: я являюсь автором этой технологии).Эта технология позволяет вам хранить базы данных ваших клиентов в разных базах данных, схемах баз данных или их комбинации с будущей поддержкой SQL Azure Data Federation. Прочитайте мой технический документ по теме

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

  • Сверните свою собственную логику разделения схемы базы данных, в которойкаждая схема базы данных содержит таблицы разных клиентов;используйте центральную таблицу, которая указывает логины клиентов на правильную схему базы данных. Прочитайте подробное описание MSDN здесь

2 голосов
/ 20 июля 2011

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

Неправильно или не совсем правильно. Зависит от того, что вы имели в виду под «отношениями». Смотри ниже.

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

Пример для наглядности: 

           Customer A might not have "Azure" in their colors table
           Customer B might have "Azure" in their colors table.

Теперь строки из таблиц цветов обоих клиентов объединены в одну таблицу: 

          COLORS
          id integer primary key
          customerid
          colorname

Таким образом, в гипотетической таблице PRODUCTS вам понадобится: 

           PRODUCTS
           id integer primary key
           customerid
           colorid

           alter table PRODUCTS add constraint
           FK_PRODUCTS_COLORS
           foreign key(colorid, customerid) references COLORS(id, customerid)

Вы не могли бы просто сделать это: 

           alter table PRODUCTS add constraint
           FK_PRODUCTS_COLORS
           foreign key(colorid) references COLORS(id)

для этого позволит ЗАКАЗЧИКУ A использовать строку для «Azure».

0 голосов
/ 20 июля 2011

Отказ от ответственности: я предполагаю, что это проблема с несколькими арендаторами.

Я бы порекомендовал поискать эту похожую тему

Вы также можете взятьпосмотрите на SQL Azure Federation и этот замечательный фрагмент SQL Azare Sharding

...