Чи слід уникати схеми dbo?

Якщо мова йде про схему dbo:

• Чи є найкращою практикою уникати використання схеми dbo при створенні об'єктів бази даних?
• Чому слід уникати схеми dbo або слід?
• Який користувач бази даних повинен володіти схемою dbo?

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

HR.Payhist
HR.Payscale
HR.Jobdesc
IT.username
IT.useraccesslevel
ENG.jobsite
ENG.trainings

Як директор з персоналу, я маю доступ до будь-якої HRсхеми, як ITдиректор я можу бачити імена користувачів та рівні доступу працівників. У Engineeringвідділі можна побачити, які сайти робочих місць активні тощо. Якщо dbo була встановленою схемою для всіх таблиць, мені було б важче сегментувати свої дані та надавати ролі доступу.

Я вважаю, що в SQL Server ідея пропонувати продукт, до якого можуть мати доступ і запитувати різні відділи. Насправді тільки бази даних (DBA) / DBDevs дійсно отримують доступ до бази даних, і вони, як правило, зберігають лише дані додатків.

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

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

Я думаю, що це дійсно зводиться до уподобань користувачів, оскільки для цього немає реальних технологічних причин. Насправді, для простоти, я кажу завжди використовувати dbo, якщо ваші вимоги безпеки не передбачають іншого. Звичайно, ви завжди можете це робити і для організаційних цілей.

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

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

Наприклад, у нас може бути система інвентаризації з базою даних. Основні таблиці можуть бути в схемі inv. Якщо ми імпортуємо що-небудь в базу даних, то схема постановки буде використовуватися як частина процесу імпорту. Якщо у нас є якісь системні збережені процедури, до яких користувачі не потребують доступу, ми ставимо їх у схему sp.

Раніше це не було найкращою практикою, оскільки схеми були приховані до SQL 2005, все було поставлено у схему dbo. Команда SQL Server показує це як найкращу практику та опублікувала статтю про неї: Найкращі практики SQL Server - реалізація об'єктних схем бази даних

Що стосується вашого іншого запитання щодо того, хто повинен ним володіти: схема dbo належить обліковому запису користувача dbo.