Чи є недоліки в базах даних, що містяться?

SQL Server 2012 представив концепцію "містяться" баз даних, де все (ну, в основному все, що потрібно) базі даних міститься в самій базі даних. Це дає великі переваги при переміщенні баз даних між серверами. Мені хотілося б знати, якщо це має бути моєю стратегією за замовчуванням при розробці нової бази даних.

MSDN перераховує кілька недоліків, що містяться в базах даних, а великі - відсутність підтримки для відстеження змін та реплікації. Є інші? Якщо я не збираюся використовувати ці функції, чи є якась причина, щоб не використовувати вміщені бази даних?

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

З'єднання струн

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

Перехресні запити

Навіть якщо ви створили того самого користувача з тим самим паролем у двох різних вміщених базах даних на одному сервері, ваша програма не зможе виконувати запити міжбазових баз даних. Імена користувача та паролі можуть бути однаковими, але вони не є тим самим користувачем. Причина цього? Якщо ви розмістили бази даних на розміщеному сервері, вам не слід перешкоджати тому, що той самий вміщений користувач, як хтось інший, який, як правило, використовує той же розміщений сервер. Коли надходить повне обмеження (ймовірно, у версії після SQL Server 2012 ніколи), крос-бази запитів у будь-якому випадку абсолютно забороняться. Я дуже, дуже настійно рекомендую не створювати входи на рівні сервера з тим самим іменем, що і користувачі баз даних, і намагатися уникати створення однакових ім’я користувачів, що містяться в базі даних. Якщо вам потрібно запустити запити, які потрапляють на кілька містяться баз даних, зробіть це за допомогою входу на рівні сервера, який має відповідні привілеї (ви можете подумати, що це так sysadmin, але для запитів лише для читання це є CONNECT ANY DATABASEі SELECT ALL USER SECURABLES).

Синоніми

Більшість 3- і 4-частинних імен легко ідентифікувати та відображатись у DMV. Однак якщо ви створюєте синонім, який вказує на 3- або 4-частинне ім'я, вони не відображаються в DMV. Отже, якщо ви сильно використовуєте синоніми, можливо, ви пропустите деякі зовнішні залежності, і це може спричинити проблеми в момент переміщення бази даних на інший сервер. Я поскаржився на це питання, але воно було закрите як "задумом" і не пережило міграцію до нової системи зворотного зв'язку . Зауважте, що DMV також буде пропускати 3- та 4-імена імена, побудовані за допомогою динамічного SQL.

Політика щодо паролів

Якщо ви створили вміщеного користувача бази даних у системі без встановленої політики паролів, можливо, вам буде важко створити того самого користувача в іншій системі, яка має політику паролів. Це відбувається тому, що CREATE USERсинтаксис не підтримує обхід політики паролів. Я подав помилку щодо цієї проблеми, і вона залишається відкритою (і вона також не пережила ходу, коли Connect вийшла на пенсію). І мені здається дивним, що в системі, що має політику паролів, ви можете створити логін на рівні сервера, який легко обходить політику, але ви не можете створити користувача бази даних, який це робить - навіть якщо цей користувач притаманний менше ризику для безпеки.

Збірка

Оскільки ми більше не можемо покладатися на зіставлення tempdb, можливо, вам доведеться змінити будь-який код, який наразі використовує явне зіставлення, або DATABASE_DEFAULTвикористовувати CATALOG_DEFAULTзамість цього. Дивіться цю статтю BOL щодо деяких потенційних проблем .

IntelliSense

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

Інструменти даних SQL Server

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

АЛЬТЕР ДАТАБАЗА

При запуску ALTER DATABASEкоманди з в контексті вмісту бази даних, rRather , ніж ALTER DATABASE fooвам потрібно буде використовувати ALTER DATABASE CURRENT- це так , що , якщо база даних переміщені, перейменовані і т.д. ці команди не повинні нічого знати про свій зовнішній контексті або посилання .

