Чим хороші схеми SQL Server?

Я не починаю використовувати бази даних SQL, і зокрема SQL Server. Однак я, головним чином, хлопець SQL 2000, і мене завжди бентежили схеми в 2005+. Так, я знаю основне визначення схеми, але для чого вони реально використовуються для типового розгортання SQL Server?

Я завжди просто використовував схему за замовчуванням. Чому я хочу створити спеціалізовані схеми? Чому я б призначив будь-яку з вбудованих схем?

EDIT: Для уточнення, я думаю, я шукаю переваги схем. Якщо ви збираєтесь використовувати його лише як схему безпеки, здається, що ролі баз даних вже заповнені, що .. е .. гм .. роль. І використовувати його як специфікатор простору імен, здається, було щось, що ви могли зробити з власністю (dbo порівняно з користувачем тощо).

Я здогадуюсь, що я отримую, це те, що роблять схеми, які ти не міг зробити з власниками та ролями? Які їхні конкретні переваги?

Схеми логічно групують таблиці, процедури, погляди разом. Усі об'єкти, пов'язані з працівниками, у employeeсхемі тощо.

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

Подібно до простору імен C # кодів.

Вони також можуть забезпечити своєрідний захист від зіткнення даних плагінів. Наприклад, нова функція зміни даних захоплення даних у SQL Server 2008 таблиці використовує таблиці в окрему схему cdc. Таким чином, їм не потрібно турбуватися про конфлікт імен між таблицею CDC та реальною таблицею, що використовується в базі даних, і з цього приводу можуть навмисно затінювати імена реальних таблиць.

Я знаю, що це стара нитка, але я просто переглянув схеми і думаю, що наступне може стати ще одним хорошим кандидатом для використання схеми:

У сховищі даних із даними, що надходять із різних джерел, ви можете використовувати різні схеми для кожного джерела, а потім, наприклад, керувати доступом на основі схем. Також уникає можливих зіткнень з іменами між різними джерелами, як відповів інший плакат вище.

Якщо ви зберігаєте свою схему дискретно, ви можете масштабувати додаток, розгорнувши задану схему на новому сервері БД. (Це передбачає, що у вас є додаток або система, яка достатньо велика, щоб мати чітку функціональність).

Прикладом розглянемо систему, яка здійснює ведення журналів. Усі таблиці реєстрації та SP входять у схему [logging]. Ведення журналу - хороший приклад, оскільки рідко (якщо взагалі є) інша функціональність в системі перекриває (тобто приєднується до) об'єкти в схемі реєстрації.

Підказка щодо використання цієї методики - мати різний рядок з'єднання для кожної схеми у вашій програмі / системі. Потім ви розгортаєте елементи схеми на новому сервері та змінюєте рядок підключення, коли потрібно масштабувати.

Я схильний погодитися з Брентом щодо цього ... дивіться цю дискусію тут. http://www.brentozar.com/archive/2010/05/why-use-schemas/

Якщо коротко ... схеми не дуже корисні, за винятком дуже конкретних випадків використання. Робить речі безладними. Не використовуйте їх, якщо можете допомогти. І спробуйте дотримуватися правила K (eep) I (t) S (Imple) S (tupid).

Я не бачу вигоди у видаленні користувачів, прив'язаних до схем. Ось чому….

Більшість людей спочатку підключають свої облікові записи користувачів до баз даних за допомогою ролей. Як тільки ви призначите користувача будь-якому sysadmin або ролі бази даних db_owner у будь-якій формі, цей обліковий запис або псевдонім до "dbo" облікового запису користувача, або має повний дозволи на базу даних. Як тільки це відбудеться, незалежно від того, як ви присвоюєте собі схему, що виходить за схемою за замовчуванням (яка має те саме ім’я, що і ваш обліковий запис користувача), ці права dbo присвоюються тим об’єктам, які ви створюєте під користувачем та схемою. Це свого роду безглуздо ..... а просто простір імен і плутає справжнє право власності на ці об'єкти. Його поганий дизайн, якщо ви запитаєте мене .... хто б це не спроектував.

