wake-up-neo.com

Was nützen SQL Server-Schemata?

Ich bin kein Anfänger in der Verwendung von SQL-Datenbanken und insbesondere von SQL Server. Allerdings war ich in erster Linie ein SQL 2000-Typ und ich war 2005+ immer durch Schemata verwirrt. Ja, ich kenne die grundlegende Definition eines Schemas, aber wofür werden sie in einer typischen SQL Server-Bereitstellung wirklich verwendet?

Ich habe immer nur das Standardschema verwendet. Warum sollte ich spezialisierte Schemata erstellen wollen? Warum sollte ich eines der integrierten Schemas zuweisen?

EDIT: Zur Verdeutlichung schätze ich, ich suche nach den Vorteilen von Schemata. Wenn Sie es nur als Sicherheitsschema verwenden, scheint es, als wären die Datenbankrollen bereits mit dieser Rolle besetzt. Und die Verwendung von a als Namespace-Spezifizierer scheint etwas gewesen zu sein, das Sie mit Ownership hätten tun können (dbo versus user, etc ..).

Ich denke, was ich vorhabe ist, was machen Schemas, was Sie mit Eigentümern und Rollen nicht machen können? Was sind ihre spezifischen Vorteile?

179

Schemata gruppieren Tabellen, Prozeduren und Ansichten logisch. Alle mitarbeiterbezogenen Objekte im Schema employee usw.

Sie können auch nur einem Schema Berechtigungen erteilen, sodass Benutzer nur das Schema sehen können, auf das sie Zugriff haben, und sonst nichts.

155
SQLMenace

Genau wie der Namespace von C # -Codes.

30
airbai

Sie können auch eine Art Namenskollisionsschutz für Plug-in-Daten bereitstellen. Das neue Feature "Datenerfassung ändern" in SQL Server 2008 legt die verwendeten Tabellen beispielsweise in einem separaten CDC-Schema ab. Auf diese Weise müssen sie sich nicht um einen Namenskonflikt zwischen einer CDC-Tabelle und einer in der Datenbank verwendeten realen Tabelle kümmern und können die Namen der realen Tabellen absichtlich spiegeln.

29
Joel Coehoorn

Ich weiß, dass es sich um einen alten Thread handelt, habe mich aber selbst mit Schemas befasst und denke, dass Folgendes ein weiterer guter Kandidat für die Verwendung von Schemas sein könnte:

In einem Datawarehouse können Sie mit Daten aus verschiedenen Quellen für jede Quelle ein anderes Schema verwenden und dann z. Steuern Sie den Zugriff anhand der Schemas. Vermeidet auch die möglichen Namenskollisionen zwischen den verschiedenen Quellen, wie ein anderes Plakat oben geantwortet hat.

16
tobi18

Wenn Sie Ihr Schema diskret halten, können Sie eine Anwendung skalieren, indem Sie ein bestimmtes Schema auf einem neuen DB-Server bereitstellen. (Dies setzt voraus, dass Sie eine Anwendung oder ein System haben, die bzw. das groß genug ist, um unterschiedliche Funktionen zu haben).

Ein Beispiel ist ein System, das die Protokollierung durchführt. Alle Protokollierungstabellen und SPs befinden sich im Schema [Protokollierung]. Die Protokollierung ist ein gutes Beispiel, da es selten (wenn überhaupt) vorkommt, dass andere Funktionen im System Objekte im Protokollierungsschema überlappen (dh mit diesen verknüpft werden).

Ein Tipp für die Verwendung dieser Technik: Verwenden Sie für jedes Schema in Ihrer Anwendung/Ihrem System eine andere Verbindungszeichenfolge. Anschließend stellen Sie die Schemaelemente auf einem neuen Server bereit und ändern die Verbindungszeichenfolge, wenn Sie skalieren müssen.

9
Hogan

Ich stimme Brent in diesem Punkt eher zu ... siehe diese Diskussion hier. http://www.brentozar.com/archive/2010/05/why-use-schemas/

Kurz gesagt ... Schemata sind nur für sehr spezielle Anwendungsfälle von großem Nutzen. Macht die Dinge unordentlich. Verwenden Sie sie nicht, wenn Sie helfen können. Und versuche, dem zu gehorchen K(eep) I(t) S(imple) S(tupid) Regel.

8
sam yi

In einem Oracle-Shop, in dem ich viele Jahre gearbeitet habe, wurden Schemata verwendet, um Prozeduren (und Pakete) zu kapseln, die auf verschiedene Front-End-Anwendungen angewendet wurden. Ein anderes 'API'-Schema für jede Anwendung war oft sinnvoll, da die Anwendungsfälle, Benutzer und Systemanforderungen sehr unterschiedlich waren. Beispielsweise war ein 'API'-Schema für eine Entwicklungs-/Konfigurationsanwendung vorgesehen, die nur von Entwicklern verwendet werden sollte. Ein weiteres 'API'-Schema war der Zugriff auf die Client-Daten über Ansichten und Prozeduren (Suchen). Ein anderes 'API'-Schema kapselte Code ein, der zum Synchronisieren von Entwicklungs-/Konfigurations- und Clientdaten mit einer Anwendung mit einer eigenen Datenbank verwendet wurde. Einige dieser 'API'-Schemata teilen sich unter dem Deckmantel immer noch gemeinsame Prozeduren und Funktionen (über andere' GEMEINSAME'-Schemata), wenn dies sinnvoll war.