Кілька інших

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

• пронумеровані процедури
• тимчасові процедури
• зміни зіставлення в пов'язаних об'єктах
• змінити захоплення даних
• відстеження змін
• тиражування

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

Вам також потрібно бути впевненим, що якщо міститься база даних, яка буде переміщена, або є частиною групи доступності або відображається в дзеркальному відображенні, що для всіх потенційних серверів призначення встановлено sp_configureпараметр contained database authentication1.

Ви можете вважати цю публікацію в блозі корисною, як і цю , навіть незважаючи на те, що вони датують RTM.

Для тих, хто зацікавлений отримати більш детальну інформацію про вміщені бази даних, я можу рекомендувати їх прочитати цю статтю http://www.sqlshack.com/contain-databases-in-sql-server/

У статті визначено основні переваги / недоліки використання вміщених баз даних.

Недоліки

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

Переваги

З іншого боку, як уже було сказано, є деякі переваги використання містяться БД, такі як:

• Перемістити базу даних з одного сервера на інший досить просто,
  оскільки проблем із сиротами користувачів не виникне
• Метадані зберігаються у вміщених базах даних, тому вони простіші та портативніші
• Для користувачів, що містять БД, можлива аутентифікація SQL Server та Windows

Стаття також допомагає:

• створення нової бази даних, що міститься (шляхом введення типу містити як частковий на сторінці параметрів на SQL сервері та використання запиту T-SQL для створення бази даних згодом)
• підключення до БД, що міститься, за допомогою SQL Server Management Studio (потрібно вказати ім'я БД, що міститься в параметрі з'єднання)
• перетворення існуючої бази даних у базу даних, що міститься
• робота над вміщеною базою даних та перелік усіх входів, що містять тип користувача

Одним з недоліків є те, що користувач, що містить базу даних, не може бути змушений змінювати свій власний пароль, як могли входити ( MUST_CHANGE). Користувачі не можуть керувати власним паролем, якщо ви не надаєте їм дозвіл на зміну користувача та не скажете їм, як змінити його за допомогою оператора SQL. Їм ніде нелегко керувати ним за допомогою інтерфейсів користувача або, принаймні, я не знаю як.

Додаткове зауваження полягає в тому, що я виявив несподіване та незадокументоване використання метаданих у пункті "PIVOT" та "UNPIVOT", яке, на мою думку, повинно бути лише у системному каталозі (sys.tables / sys.column / тощо). Як задокументовано в msdn :

У вміщеній базі даних зіставлення каталогу Latin1_General_100_CI_AS_WS_KS_SC . Це порівняння є однаковим для всіх вміщених баз даних на всіх примірниках SQL Server і його неможливо змінити.

Але вони не згадували, що в пункті "PIVOT" І "UNPIVOT" також використовуються системні каталоги як механізм виконання. тому він створює конфліктну помилку зіставлення скрізь поблизу використання пункту "PIVOT" І "UNPIVOT" під час міграції. ось кілька докорів:

/*step1 create a table belongs to a contained database and populate some data*/
create  table dbo.test1 (col1 varchar(100),col2 varchar(100))
insert  dbo.test1 values('a','x')
insert  dbo.test1 values('b','y')
insert  dbo.test1 values('c','z')

/*step2 lets see its collation you will see it is correctly as same as its (contained) database */
select name,collation_name from sys.columns where object_name(object_id) = 'test1'

/*step3 reproduce an unpivoted column*/
select * into dbo.test2
from (select * from dbo.test1) a unpivot (val for col in (col1,col2)) a


/*step4 lets check its collation you will see the column specified at "FOR" clause is created as Latin1_General_100_CI_AS_KS_WS_SC */
select name,collation_name from sys.columns where object_name(object_id) = 'test2'

/*step5 make use of the unpivoted table without awareness will cause an error*/
select val + ' = ' + col from dbo.test2 

/*step6 clean up*/
drop table dbo.test1
drop table dbo.test2

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