Що вони повинні були зробити, це створити "Групи", викинути схеми та роль і просто дозволити вам впорядкувати групи груп у будь-якій комбінації, яка вам подобається, а потім на кожному ярусі повідомте системі, чи дозволи дозволені успадковуються, відмовляються чи перезаписуються на замовлення ті. Це було б набагато інтуїтивніше, що дозволило б DBA краще контролювати, хто на цих об'єктах справжні власники. Зараз його мається на увазі в більшості випадків користувач SQL Server за замовчуванням має ці права .... а не користувач.

У магазині ORACLE, в якому я працював багато років, схеми використовувались для інкапсуляції процедур (і пакетів), які застосовувались до різних застосувань. Різна схема "API" для кожної програми часто мала сенс, оскільки випадки використання, користувачі та системні вимоги були зовсім різними. Наприклад, одна схема "API" була для програми для розробки / конфігурації, яка повинна використовуватися лише розробниками. Ще однією схемою "API" був доступ до клієнтських даних за допомогою переглядів та процедур (пошуку). Ще один інкапсульований код схеми "API", який використовувався для синхронізації розробки / конфігурації та даних клієнта з додатком, який мав власну базу даних. Деякі з цих схем "API" під обкладинками все ще поділять загальні процедури та функції з іншими (через інші "COMMON"

Я скажу, що відсутність схеми - це, мабуть, не кінець світу, хоча це може бути дуже корисним. Дійсно, саме відсутність пакетів у SQL Server справді створює проблеми в моїй свідомості ... але це вже інша тема.

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

Мені здається, що схеми приблизно еквівалентні необов'язковим просторам імен. Якщо ви опинилися в ситуації, коли назви об'єктів стикаються і деталізація дозволів недостатньо точна, ось вам інструмент. (Я схиляюсь сказати, що можуть виникнути проблеми дизайну, які слід вирішити спочатку на більш фундаментальному рівні.)

Проблема може полягати в тому, що якщо він є, деякі розробники почнуть випадково використовувати його для короткострокової вигоди; і як тільки він буде там, він може стати кудзу.

У SQL Server 2000 об’єкти, створені, були пов’язані з цим конкретним користувачем, як, наприклад, якщо користувач, скажімо, Сам створює об'єкт, скажімо, Співробітники, ця таблиця виглядатиме так: Sam.E Employees. А як бути, якщо Сем залишає компанію або переїжджає в іншу ділову сферу. Як тільки ви видалите користувача Sam, що буде з таблицею Sam.E Employees? Ймовірно, вам доведеться спочатку змінити право власності з Sam.E Employees на dbo.Eслуess. Схема забезпечує рішення для подолання цієї проблеми. Сем може створити всі свої об'єкти в межах схеми, такої як Emp_Schema. Тепер, якщо він створює об'єкт Співробітники в межах Emp_Schema, то об'єкт буде іменуватися як Emp_Schema.E Employees. Навіть якщо обліковий запис користувача Sam потрібно видалити, на схему це не вплине.

розвиток - кожен з наших розробників отримує власну схему, як пісочницю, в яку можна грати.

Ось хороший приклад реалізації схеми використання SQL Server. У нас було кілька програм для доступу до MS. Ми хотіли перетворити їх на портал додатків ASP.NET. Кожна програма доступу до MS пишеться як додаток для цього порталу. Кожна програма доступу до MS має власні таблиці баз даних. Деякі з них пов'язані, ми розміщуємо їх у загальній схемі dbo для SQL Server. Решта отримує власні схеми. Таким чином, якщо ми хочемо знати, які таблиці належать додатку на порталі додатків ASP.NET, за яким можна легко переміщуватися, візуалізувати та підтримувати.