Zu verstehen, wie die Prinzipale in SQL Server?
Das klingt dumm, aber ich finde es wirklich verwirrend: in der MSDN ist die definition der Entität, kann SQL Server-Ressourcen anfordern. Und im Grunde gibt es drei Arten von Auftraggebern: Windows-Ebene Rektoren, die SQL Server-level-Prinzipien und Datenbank-Ebene-Prinzipien. So weit ist es in Ordnung. Nur, es gibt mir den Eindruck, dass die Kennung ein Rektor sollte anders sein als andere, egal, welche Art ist dieses Prinzip.(Wenn alle Prinzipien dieser drei Arten sein könnte, angeordnet in einem Tisch, Sie hätte unique identifiers)
Der verwirrende Teil kommt aus diesen drei Abfragen unter:
1)
Select name,principal_id from sys.database_principals
(Hinweis: ich betreibe es auf einer Datenbank)
2)
Select name,principal_id from sys.server_principals
Nun kenne ich die erste zurück-Datenbank Benutzer-Prinzipalen, während der zweite führt zu server-Benutzer-principals (korrigiert mich wenn ich falsch Liege). Aber warum eine Zeile aus der ersten Abfrage können die gleichen principal_id wie man es von der zweiten Abfrage? Zum Beispiel, eine Zeile aus der Datenbank principals wäre:
name:INFORMATION_SCHEMA, principal_id: 3
während eine Zeile von der zweiten Abfrage ist
name:sysadmin, principal_id: 3
Was sind diese zwei principal_id? Wie ich bereits erwähnt, ich dachte die Bezeichner der zwei Hauptpersonen anders sein würde, selbst dann, wenn man einen DB-Benutzer und andere server-Benutzer(und von den Namen ich nehme an, principal_id ist der Bezeichner).
Gut, wenn die principal_id ist nicht eindeutig für alle AUFTRAGGEBER, jedoch nur einmalig bei jedem query-Bereich(die principal_id aus der ersten Abfrage sind nur die Bezeichner für Datenbank-Benutzer, so dass es passieren kann, das gleiche zu sein wie man es von server-Benutzer), dann habe ich eine Dritte Abfrage, und nicht verstehen, was es bedeutet:
3)
SELECT
SDP.PRINCIPAL_ID AS [Principal ID],
SDP.NAME AS [Database UserName],
SDP.TYPE_DESC AS [Datebase UserType],
SSP.NAME AS [Server LoginName],
SSP.TYPE_DESC AS [Server LoginType]
FROM sys.database_principals SDP
INNER JOIN sys.server_principals SSP
ON SDP.PRINCIPAL_ID = SSP.PRINCIPAL_ID
Wenn die beiden principal_id sind nur eindeutig innerhalb Ihrer Reichweite, was bedeutet es, um ein inner join auf beide principal_id ? Ein inner join bedeutet, dass diese Spalte wird gemeinsam einzigartige, richtig?
Muss es etwas sehr elementares, dass ich missverstehen. Vielen Dank für jede Hilfe!
viele Artikel haben ähnlichen. Wie in diesem link: sql-server-performance.com/2009/...
und haben Sie gelesen, die einen Kommentar auf diesem Artikel - mit dem Hinweis darauf, dass der Beitritt auf principal_id ist falsch, und das SIDs sollte stattdessen verwendet werden?
verdammt, ich wollte nicht Lesen, weil ich hier hängengeblieben. Ich werde weiterhin... Danke für den Hinweis
InformationsquelleAutor tete | 2012-11-09
Du musst angemeldet sein, um einen Kommentar abzugeben.
Es gibt keine Korrespondenz zwischen
principal_id
s aufsys.database_principals
undsys.server_principals
. Auf den ersten, es ist nur dokumentiert innerhalb der Datenbank eindeutig sein. Auf dem zweiten, Sie sind eindeutig gegenüber dem server. Und es gibt keine dokumentierte Beziehung zwischen diesen Spalten in den gleichen Ansichten.In der Tat, die niedrigen zahlen
principal_id
s sind sehr wahrscheinlich zugeordnet werden, die in beiden Ansichten, und die Rektoren, dass Sie sich zu nichts.Damit die Abfrage zeigt einen join zwischen den beiden Ansichten mit
principal_id
ist falsch.Jedoch, obwohl ich mein login in server_principal Abfrage, gibt es keinen mit der gleichen sid in database_principal. So verlor ich meine Spur. Habe ich etwas falsch gemacht? Zum Beispiel habe ich die Berechtigung zur Anzeige aller database_principal? Mein login ist unter sysadmin-Serverrolle
wenn Sie ein Mitglied der
sysadmin
dann alle möglichen seltsamen Regeln kick in - Sie sind automatischdbo
in jeder Datenbank, ohne dass es irgendwelche Einträge indatabase_principals
zum Beispiel.Danke für deine Antwort. Dann werde ich den test durch die Schaffung einer normalen Anmeldung
InformationsquelleAutor Damien_The_Unbeliever