MSSQL Selektieren einer bestimmten Zeile
Ich möchte Daten in einer Datenbanktabelle mit Daten aus einer anderen Personen-Tabelle updaten.
Problem ist, dass ich bestimmte Zeilen selektieren muss.
Situation:
Tabelle-B
ID
NAME1
NAME2
NAME3
Tabelle-A
ID
B_ID
NAME
VORNAME
Tabelle B soll mit den Personendaten (Name, Vorname) aus Tabelle A befüllt werden. Über eine ID ist eine Zuordnung der Datensätze möglich.
Allen Datensätze haben 1 bis maximal 3 Personen.
1. Person soll in Feld NAME1 (Tabelle-B)
2. Person soll in Feld NAME2 (Tabelle-B)
3. Person soll in Feld NAME3 (Tabelle-B)
Die 1. Person konnte ich bereits mit TOP (1) herausfiltern und zuordnen:
UPDATE Tabelle-B
SET [Name1] = (
Select TOP (1) NAME + ', ' + VORNAME
FROM Tabelle-A
WHERE Tabelle-B.ID= Tabelle-A.B_ID
ORDER BY Tabelle-A.NAME
)
Wie kann ich die 2. und 3. Person filtern ? (würde der 2. Zeile des Select entsprechen, bzw. der 3. Zeile)
Problem ist, dass ich bestimmte Zeilen selektieren muss.
Situation:
Tabelle-B
ID
NAME1
NAME2
NAME3
Tabelle-A
ID
B_ID
NAME
VORNAME
Tabelle B soll mit den Personendaten (Name, Vorname) aus Tabelle A befüllt werden. Über eine ID ist eine Zuordnung der Datensätze möglich.
Allen Datensätze haben 1 bis maximal 3 Personen.
1. Person soll in Feld NAME1 (Tabelle-B)
2. Person soll in Feld NAME2 (Tabelle-B)
3. Person soll in Feld NAME3 (Tabelle-B)
Die 1. Person konnte ich bereits mit TOP (1) herausfiltern und zuordnen:
UPDATE Tabelle-B
SET [Name1] = (
Select TOP (1) NAME + ', ' + VORNAME
FROM Tabelle-A
WHERE Tabelle-B.ID= Tabelle-A.B_ID
ORDER BY Tabelle-A.NAME
)
Wie kann ich die 2. und 3. Person filtern ? (würde der 2. Zeile des Select entsprechen, bzw. der 3. Zeile)
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 172374
Url: https://administrator.de/contentid/172374
Ausgedruckt am: 22.11.2024 um 15:11 Uhr
11 Kommentare
Neuester Kommentar
Moin dunvegane,
Selbst MSSQL bietet dafür die Möglichkeiten mit Konstrukten über ROW_NUMBER() oder auch ROW_NUMBER() OVER(ORDER BY id).
Die eigentliche Schwierigkeit in deiner verquasten Situation ist eine andere.
In deinem TOP(1) UPDATE-Statement-Beispiel bist du fein raus. Jeder Satz, der überhaupt mit diesem UPDATE-Statement angefasst wird, bekommt auch einen Wert in das Feld NAME1. Nix kann schiefgehen.
Beim Ermitteln der UPDATE-Werte für NAME2 und NAME3 mit der Strategie "Schreib da den zweiten (bzw. dritten) gefundenen Datensatz rein" geht es in die Grütze, wenn es keinen zweiten oder dritten Datensatz gibt.
Somit wäre vorab zu klären:
Zusatzverständnis-Fragen:
Grüße
Biber
Zitat von @dunvegane:
Ich hatte gehofft dass es eine Möglichkeit gibt eine bestimmte Zeile auszulesen.
Dürfte doch eine sehr häufige Anwendung sein.
Ja, schon.Ich hatte gehofft dass es eine Möglichkeit gibt eine bestimmte Zeile auszulesen.
Dürfte doch eine sehr häufige Anwendung sein.
Selbst MSSQL bietet dafür die Möglichkeiten mit Konstrukten über ROW_NUMBER() oder auch ROW_NUMBER() OVER(ORDER BY id).
Die eigentliche Schwierigkeit in deiner verquasten Situation ist eine andere.
In deinem TOP(1) UPDATE-Statement-Beispiel bist du fein raus. Jeder Satz, der überhaupt mit diesem UPDATE-Statement angefasst wird, bekommt auch einen Wert in das Feld NAME1. Nix kann schiefgehen.
Beim Ermitteln der UPDATE-Werte für NAME2 und NAME3 mit der Strategie "Schreib da den zweiten (bzw. dritten) gefundenen Datensatz rein" geht es in die Grütze, wenn es keinen zweiten oder dritten Datensatz gibt.
Somit wäre vorab zu klären:
- Gibt es denn für alle upzudatenden Sätze auch (mindestens) 3 Sätze in der TabelleA?
- oder sollen nur alle Sätze upgedatet werden, für die es genau 3 Sätze in TabelleA gibt?
- oder sind die Datenfelder NAME2 und NAME3 wirklich NULLABLE/optional - dann wären unter Umständen 3 Update-Statements sinnvoller. Eines für den Fall, dass nur ein Datensatz in TabelleA vorliegt, ein Statement für den Fall "zwei Datensaätze" und eines für den Fall "mindestens drei Datensätze".
Zusatzverständnis-Fragen:
- wenn mehr als 3 Datensätze in TabelleA vorliegen, dann landen "nur" die alphabetisch sortierten ersten drei als NAME1, NAME2, NAME3 im Ziel?? Ist dir bewusst und so gewollt?
- das bisherige TabelleA-Feld "ID" wird stillschweigen weggeworfen - wird nie wieder gebraucht? keine Constraints oder Child-Datensätze, die davon abhängen?
Grüße
Biber
Das ganze sollte mit einer Schleife funktionieren.
Erst werden die Grunddaten mit den zu updatenden Daten gejoint und dann wird die Tabelle upgedatet.
Durch eine Nummerierung innerhalb der Gruppe (B_ID) wird dann bestimmt, welche Spalte upgedatet wird. Das ganze kann man auch mit dynamischen SQL machen, dann spart man sich die Wiederholung der Update-Statements.
Mangels MS-SQL mal die Oracle-Syntax dazu. Sicherlich kann das MS-SQL auch.. eventuell kann das ja einer "übersetzen"
Dabei ist es auch egal, ob es immer drei Namen gibt oder nicht.. nur mehr wären bei diesem Beispiel schlecht, aber selbst das bekommt man bei Bedarf noch in den Griff.
so long,
pi
Erst werden die Grunddaten mit den zu updatenden Daten gejoint und dann wird die Tabelle upgedatet.
Durch eine Nummerierung innerhalb der Gruppe (B_ID) wird dann bestimmt, welche Spalte upgedatet wird. Das ganze kann man auch mit dynamischen SQL machen, dann spart man sich die Wiederholung der Update-Statements.
Mangels MS-SQL mal die Oracle-Syntax dazu. Sicherlich kann das MS-SQL auch.. eventuell kann das ja einer "übersetzen"
Dabei ist es auch egal, ob es immer drei Namen gibt oder nicht.. nur mehr wären bei diesem Beispiel schlecht, aber selbst das bekommt man bei Bedarf noch in den Griff.
begin
for rec in (select b.id as theUpdateID, a.name, a.vorname, count(*) over( partition by a.b_id order by b.id Rows Unbounded Preceding ) as rn
from test_b b
join test_a a on (a.b_id = b.id)
order by b.id) loop
if rec.rn = 1 then
update test_b set name1 = rec.vorname || ' ' || rec.name where id = rec.theUpdateID;
end if;
if rec.rn = 2 then
update test_b set name2 = rec.vorname || ' ' || rec.name where id = rec.theUpdateID;
end if;
if rec.rn = 3 then
update test_b set name3 = rec.vorname || ' ' || rec.name where id = rec.theUpdateID;
end if;
end loop;
end;
/
so long,
pi
Als "Weiterbildungsmaßnahme" hab' ich mir das mal in TSQL geschrieben.. und es geht
declare updCursor Cursor for
select b.id as theUpdateID
, a.name, a.vorname
, ROW_NUMBER() over( partition by a.b_id order by a.id) as rn
from tab_b b
left join tab_a a on (a.b_id = b.id)
order by a.b_id;
declare @updID VarChar( 30 );
declare @name VarChar( 30 );
declare @vorname VarChar( 30 );
declare @rn VarChar( 3 );
open updCursor;
fetch next from updCursor into @updID, @name, @vorname, @rn;
while @@FETCH_STATUS = 0
begin
declare @stmt NVarChar( max );
set @stmt = 'update tab_b set name' + @rn + ' = ''' + @vorname + ' ' + @name + ''' where id = ' + @updID;
print @stmt;
exec sp_executesql @stmt;
fetch next from updCursor into @updID, @name, @vorname, @rn;
end;
close updCursor;
deallocate updCursor;
Moin pi314,
nur als Anmerkung....
Schöne Arbeit. und auch keine Zweifel, dass es geht.
Allerdings - die Deklaration (und auch Verwendung) von @updid und @rn als varChar()-Typen finde ich schon etwas brutal.
Denn eigentlich werden die beide nicht in der Zeile 01 bzw. 21 als String, sondern als numerische Werte angefordert/duchgefetched.
In diesem Paar-Zeilen-Statement mag man/frau das ja noch im Auge und/oder im Hinterkopf behalten können.
In einem "längeren" und "produktiven" Schnipsel ist eine solche (kommentarlose) Aktion möglicherweise ein Anlass zu langwieriger Fehlersuche.
Eine so genannte "Sollbruchstelle" eben
Grüße
Biber
nur als Anmerkung....
Schöne Arbeit. und auch keine Zweifel, dass es geht.
Allerdings - die Deklaration (und auch Verwendung) von @updid und @rn als varChar()-Typen finde ich schon etwas brutal.
Denn eigentlich werden die beide nicht in der Zeile 01 bzw. 21 als String, sondern als numerische Werte angefordert/duchgefetched.
In diesem Paar-Zeilen-Statement mag man/frau das ja noch im Auge und/oder im Hinterkopf behalten können.
In einem "längeren" und "produktiven" Schnipsel ist eine solche (kommentarlose) Aktion möglicherweise ein Anlass zu langwieriger Fehlersuche.
Eine so genannte "Sollbruchstelle" eben
Grüße
Biber
Ja Biber, da gebe ich dir recht
Sie sollten als Number deklariert sein und dann gecastet werden.
Hatte ich auch erst anders geschrieben, dann aus irgendwelchen Fehlergründen umgewandelt (irgendwas hat nicht geklappt und dann hab ich etwas rumprobiert..)
Das bringt mich zu einer Frage:
Kann man in T-SQL auch Variablen anhand von Spaltendefinitionen deklarieren?
So wie bei PL/SQL:
Sie sollten als Number deklariert sein und dann gecastet werden.
Hatte ich auch erst anders geschrieben, dann aus irgendwelchen Fehlergründen umgewandelt (irgendwas hat nicht geklappt und dann hab ich etwas rumprobiert..)
Das bringt mich zu einer Frage:
Kann man in T-SQL auch Variablen anhand von Spaltendefinitionen deklarieren?
So wie bei PL/SQL:
updID TEST_A.id%type;
Moin pi314,
Zu deiner Frage, ob es etwas dem oraclehaften xy.Feldname%type vergleichbares in T-SQL gäbe...
Ja nee... nicht wirklich... von Praktikanten für Praktikanten...
Die Redmonder Realitätsferne zeigt sich selten so schön wie hier.
Es gibt (wie immer im Leben) natürlich einen Weg, der über die sp_describe_cursor_columns führt.
Angelehnt ist der Name sp_describe_cursor_columns natürlich an das fett gedruckte.
Und in diesen Metadaten kommen auch die folgenden Attribute vor.
Dieses kryptische ###-data_type_sql wiederum, wortwörtlich "eine Nummer zum Anzeigen des ..Datentyps"...
--> den kann dann jeder interpretieren, der schon mit Excel 95 und Access/ADO-Krempel aufgewachsen ist.
Also --> ist aus meiner Sicht eher eine Frechheit als eine Unterstützung.
Ich habe zwar nichts gegen ein büschen Rumskripten, aber alle Räder immer wieder neu erfinden müssen... muss ich auch nicht haben.
Und ich arbeite ungern mit Tools, die mit so viel Realitätsferne und Alltagsuntauglichkeit zusammengekehrt wurden.
Grüße
Biber
Zu deiner Frage, ob es etwas dem oraclehaften xy.Feldname%type vergleichbares in T-SQL gäbe...
Ja nee... nicht wirklich... von Praktikanten für Praktikanten...
Die Redmonder Realitätsferne zeigt sich selten so schön wie hier.
Es gibt (wie immer im Leben) natürlich einen Weg, der über die sp_describe_cursor_columns führt.
Angelehnt ist der Name sp_describe_cursor_columns natürlich an das fett gedruckte.
Und in diesen Metadaten kommen auch die folgenden Attribute vor.
column_size [int] =Die maximal mögliche Größe von Werten in dieser Spalte.
data_type_sql [smallint] Eine Nummer zum Anzeigen des SQL Server-Datentyps der Spalte.
[Ist zitert aus der o.g. TechNet-Site]data_type_sql [smallint] Eine Nummer zum Anzeigen des SQL Server-Datentyps der Spalte.
Dieses kryptische ###-data_type_sql wiederum, wortwörtlich "eine Nummer zum Anzeigen des ..Datentyps"...
--> den kann dann jeder interpretieren, der schon mit Excel 95 und Access/ADO-Krempel aufgewachsen ist.
Also --> ist aus meiner Sicht eher eine Frechheit als eine Unterstützung.
Ich habe zwar nichts gegen ein büschen Rumskripten, aber alle Räder immer wieder neu erfinden müssen... muss ich auch nicht haben.
Und ich arbeite ungern mit Tools, die mit so viel Realitätsferne und Alltagsuntauglichkeit zusammengekehrt wurden.
Grüße
Biber