Ich werde sagen, dass es wahrscheinlich nicht das Ende der Welt ist, kein Schema zu haben, obwohl es sehr hilfreich sein kann. Eigentlich ist es das Fehlen von Paketen in SQL Server, das wirklich Probleme in meinem Kopf verursacht ... aber das ist ein anderes Thema.

7
L. L. Learner

Ich sehe keinen Vorteil darin, an Schemas gebundene Benutzer auszublenden. Hier ist warum ....

Die meisten Benutzer verbinden ihre Benutzerkonten zunächst über Rollen mit Datenbanken. Sobald Sie einen Benutzer entweder dem Sysadmin oder der Datenbankrolle db_owner in irgendeiner Form zuweisen, ist dieses Konto entweder mit dem Benutzerkonto "dbo" verknüpft oder voll Berechtigungen für eine Datenbank. Unabhängig davon, wie Sie sich einem Schema außerhalb Ihres Standardschemas zuweisen (das denselben Namen wie Ihr Benutzerkonto hat), werden diese DBO-Rechte dem Objekt zugewiesen, das Sie unter Ihrem Benutzer und Schema erstellt haben. Es ist irgendwie sinnlos ..... und nur ein Namespace und verwirrt das wahre Eigentum an diesen Objekten. Sein schlechtes Design, wenn Sie mich fragen ... wen auch immer es entworfen hat.

Was sie hätten tun sollen, ist, "Gruppen" zu erstellen, Schemata und Rollen zu löschen und es Ihnen einfach zu ermöglichen, Gruppen von Gruppen in einer beliebigen Kombination einzuteilen. Dann teilen Sie dem System auf jeder Ebene mit, ob Berechtigungen vererbt, verweigert oder mit benutzerdefinierten Berechtigungen überschrieben wurden Einsen. Dies wäre so viel intuitiver gewesen und hätte es DBAs ermöglicht, besser zu kontrollieren, wer die wirklichen Eigentümer dieser Objekte sind. Momentan impliziert dies in den meisten Fällen, dass der SQL Server-Standardbenutzer von dbo diese Rechte besitzt, nicht der Benutzer.

7
stormy

Ich denke, Schemata sind wie viele neue Funktionen (egal ob für SQL Server oder ein anderes Software-Tool). Sie müssen sorgfältig abwägen, ob der Vorteil des Hinzufügens zu Ihrem Development Kit den Verlust an Einfachheit bei Design und Implementierung ausgleicht.

Es sieht für mich so aus, als ob Schemata ungefähr den optionalen Namespaces entsprechen. Wenn Sie in einer Situation sind, in der Objektnamen kollidieren und die Granularität der Berechtigungen nicht ausreicht, finden Sie hier ein Tool. (Ich würde sagen, dass es Designprobleme geben könnte, die zuerst auf einer grundlegenderen Ebene behandelt werden sollten.)

Das Problem kann sein, dass einige Entwickler es gelegentlich verwenden, um kurzfristigen Nutzen daraus zu ziehen. und sobald es dort ist, kann es kudzu werden.

5
dkretz

In SQL Server 2000 wurden erstellte Objekte mit diesem bestimmten Benutzer verknüpft. Wenn ein Benutzer beispielsweise Sam ein Objekt erstellt, z. B. Employees, sieht diese Tabelle folgendermaßen aus: Sam.Employees. Was ist, wenn Sam das Unternehmen verlässt oder in einen anderen Geschäftsbereich zieht? Was würde mit der Sam.Employees-Tabelle passieren, sobald Sie den Benutzer Sam löschen? Wahrscheinlich müssten Sie zuerst den Eigentümer von Sam.Employees in dbo.Employess ändern. Schema bietet eine Lösung, um dieses Problem zu überwinden. Sam kann alle seine Objekte in einem Schema wie Emp_Schema erstellen. Wenn er nun ein Objekt Employees in Emp_Schema erstellt, wird das Objekt als Emp_Schema.Employees bezeichnet. Auch wenn das Benutzerkonto Sam gelöscht werden muss, ist das Schema nicht betroffen.

3
Tariq Awan

entwicklung - Jeder unserer Entwickler bekommt sein eigenes Schema als Sandbox zum Spielen.

0
Nick Van Brunt

Hier ein gutes Implementierungsbeispiel für die Verwendung von Schemata mit SQL Server. Wir hatten mehrere MS-Access-Anwendungen. Wir wollten diese in ein ASP.NET-App-Portal konvertieren. Jede Anwendung von ms-access ist als App für dieses Portal geschrieben. Jede MS-Access-Anwendung verfügt über eigene Datenbanktabellen. Einige davon hängen zusammen, wir fügen sie dem allgemeinen Dbo-Schema von SQL Server hinzu. Der Rest bekommt seine eigenen Schemata. Auf diese Weise möchten wir wissen, welche Tabellen zu einer App im ASP.NET-App-Portal gehören, die einfach navigiert, visualisiert und verwaltet werden können.

0