Schema, Besitzer für Objekte in MS SQL

Question

Standardmäßig werden Objekte (Tabellen, gespeicherte Prozeduren usw.) mit dem dbo Besitzer/Schema eingerichtet (ich denke, ms sql 2000 nennt es Besitzer, während ms sql 2005 es Schema aufruft)

Der Besitzer/das Schema ist wirklich eine Rolle oder ein Benutzer in der Datenbank. Ich habe immer die Standardeinstellung von dbo verlassen, aber ich habe kürzlich einige Beispiele in Microsoft-Trainingsbüchern gesehen, wo einige ihrer gespeicherten Prozeduren unterschiedliche Eigentümer/Schemas hatten. Wann ist es sinnvoll dies zu tun und warum?

Answer 1

Die Verwendung von Schemas ist besonders vorteilhaft, wenn Sie Sicherheitsbedenken haben.

Wenn mehrere Anwendungen auf die Datenbank zugreifen, möchten Sie möglicherweise der Logistikabteilung keinen Zugriff auf Personalakten gewähren. Sie legen also alle Ihre HR-Tabellen in ein hr-Schema und erlauben nur den Zugriff für Benutzer in der HR-Rolle.

Sechs Monate später muss die Logistik nun interne Spesenkonten kennen, damit sie alle diese Paletten blauer Stifte an die richtigen Personen senden können. Sie können dann eine gespeicherte Prozedur erstellen, die als Benutzer mit der Berechtigung zum Anzeigen des hr-Schemas und des Logistikschemas ausgeführt wird. Die Logistics-Benutzer müssen nie wissen, was im HR vor sich geht, und dennoch erhalten sie ihre Daten.

Sie können Schemas auch wie von cfeduke vorgeschlagen verwenden und einfach dazu verwenden, Dinge im Objektbrowser zu gruppieren. Wenn Sie dies tun, seien Sie nur vorsichtig, weil Sie am Ende Person.Address und Company.Address erstellen können, wenn Sie wirklich nur eine einzige dbo.Address benötigen (ich klopfe nicht an Ihr Beispiel, cfeduke, benutze es nur, um beides zu illustrieren Adresstabellen können gleich sein oder sie könnten anders sein und YMMV).

Answer 2

Organisation

In einer Entwickler-Umgebung ist die Produktion Kopie der Objekte dbo aber die Entwickler in ihrem eigenen Schema entwickeln. Dann kann der Code auf die Produktkopie oder ihre Änderungen sehr einfach Bezug nehmen. Die Verwendung von Aliasen kann diese Technik noch einfacher machen.

---

Auch eine Produktionsdatenbank kann zahlreiche Systeme oder Subsysteme unterstützen. Sie können unterschiedliche Schemas verwenden, um diese Objekte gruppiert zu halten.

Answer 3

In SQL 2000 entsprechen die Schemas den Datenbankbenutzern, in SQL 2005 ist jedes Schema ein eindeutiger Namespace, der unabhängig vom Datenbankbenutzer existiert, der es erstellt hat.

Ich benutze Schemata, wenn ich Features oder Module erstellen muss, die später in anderen Projekten verwendet werden, so dass ich die Datenbankobjekte isolieren kann, die vom Modul verwendet werden.

Answer 4

Ich habe Schemas in der Vergangenheit wie Namespaces verwendet, so dass Sie mehrere Entities namens Adresse ([Person].[Address], [Company].[Address]) haben könnten. Der Vorteil besteht in der visuellen Organisation in SQL Management Studio. Sie können dasselbe erreichen, indem Sie alles unter ein Schema setzen und Tabellen mit einem einzigen Bezeichner benennen (z. B. [dbo].[PersonAddress]).

Ich habe sie auch für die Entwicklung von Entwicklern vs. Entwicklern verwendet, bevor ich die SQL Server Developer Edition auf allen unseren Dev-Maschinen ausführte (damals, als wir früher in meiner Karriere eine zentralisierte Entwicklungsdatenbank hatten).

Answer 5

This article erklärt es gut, einschließlich der Änderungen von SQL Server 2000 bis 2005.