Есть ли недостатки в базах данных?

В 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

При запуске ALTER DATABASEкоманды из контекста отдельной базы данных, вместо того, чтобы ALTER DATABASE fooвам нужно было использовать ALTER DATABASE CURRENT- это так, что если база данных перемещена, переименована и т. Д., Эти команды не должны ничего знать об их внешнем контексте или ссылке ,

Несколько других

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

• пронумерованные процедуры
• временные процедуры
• изменения сопоставления в связанных объектах
• изменить сбор данных
• отслеживание изменений
• копирование

Тем не менее, это не обязательно недостатки использования автономных баз данных, это просто проблемы, о которых вам следует знать, и не все они явно раскрыты в официальной документации.

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

Вы можете найти этот пост полезным, как и этот , даже если они предшествуют RTM.

Для тех, кто заинтересован в получении более подробной информации о базах данных, я могу порекомендовать им прочитать эту статью http://www.sqlshack.com/contained-databases-in-sql-server/

В статье указаны основные преимущества / недостатки использования автономных баз данных.

Недостатки

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

преимущества

С другой стороны, как уже упоминалось, есть несколько преимуществ использования отдельных БД, таких как:

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

Статья также помогает с:

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

Одним из недостатков является то, что пользователь автономной базы данных не может быть вынужден изменить свой собственный пароль, как могли бы логины ( MUST_CHANGE). Пользователи не могут управлять своим собственным паролем, если вы не предоставите им разрешение на изменение пользователя и не скажете, как его изменить, используя оператор SQL. Им нигде не легко управлять им через пользовательские интерфейсы или, по крайней мере, я не знаю как.

Дополнительным примечанием является то, что я обнаружил неожиданное и недокументированное использование метаданных в предложении «PIVOT» И «UNPIVOT», которое, как мне показалось, должно быть только в системном каталоге (sys.tables / sys.columns / etc). Как задокументировано в 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

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