Was nützen SQL Server-Schemas?

Ich bin kein Anfänger in der Verwendung von SQL-Datenbanken und insbesondere von SQL Server. Ich war jedoch in erster Linie ein SQL 2000-Typ und 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 spezielle Schemas erstellen wollen? Warum sollte ich eines der integrierten Schemas zuweisen?

EDIT: Zur Verdeutlichung denke ich, ich suche nach den Vorteilen von Schemata. Wenn Sie es nur als Sicherheitsschema verwenden möchten, scheinen die Datenbankrollen diese Rolle bereits ausgefüllt zu haben. Und die Verwendung eines Namespace-Spezifizierers scheint etwas gewesen zu sein, das Sie mit dem Besitz hätten tun können (dbo versus Benutzer usw.).

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

Schemata gruppieren Tabellen, Prozeduren und Ansichten logisch zusammen. Alle mitarbeiterbezogenen Objekte im employeeSchema 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.

Genau wie der Namespace von C # -Codes.

Sie können auch eine Art Namenskollisionsschutz für Plugin-Daten bieten. Mit der neuen Funktion zum Ändern der Datenerfassung in SQL Server 2008 werden die verwendeten Tabellen beispielsweise in einem separaten CDC-Schema abgelegt. Auf diese Weise müssen sie sich keine Gedanken über einen Namenskonflikt zwischen einer CDC-Tabelle und einer in der Datenbank verwendeten realen Tabelle machen und können die Namen der realen Tabellen absichtlich schattieren.

Ich weiß, dass es ein alter Thread ist, aber ich habe mich selbst mit Schemas befasst und denke, dass Folgendes ein weiterer guter Kandidat für die Verwendung von Schemata sein könnte:

In einem Datawarehouse mit Daten aus verschiedenen Quellen können Sie für jede Quelle ein anderes Schema verwenden und dann z. B. den Zugriff basierend auf den Schemas steuern. Vermeidet auch die möglichen Namenskollisionen zwischen den verschiedenen Quellen, wie ein anderes Poster oben antwortete.

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 über eine Anwendung oder ein System verfügen, die / das groß genug ist, um unterschiedliche Funktionen zu haben.)

Stellen Sie sich als Beispiel ein System vor, 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 verknüpfen).

Ein Hinweis zur 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 Ihre Verbindungszeichenfolge, wenn Sie skalieren müssen.

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 ganz bestimmte Anwendungsfälle besonders nützlich. Macht die Dinge chaotisch. Verwenden Sie sie nicht, wenn Sie helfen können. Und versuchen Sie, die K (eep) I (t) S (imple) S (tupid) -Regel zu befolgen.

Ich sehe keinen Vorteil darin, Benutzer, die an Schemas gebunden sind, zu aliasen. Hier ist warum ....

Die meisten Benutzer verbinden ihre Benutzerkonten zunächst über Rollen mit Datenbanken. Sobald Sie einen Benutzer entweder dem Systemadministrator oder der Datenbankrolle db_owner in irgendeiner Form zuweisen, ist dieses Konto entweder dem Benutzerkonto "dbo" zugeordnet oder voll Berechtigungen für eine Datenbank. Sobald dies geschieht, werden diese DBO-Rechte unabhängig davon, wie Sie sich einem Schema zuweisen, das über Ihr Standardschema hinausgeht (das denselben Namen wie Ihr Benutzerkonto hat), dem Objekt zugewiesen, das Sie unter Ihrem Benutzer und Schema erstellen. Es ist irgendwie sinnlos ... und nur ein Namespace und verwirrt das wahre Eigentum an diesen Objekten. Es ist schlechtes Design, wenn Sie mich fragen ... wer auch immer es entworfen hat.

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

In einem ORACLE-Shop, in dem ich viele Jahre gearbeitet habe, wurden Schemata verwendet, um Prozeduren (und Pakete) zu kapseln, die für verschiedene Front-End-Anwendungen gelten. Ein anderes API-Schema für jede Anwendung war häufig sinnvoll, da die Anwendungsfälle, Benutzer und Systemanforderungen sehr unterschiedlich waren. Ein API-Schema bestand beispielsweise darin, dass eine Entwicklungs- / Konfigurationsanwendung nur von Entwicklern verwendet werden sollte. Ein weiteres API-Schema war der Zugriff auf die Clientdaten über Ansichten und Prozeduren (Suchen). Ein weiteres 'API'-Schema kapselte Code, der zum Synchronisieren von Entwicklungs- / Konfigurations- und Clientdaten mit einer Anwendung verwendet wurde, die über eine eigene Datenbank verfügte. Einige dieser 'API'-Schemata würden unter dem Deckmantel immer noch gemeinsame Prozeduren und Funktionen miteinander teilen (über andere' GEMEINSAME ').

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

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

Es sieht für mich so aus, als ob Schemata in etwa optionalen Namespaces entsprechen. Wenn Sie sich in einer Situation befinden, in der Objektnamen kollidieren und die Granularität der Berechtigungen nicht ausreicht, finden Sie hier ein Tool. (Ich würde gerne sagen, dass es möglicherweise Designprobleme gibt, die zuerst auf einer grundlegenderen Ebene behandelt werden sollten.)

Das Problem kann sein, dass einige Entwickler, wenn es vorhanden ist, es gelegentlich zum kurzfristigen Nutzen verwenden. und wenn es dort drin ist, kann es zu Kudzu werden.

In SQL Server 2000 wurden erstellte Objekte mit diesem bestimmten Benutzer verknüpft, z. B. wenn ein Benutzer, z. B. Sam, ein Objekt erstellt, z. B. Mitarbeiter, 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 Tabelle Sam.Employees passieren, sobald Sie den Benutzer Sam löschen? Wahrscheinlich müssten Sie zuerst den Besitz von Sam.Employees in dbo.Employess ändern. Schema bietet eine Lösung, um dieses Problem zu überwinden. Sam kann sein gesamtes Objekt 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. Selbst wenn das Benutzerkonto Sam gelöscht werden muss, ist das Schema nicht betroffen.

Entwicklung - Jeder unserer Entwickler erhält sein eigenes Schema als Sandbox zum Spielen.

Hier ein gutes Implementierungsbeispiel für die Verwendung von Schemas mit SQL Server. Wir hatten mehrere MS-Access-Anwendungen. Wir wollten diese in ein ASP.NET-App-Portal konvertieren. Jede MS-Access-Anwendung wird als App für dieses Portal geschrieben. Jede MS-Access-Anwendung verfügt über eigene Datenbanktabellen. Einige davon sind verwandt, wir fügen sie in das allgemeine dbo-Schema von SQL Server ein. 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 kann.