Spalteninhalte übertragen

Hallo,

zuallererst: Allen ein frohes neues Jahr! <:-)
Ich habe zwei Tabellen a und b und muss aus der einen alten Tabelle a den Inhalt der Spalte ‚ZU‘ korrekt in die zweite neue Tabelle b ‚condition‘ bringen. Die alte Tabelle wird dann nicht weitergenutzt und verworfen. Dummerweise habe ich aber keine Spalte zur Verfügung, die die Zuordnung immer ein-eindeutig festlegt.
Hier das Ist und das Soll mit den denkbaren Fällen.

Alte Tabelle Ist:

a
------------------------------------------
STNR          ART            ZU  
AGE01191    32028000          a       
AGE01258    24002000          b      
AGE01299    12040000          c
GNS046508   32038000          d      
GNS046508   32038000          e      
GNS046532   12015001          f       
GNS046532   13002000          g       
------------------------------------------

Neue Tabelle Ist:

b
---------------------------------------------------------              
PK   STNR       ART      condition        
1  AGE01191   32028000                  
2  AGE01258   24002000                  
3  AGE01299   12040000     
4  GNS046508  32038000                  
5  GNS046508  32038000                  
6  GNS046532  12015001                   
7  GNS046532  13002000                  
---------------------------------------------------------

Neue Tabelle Soll:

b
---------------------------------------------------------              
PK   STNR       ART      condition        
1  AGE01191   32028000     a             
2  AGE01258   24002000     b             
3  AGE01299   12040000     c
4  GNS046508  32038000     d             
5  GNS046508  32038000     e             
6  GNS046532  12015001     f              
7  GNS046532  13002000     g             
---------------------------------------------------------

Meine Strategie (ohne zu wissen, wie ich das bewerkstelligen könnte) wäre,

  1. Alle Datensätze, die nur eine STNR besitzen, werden 1:1 per INSERT überführt. (1., 2. und 3. Zeile)
  2. Alle Datensätze, die durch eine mehrmals auftauchende STNR gekennzeichnet sind, aber in Spalte ART unterschiedlich sind, werden ebenfalls per INSERT überführt. (6. und 7. Zeile)
  3. Alle Datensätze, die durch eine mehrmals auftauchende STNR gekennzeichnet sind und in Spalte ART gleiche Einträge besitzen, muss ich per Hand und Keyboard nachpflegen. (5. und 6. Zeile)

Bin ich auf dem richtigen Weg? Wie wäre eure Strategie?

Carsten

Vielleicht bin ich grad zu blind, aber deine alte Tabelle a und die neue Soll-Tabelle c sind gleich bis auf:

  • anderer Spaltennamen, statt zu nun condition
  • neue Spalte mit fortlaufender Nummer

Einklich brauchst doch nur alle Rows der alten Tabelle a sortiert nach Spalte “ZU” in eine neue Tabelle mit einer SERIAL-Spalte “PK” via INSERT reinzuwerfen. Oder selektiert mit row_num() over(order by zu) und kippst das in die Zieltabelle.


Andreas

So gleich, wie ich es dargestellt habe, sind die tatsächlich doch nicht. Das Beispiel war wohl nicht gut genug gewählt. Die alte Tabelle a ist tatsächlich sehr ähnlich dem Beispiel ohne Primärschlüssel und nicht sortiert, die Tabelle b existiert nicht wirklich. Deren Infos STNR, ART und condition sind in 3 verschiedenen Tabellen der neuen Datenbank enthalten. Die Inhalte von ‘ZU’ sind auch weder fortlaufend noch eindeutig, es sind meist strings 3 Stellen lang. Besser kann ich es leider auf die Schnelle heute nicht erklären. Ich glaube ich versuche es morgen noch einmal detaillierter. Sorry

Carsten

Auf ein Neues! Mein Beispiel war wohl falsch oder ich stehe auf dem Schlauch. Wahrscheinlich beides. Deshalb ein neuer Versuch mit mehr Nabelschau und mehr Infos im Detail.

