dunvegane
Goto Top

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)

Content-ID: 172374

Url: https://administrator.de/contentid/172374

Ausgedruckt am: 22.11.2024 um 15:11 Uhr

HStumpf
HStumpf 31.08.2011 um 17:50:33 Uhr
Goto Top
Hallo

welche Datenbank wird denn eingesetzt?

Bei MSSQL 2008 R2 im TSQL über den Umweg einer Table Variablen

Horst
dunvegane
dunvegane 01.09.2011 um 08:19:09 Uhr
Goto Top
Wir nutzen MS SQL 2005 Standard Edition.
dunvegane
dunvegane 02.09.2011 um 07:14:30 Uhr
Goto Top
Ich hatte gehofft dass es eine Möglichkeit gibt eine bestimmte Zeile auszulesen. Dürfte doch eine sehr häufige Anwendung sein.
Biber
Biber 02.09.2011 um 09:59:15 Uhr
Goto Top
Moin dunvegane,

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.
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
pi314
pi314 12.09.2011 um 15:31:48 Uhr
Goto Top
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" face-smile
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
dunvegane
dunvegane 12.09.2011 um 20:04:08 Uhr
Goto Top
klingt auf jeden Fall eine Überlegung wert. Werde ich nächste Woche mal testen. face-smile
pi314
pi314 14.09.2011 um 13:26:20 Uhr
Goto Top
Als "Weiterbildungsmaßnahme" hab' ich mir das mal in TSQL geschrieben.. und es geht face-wink

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;
Biber
Biber 14.09.2011 um 19:22:24 Uhr
Goto Top
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 face-wink

Grüße
Biber
pi314
pi314 14.09.2011 um 20:37:33 Uhr
Goto Top
Ja Biber, da gebe ich dir recht face-smile
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;
Biber
Biber 14.09.2011 um 21:40:28 Uhr
Goto Top
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.
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]

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
pi314
pi314 15.09.2011 um 15:22:56 Uhr
Goto Top
Mahlzeit Biber,

Ja nee... nicht wirklich... von Praktikanten für Praktikanten...

Die Redmonder Realitätsferne zeigt sich selten so schön wie hier.

face-big-smile *klatsch*