Одиночные или несколько баз данных

Проблема с конструкцией базы данных SQL Server 2008.

Я определяю архитектуру службы, где пользователи сайта будут управлять большим объемом данных на нескольких принадлежащих им сайтах (100 МБ в среднем, максимум 1 ГБ на сайт). Я рассматриваю вопрос о том, следует ли разбить базы данных таким образом, чтобы основные таблицы управления сайтом (пользователи, платежи, контактные данные, данные для входа, продукты и т. Д.) Хранились в одной базе данных, а база данных, относящаяся к собственным веб-сайтам клиента, хранилась в отдельной база данных.

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

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

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

Спасибо за вашу помощь.

Этот вопрос, и, таким образом, мой ответ может быть близок к серой линии субъективного, но, по крайней мере, я считаю, что обычной практикой было бы разделение таблиц «admin» на их собственный db на то, как это звучит так, как будто вы делаете. Если вы можете привязать клиента к определенному серверу и экземпляру db, то, имея отдельные экземпляры db, он открывает несколько простых путей для добавления серверов для добавления клиентов. Один дБ потребует от вас обезьяны с различными подходами к кластеризации, если вы будете слишком большими.

[править] Создание идеи в начале того, что каждый клиент получает свою собственную БД, также просто устанавливает тон для того, как вы развиваетесь, когда легко осуществить структурные и организационные изменения. Обнаружив 2 года, вы должны сделать это, станет намного более болезненным. Я работал с split dbs много раз в прошлом, и на самом деле нетрудно справиться с этим, пока вы можете установить какое-то представление о том, что такое контекст. Здесь, похоже, у вас уже есть идея, что клиент – это контекст.

Только мои два цента, как я уже сказал, вы можете быть близки к субъективным на этом.

Простые базы данных

  • Одна база данных для поддержки. Одна база данных, чтобы управлять ими всеми, а в темноте – связывать их …
  • Одна строка подключения
  • Может использовать кластеризацию

Отдельная база данных для каждого клиента

  • Поддержка настройки на основе клиента
  • Безопасность: нет никаких шансов, что клиенты будут видеть данные друг друга

Вывод

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

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

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

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

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

Представьте, что у нас есть бесконечно быстрые компьютеры, разделите ли вы свои базы данных? Конечно нет. Единственная причина, по которой мы их разделяем, – это облегчить нам задачу в какой-то момент. У вас действительно нет никакого выбора здесь, 100 МБ-1000 МБ на одного клиента огромны.

  • Пользовательская / динамическая категоризация в хранилище данных
  • Когда имеет смысл иметь одну транзакцию для нескольких подключений к базе данных?
  • Использование IF / ELSE для определения оператора SELECT INTO
  • Sql Соединяется с несколькими таблицами, возвращающими произведение из двух столбцов
  • вопрос проектирования системы
  • Создание базы данных из файла .mdf в MS Access
  • SSIS Преобразование процента в десятичный
  • Главный стол с сотнями против нескольких меньших
  • Невозможно вставить явное значение для столбца идентификатора в таблице
  • Не удалось восстановить базу данных SQL Server - Конфликт версий
  • проблема с дизайном базы данных при добавлении новых столбцов в таблицу из приложения
  • Interesting Posts

    Какой тип данных я должен использовать для хранения денежных значений?

    Оптимизация запроса SQL Server

    Разбор бит-флагов в SQL Server

    SQL Server: объединение и добавление столбцов

    Настройка зависимости maven для SQL Server

    Полнотекстовый поиск по вычисленным столбцам

    Почему я получаю InvalidCastException при приведении объекта к целому?

    EF – подключение к базе данных – ожидается, что будет использоваться проверка подлинности SQL Server, но попытка (и отказ) с проверкой подлинности Windows

    Сделать запрос SQL Select Query только для чтения

    C # Linq Как перечислить периоды времени между двумя датами для получения данных для графика

    Возвращать данные SQL из одного столбца в несколько столбцов

    Добавить сгруппированное значение в ту же таблицу

    Как параметризовать запрос с помощью специального символа в SQL Server?

    Как аннулировать доступ для входа / подключения к службам анализа SQL Server (SSAS)

    Delphi Firedac – проблема с регистром

    Давайте будем гением компьютера.