Mir hat jemand (mit dem ich keinen Kontakt mehr habe) eine alte DB auf dBase-Basis mit 5 Tabellen in eine neue Struktur gegossen (pgresql). Es ist eine Funddatenbank für Pflanzen. Soweit so gut. Nur eine Spalte hat er vergessen. :angry: Darin sind bis zu 3 Buchstaben enthalten, NULL ist möglich. Die alte Tabelle heißt „agns“, die Spalte „ZU“. Deren Inhalt muss in die Spalte “report.plant_condition”. Die ganze Struktur der alten Tabelle agns sieht so aus: STNR, ART, ZU, ZAHL, DATUM, VON. Die Tabelle habe ich als xls-Datei. Selbst für mich sollte es möglich sein, sie in meine pgresql-DB zu bekommen.
STNR, ART, ZAHL, DATUM und VON aus der alten agns-Tabelle haben Entsprechungen in der neuen DB, allerdings sind diese dummerweise nur unter Zuhilfenahme der Inhalte von agns.ZU eineindeutig. Auch wenn ich mir die restlichen 4 alten Tabellen ansehe, finde ich keine Möglichkeit einer eindeutigen Zuordnung und damit auch keiner Sortierungsoption.

Hier die Entsprechungen von Alt -> neu:

agns.STNR -> location.inka-stnr
agns.ART -> taxon_id
agns.ZU -> report.plant_condition
agns.ZAHL -> report.quantity
agns.DATUM -> report.date
agns.VON -> reporter.reporter_id

agns.STNR ist kein Primärschlüssel, agns.ZU kann NULL sein. Deshalb sehe ich keine andere Möglichkeit, als tatsächlich einige Daten per Hand einpflegen zu müssen, möchte das bei 60.000 Datensätzen möglichst gering halten.

Leider kann ich kein Bild hochladen, sonst hätte ich die neue Struktur gepostet…

Wie sollte ich am besten daran gehen oder liegt die Lösung doch auf der Hand oder ist das alles Murks?
:confused:


Carsten

Nun doch noch das Bild meiner neuen DB:

http://img202.imageshack.us/img202/7808/37752495.jpg

Hi,

wenn Du nur noch diese eine Tabelle hast, fällt mir nichts rechtes dazu ein… Ansonsten würde ich es wohl mit neu umsetzen versuchen.

Eine Idee hab ich noch: Wenn Du auf die Tabelle noch kein insert/update/delete angewandt hast, stehen die Datensätze noch in der Reihenfolge, wie sie eingelesen wurden, wenn Du sie nochmal mit select ausliest, kommen sie genau wieder so raus und Du kannst die Spalte einfach (ohne Datenzusammenhang) hinzufügen, z.B. in der Tabellenkalkulation danebenkopieren und diese Tabelle dann wieder einlesen.
Jedes update führt aber dazu, dass der betreffende Satz am Ende der Tabelle landet… (selbst so wären natürlich einzelne Bearbeitungen noch nachvollziehbar).

cu jth

Depends. http://j-davis.com/postgresql/syncscan/syncscan.pdf


Andreas

Ja, natürlich ist das nicht die feine englische Art. Und natürlich könn(t)en Seiteneffekte, wie caching das verfälschen. Keine Ahnung, wie relevant das ist. Sicherer ist es wahrscheinlich, den DB-Server neu zu starten und nix anderes vorher zu machen, ehe man ausliest. Aber ich habe hier - wir beginnen gerade, unser Verwaltungssystem auf PSQL zu migrieren - ein paar nächtliche Autotransfers aus unserer bisherigen DB in PSQL, z.B. ca. 30000 Kunden. Die kommen immer in der gleichen Reihenfolge raus, weil die alte DB sie nach Recordnumber (quasi Anlage-Reihenfolge) sortiert ausgibt. Und sie sind immer in genau dieser Reihenfolge, wenn ich ein select ohne index und order drüber laufen lasse, auch nach diversen Queries, die ggf. mit order by liefen.

OK, das ist hier Linux, Opensuse 11.4, PSQL 9.0.10. Kann ggf. auf einem anderen System anders sein. Glaube ich aber nicht…

In der Not frißt der Teufel bekanntlich Fliegen…

cu jth

Ja, ist schon klar. Ich wollt auf was anderes hinaus: es gibt eine Optimierung in PostgreSQL, wenn Client A ein select * from aufruft, und wenn A vielleicht bei 5% ist ruft Client B dasselbe auf. Hier optimiert PG dann so, daß B sich quasi an A hängt und B wird nun ab den 5% von A beliefert, also beide bekommen nun diese Daten. Wenn das durch ist, bekommt B noch das, was fehlt: von 0 bis 5%. Und schwupps ist die Sortierung im Eimer.

Es gibt weitere Fälle, wo das passiert: ab Version (weiß ich grad nicht) werden Unique-Operationen durch Hashe erledigt, vorher durch Sortierung. Was also vorher ohne ORDER BY physisch sortiert rausfiel, kommt nun gewürfelt.

Also: nicht drauf verlassen, daß etwas sortiert rauskommt, insbesonder NIE in produktivem Code.


Andreas