次のスクリプトを使用して、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はDOMAIN\AppUsersのメンバーであるため、User1はdboスキーマのテーブルに問題なくクエリを実行しますが、このアプリではユーザーがテーブルを作成することもできます。これらのテーブルを作成するときスキーマを指定せずにの場合、SQL Serverは次のことを行います。
私はこれらの結果に完全に困惑しています。ここに私の質問があります:
単純化のためにSQL認証を好む組織内でWindows認証を使用し始めたばかりなので、私の質問は違いを知らないことに由来していると思います。このコードは、Windows認証の使用を検討するずっと前に作成されたものであるため、データベース所有者以外のユーザーとしてWindows認証を使用してログオンした場合の新しいスキーマの作成に関する理解を深める必要があります。
わかりにくいかもしれませんが、私はSQL認証よりもWindows認証の使用を強く求めています。これについてしっかりと理解できなければ、SQL認証に戻ります。
SQL Server 2000に戻って、これは常に起こりました。
スキーマがない場合、SQL Serverは、スキーマをdbo
スキーマに配置することをどのようにして認識しますか?
デフォルトのスキーマを指定する唯一の方法は、次のとおりです。
これらはどちらも受け入れられません
ベストプラクティスは、DDLおよびDMLのすべてのオブジェクト参照のスキーマを常に修飾することです。計画を再利用することで、明らかにパフォーマンス上の利点があります。
また、SQL Server 2005では、意図的なスキーマの使用がより適切です。
Data
のテーブルArchive
、Staging
などの他のテーブルDesktop
、WebGUI
などDboスキーマの使用はso最後のミレニアムです:-)リンク:
質問は非常に古く、すでに受け入れられた回答がありますが、私は(一般的なアドバイスを与えるのではなく)より具体的に質問に回答するように努めます。
動作は https://docs.Microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql の「暗黙的なスキーマとユーザー」セクションに記載されています。創造」
オブジェクトを特定のスキーマで作成する場合(ステートメントでスキーマが明示的に指定されていない場合)、ユーザーにDEFAULT_SCHEMAを指定する必要があります。 SQL Server 2008 R2(およびそれ以前のバージョン)では、DEFAULT_SCHEMAをWindowsグループに基づいてユーザーに割り当てようとするとエラーが発生しましたが、SQL Server 2012(およびそれ以降のバージョン)では、これが可能になりました。
そのユーザーのログインがないため、表示されません。 https://docs.Microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql で指定されているように、ログインしたユーザーのためにユーザーが作成される場合があります別のグループを使用するか、ログインなしでも使用できます。
小さな赤い矢印(またはSSMSの新しいバージョンでは小さな赤いx)は、データベースにCONNECT権限がないユーザーを表します(ただし、この権限は別のグループを通じて取得される場合があります)。
ええと @ gbn タイプよりもタイプが速い...
私の唯一の提供は...ユーザーがアプリにログインしていることを参照し、itを使用して、ユーザーがテーブルなどを作成できるようにします。アプリケーションがこれを許可し、ユーザーがSQL Server自体を介してこれを行わない場合(SSMSを使用してデータベースに直接ログイン)、そのアプリケーションのベンダーに確認する必要があります。
これは古い質問ですが、(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
)
このスクリプトは、Testという2つのテーブルを作成します。
最初のCREATE TABLE
は[MyDomain\MyAdGroupUser].[Test]
というテーブルを作成し、MyDomain\MyAdGroupUser
スキーマも作成します(無効になっているMyDomain\MyAdGroupUser
データベースユーザーも同様です)。
2番目のCREATE TABLE
は[dbo].[Test]
というテーブルを作成します
これは、CREATE TABLE
コマンドではスキーマが明示的に指定されていないため、デフォルトのスキーマが使用されるためです。
ユーザーの作成時にデフォルトスキーマを指定しなかったため、SQL ServerはWindowsユーザーのデフォルトスキーマをdboとして設定しますが、Windowsグループユーザーにはデフォルトスキーマを設定しないため、これによりスキーマ/ユーザーが作成されます