SQL 2008 R2 створює користувача / схему, коли користувач Windows створює таблиці

Ми додали користувача для входу в сервер та бази даних, який відображає групу Windows на екземпляр SQL 2008 R2, використовуючи наступний сценарій, імена змінені на анонімність:

USE master
go
CREATE LOGIN [DOMAIN\AppUsers] FROM WINDOWS
WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english]
go
USE AppDb
go
CREATE USER [DOMAIN\AppUsers] FOR LOGIN 
[DOMAIN\AppUsers]
go
EXEC sp_addrolemember N'db_owner', N'DOMAIN\AppUsers'
go

Коли обліковий запис DOMAIN \ User1 входить у додаток, User1 запитує таблиці в схемі dbo просто добре, оскільки User1 є членом DOMAIN \ AppUsers, але ця програма дозволяє користувачеві створювати і таблиці. Створюючи ці таблиці без вказівки схеми , SQL Server виконує такі дії:

1. Створює користувача "DOMAIN \ User1" в AppDb, який використовує вхід "DOMAIN \ User1", який не зазначений у SSMS \ Security \ Logins для цього примірника.
2. Створює схему 'DOMAIN \ User1' в AppDb.
3. Створює ці таблиці за допомогою нової схеми 'DOMAIN \ User1'.

Я цілком збентежений цими результатами. Ось мої запитання:

1. Я б очікував, що створення таблиці не вдасться, а не створить додаткові об'єкти. Чи може хтось вказати мені на частину Книг Інтернет, яка пояснює це?
2. Чому сервер не створює схему "DOMAIN \ AppUsers" і не додає нові таблиці до цієї схеми, якщо він збирається додавати схеми?
3. Крім того, як база даних використовує логін, не показаний у SSMS \ Security \ Logins?
4. Дивлячись на користувача "DOMAIN \ User1" у SSMS \ Бази даних \ AppDb \ Безпека \ Користувачі, піктограма користувача має маленьку червону стрілку, спрямовану вниз. Що це означає?

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

У випадку, якщо ви не можете сказати, я підштовхую до використання автентифікації Windows через автентифікацію SQL. Якщо ми не зрозуміємо це, ми повернемось до автентифікації SQL.

Так було завжди, повертаючись до SQL Server 2000.
Без схеми, як SQL Server знає, що ви хочете помістити його в dboсхему?

Єдиний спосіб вказати схему за замовчуванням - це:

• використовувати вхід у систему SQL (не для Windows)
• запустити як "sysadmin"

Жодне з них не є прийнятним

Найкраща практика - це завжди кваліфікувати схему для кожної посилання на об'єкт для DDL та DML. Є чіткі переваги від продуктивності через повторне використання плану.

Крім того, навмисне використання схеми краще для SQL Server 2005:

• таблиці в Data
• інші таблиці , в Archive, і Stagingт.д.
• код в схемах на повноваження клієнта: Desktop, і WebGUIт.д.

Використання схеми dbo - це минуле тисячоліття :-) Посилання:

• Дизайн схеми - найкращі практики?
• https://dba.stackexchange.com/q/7257/630

Ну @gbn набирає швидше, ніж я ...

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

Хоча запитання дуже старе і воно вже має прийняту відповідь, я спробую відповісти на ваші запитання конкретніше (а не давати загальні поради).

1. Поведінка задокументована у https://docs.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql , у розділі "Неявна схема та створення користувачів"

2. Якщо ви хочете, щоб об'єкти були створені в певній схемі (коли схема не вказана в заяві явно), вам слід вказати DEFAULT_SCHEMA для користувача. У SQL Server 2008 R2 (і більш ранніх версіях) ви отримаєте помилку, якщо спробуєте призначити DEFAULT_SCHEMA користувачеві на основі групи Windows, але в SQL Server 2012 (і пізніших версіях) це зараз можливо.

3. Це не відображається просто тому, що для цього користувача немає входу. Як зазначено в https://docs.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql , користувач може бути створений для тих, хто входить у систему, використовуючи іншу групу або навіть без будь-який логін.

4. Маленька червона стрілка (або маленька червона x у новіших версіях SSMS) представляє користувача, який не має дозволу CONNECT в базі даних (однак цей дозвіл може бути отриманий через іншу групу).

Хоча це старе питання, я спостерігав за такою поведінкою (у SQL Server 2014) і виявив наступне:

З огляду на сценарій

USE [master]
CREATE DATABASE [Test]

USE [Test]

-- Note that we create the users without specifying the default schema
CREATE USER [MyDomain\MyADGroup] FOR LOGIN [MyDomain\MyADGroup] -- ad group
CREATE USER [MyDomain\MyDomainUser] FOR LOGIN [MyDomain\MyDomainUser] -- ad user (not in said AD group)

ALTER ROLE db_ddladmin ADD MEMBER [MyDomain\MyADGroup]
ALTER ROLE db_ddladmin ADD MEMBER [MyDomain\MyDomainUser]

EXECUTE AS LOGIN = 'MyDomain\MyAdGroupUser' -- a windows account which is a member of [MyDomain\MyADGroup]

CREATE TABLE Test
(
    a INT
)

REVERT 

EXECUTE AS USER = 'MyDomain\MyDomainUser'

CREATE TABLE Test
(
    a INT
)

Цей скрипт створить дві таблиці під назвою Тест.

Перший CREATE TABLEстворює таблицю під назвою, [MyDomain\MyAdGroupUser].[Test]а також створює MyDomain\MyAdGroupUserсхему (а також MyDomain\MyAdGroupUserкористувач бази даних, який відключений)

другий CREATE TABLEстворює таблицю під назвою[dbo].[Test]

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

Оскільки ми не вказували схему за замовчуванням під час створення користувачів, SQL Server встановлює схему за замовчуванням користувача Windows як dbo, але НЕ встановлює жодної схеми за замовчуванням для користувача групи Windows, і тому це спричиняє створення схеми / створення користувача