Организация БД и таблиц в SSMS

Question

Это репост вопроса, который я задал 4 или 5 дней назад, с нулевым ответом. Надеемся на удачу в этот раз ...

(с использованием SQL Server 2008)

В течение следующих нескольких недель я планирую представить сервер SQL в офисе, который остро нуждается в надлежащем сервере данных. В настоящее время существует сильная зависимость от свободного файла Excel и Access (дополненного пугающе большим количеством непробиваемого кода VB для манипулирования данными), разбросанного по всей внутренней сети.

Нам нужен SQL-сервер для двух вещей:
1. Для внутренних баз данных, которые будут разработаны заранее и будут собирать данные на постоянной основе
2. Для специальных загрузок наборов данных, полученных от клиентов, которые мы затем анализируем

Я единственный человек в этом офисе, кто знаком с SQL. Я должен буду обучить других 5 или 6 человек использовать его.

Теперь мой вопрос таков: как бы вы, ребята, настроили БД, чтобы с помощью Management Studio было легко визуально определить, где что хранится? Чтобы быть более точным: если бы это была файловая система Windows, она бы выглядела примерно так:

c: \ работа клиента \ клиент 1 \ работа 1 (дБ с 10 таблицами) \
c: \ работа клиента \ клиент 1 \ произведение 2 (дБ с 8 таблицами) \
c: \ работа клиента \ клиент 1 \ часть работы 3 (база данных с 7 таблицами) \

c: \ internal \ система учета \ some db с 8 таблицами \
c: \ internal \ система учета \ some db с 5 таблицами \
c: \ internal \ какая-то другая система \ несколько БД с 7 таблицами \

и т.д.

Итак, вкратце, мне нужно визуально разделить на внутреннюю и клиентскую работу. Работу клиента мне нужно разделить на разных клиентов. Для каждого клиента мне нужно разделить различные наборы работ. (Внутренняя работа идет по аналогичной схеме).

Решения, которые мне известны:

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

Буду рад услышать ваши предложения!

Answer 1

Организационными инструментами для управления SQL Server являются экземпляры, базы данных и схемы:

Сервер может запускать несколько экземпляров. Экземпляр - это, по сути, совершенно отдельный экземпляр сервера на том же компьютере.

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

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

Все эти "контейнеры" так или иначе связаны с безопасностью.

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

Оттуда перейдите к определению ролей для ваших пользователей. Наличие ролей - намного лучшая стратегия, чем назначение прав отдельным пользователям. Он документирует семантическое значение доступа (любой человек, выполняющий эту роль, нуждается в этом доступе, в отличие от личности пользователя - Джон и Кейт нуждаются в доступе - это ничего не говорит о том, зачем ему нужен доступ). Будьте уверены, что роли достаточно мелкозернистые. Роль отдела, такая как AccountsReceivable, не так полезна, как PaymentApprover, InvoiceProcessor или AccountsSupervisor. Пользователи могут действовать в разных ролях - это даст вам гораздо больше возможностей самодокументирования в вашей инфраструктуре и намного меньше дыр в безопасности и головной боли.

Это должно помочь определить, какие контейнеры вам понадобятся и какой доступ предоставить и направить вашу инфраструктуру данных оттуда.

Что касается предоставления пользователям прямого доступа, я с Рэнди Миндером, SQL Server в лучшем случае является только опытным инструментом пользователя. Если они знакомы с Access, хорошим вариантом будет позволить им использовать Access против тщательно разработанных и выбранных представлений в SQL Server, пока они не будут готовы к более систематическому подходу к проектированию данных.

Answer 2

IMO, пользователи ваших баз данных не должны знать или заботиться о том, где и как ваши базы данных настроены. И им не следует предоставлять доступ к SSMS, если они не хорошо обучены SQL. Это катастрофа, ожидающая случиться. Вы должны создавать приложения и / или отчеты, которые предоставляют пользователю доступ к нужным им данным. Таким образом, им все равно, где находятся данные, и им не нужно знать.