SQL Server MERGE + Eintritt in die anderen Tabellen

Ich bin mit der MERGE-Anweisung innerhalb einer Datenbank-Projekt zu füllen Referenz-Daten aus einer statischen Wert festgelegt, wie die folgenden beschrieben:

    MERGE INTO dbo.[User] AS TARGET
USING (VALUES
    ('[email protected]', 'My Name'))
AS SOURCE(UserName, FullName)
ON SOURCE.UserName = TARGET.UserName
WHEN NOT MATCHED BY TARGET THEN
    INSERT (UserId, UserName, FullName)
    VALUES (NEWID(), UserName, FullName);

Das problem kommt, wenn ich wollen, füllen Sie die sekundäre Tabelle anhand der Inhalte in anderen Tabellen. Zum Beispiel, mein UserPermission Tabelle enthält die Benutzer-ID und Rollen-ID und ich möchte meine statische Wert legen auf etwas wie ('[email protected]', 'Admin') und in der Lage sein zu verbinden, um Benutzer und Berechtigung, um die ID-Werte für Einsetzen. Nicht sicher, wo Sie tun, dass...

Edit:

Tabelle User(ID, Benutzername)
1, John Smith
2, Mark Wahlerg

Rolle Tabelle(ID, RoleName)
1, Administrator
2, Benutzer
3, Gast

Benutzer-Rolle-Tabelle (User-ID, Rollen-ID)

Ich will, das SQL für die MERGE-Anweisung zum einstellen der Benutzer-Rolle-Tabelle, so dass ich tun kann, geben Sie etwas wie:

USING(VALUES
 ('John Smith', 'Administrator'),
 ('Mark Wahlburg', 'User')

und es zu verbinden, um bestimmen Sie die IDs, legen Sie die Kombinationen, die nicht existiert (und vielleicht löschen Sie diejenigen, die das tun, sich aber nicht in den SERIENDRUCK.

Lösung:

WITH CTE AS
(
   SELECT UserId, RoleId
   FROM (VALUES
      ('John Smith', 'Administrator'),
      ('Mark Wahlburg', 'User'))
      AS SOURCE(UserName, RoleName)
   INNER JOIN User ON SOURCE.UserName = User.UserName
   INNER JOIN Role ON SOURCE.RoleName = Role.RoleName
)
MERGE INTO UserRole AS TARGET
USING CTE
ON CTE.UserId = TARGET.UserID AND CTE.RoleId = TARGET.UserId
WHEN NOT MATCHED BY TARGET THEN
  INSERT(UserId, RoleId)
  VALUES(UserId, RoleId)
  • Einfach nur neugierig, warum verwenden Sie hier MERGE anstatt eine viel einfachere INSERT ... SELECT? Ich sage nicht, dass du es nicht mit MERGE aber es scheint übertrieben für so eine triviale operation.
  • dies ist ein einfaches Beispiel, normalerweise habe ich mehrere Zeilen und verwenden Sie die UPDATE-und DELETE-capabiltities ZUSAMMENFÜHREN. Ich habe versucht, das problem zu isolieren.
  • Das problem ist in Ihrem USING - Klausel. Sie müssen nur hart codierte Werte; Sie brauchen es, um tatsächlich eine SELECT wenn Sie zeichnen müssen diese Werte aus einer Tabelle. Auch gibt es einige ziemlich schlaue Leute, die helfen können, Ihre Probleme zu lösen, aber Sie sind viel mehr daran interessiert, bei der Lösung Ihres eigentlichen Problems - Niveau herunterzuschrauben führt nur zu unnötigen Fragen wie die, die ich gefragt habe.
  • Ich kann nicht einen Grund sehen, nicht ändern Sie den Einsatz durch das entfernen der 'Werte ( ... )" - Zeile zu einem 'select', in dem Sie Ihre statische Felder und auch Verknüpfungen zu anderen Tabellen zum nachschlagen der entsprechenden id.
  • Diese Werte gemeint sind hart codiert, aber das problem ist, ich will nicht zu legen Sie die spezifischen Werte, sondern IDs aus anderen Tabellen basierend auf dem hart-kodierte Werte. Das ist nur ein Beispiel, dass funktioniert jetzt. Das problem ist der nächste Schritt, das ist das problem beschrieben, danach.
  • Die ID-Felder bekannt sein muss vor der INSERT -, für die ON-Klausel verwenden Sie die SERIENDRUCK-Quelle und-Ziel zu ermitteln, ob die ZUSAMMENFÜHREN soll, zu aktualisieren, einfügen oder löschen.
  • Sie brauchen, um besser festzulegen, welche sind die hartcodierte Werte, die Sie verwenden möchten, und welches sind die hartcodierte Werte, die Sie nicht verwenden möchten. Können Sie zeigen einige der tatsächlichen sample-Daten vor dem und nach und wie die Sie möchten den Seriendruck tatsächlich auf die Daten auswirken? Versuchen Sie, stellen Sie alle Werte in die Benutzernamen-Tabelle, oder spezifisch? Wenn bestimmte, sind, wie Sie angeben? Details, details, details.
  • Kann ein user angehören, mehr als eine Rolle?

InformationsquelleAutor Rich | 2012-05-09
Schreibe einen Kommentar