Hallo,
ich möchte gerne Metadatentabellen sortieren, welche von anderen Tabellen als Fremdschlüssel referenziert werden.
Als Beispiel:
Tabelle: people
id name
1 Paul
2 Jack
3 Heinz
Tabelle: people_money
id nid money
1 3 1000
2 1 800
3 2 900
Wobei die Spalten 'id' in beiden Tabelle Primärschlüssel sind und 'nid' in der Tabelle 'people_money' ein Fremdschlüssel ist, der auf 'id' aus der Tabelle 'people' referenziert. Dabei gelten die Constraints ON UPDATE - CASCADE und ON DELETE - RESTRICT.
Mein Frage: ich möchte, dass die Tabelle 'people' aufsteigend nach der 'name' Spalte sortiert wird und so die Namen dann auch die aufsteigenden IDs je nach ihrer neuen Position in der Sortierung erhalten. Durch das ON UPDATE - CASCADE sollten sich dabei die ID's in der 'people_money' Tabelle mit ändern.
Wie kann man das machen und funktioniert das auch wirklich so durch die Constraints?
Die Daten in einer Tabelle sind erst mal per Default unsortiert.
Erst beim SELECT kannst du die Sortierreihenfolge angeben.
Dabei kannst du aber keine anderen Tabellen verändern.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
Aber welche Auswirkung hat denn dann das ON UPDATE - CASCADE? Oder besser, in welchem Fall hat dieses eine Auswirkung in der Tabelle, welche den Fremdschlüssel besitzt?
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
Na, bei einem UPDATE.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
Okay ... bei einem Update ... wie in dem Schema oben zu erkennen, referenziert die 'nid' auf die 'id' Spalte aus der 'people' Tabelle. Wenn ich nun zwei Einträge in der 'people' Tabelle ändere, also z.B. den Namen, der unter 'id' 1 steht in die Zelle schreibe, welche 'id' 2 hat und umgekehrt, dann muss sich ja auch die 'id' in der referenzierten Tabelle ändern, da ja der eigentliche Name nun unter einer anderen 'id' steht. Das wäre ein Update.
Ich wiederhole meine Frage und stelle eine weitere: was willst Du machen, wenn ein neuer Eintrag dazu kommt, ich sage mal 'Andreas'? Willst Du den dann wieder 'vorne' einsortieren und alle Keys ändern?
Oder um es kurz zu sagen: Datenbanken funktionieren anders. Buche doch ein Kurs bei ads ;-)
Andreas
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
Also ... das ist ein DWH (Data Warehouse) System, welches Millionen von Einträge enthält ... nun funktionieren die Analysen so, dass die ID's der Metadaten zurückgegeben werden und das Frontend holt sich über eine spezielle Methode dann die eigentlichen Namen der Metadaten, welche zu den IDs gehören ... Da man nun also die eigentlichen Name nicht sortieren kann, sollen sie schon im DWH in den Metadatentabellen sortiert vorliegen ... und JA .. diese Prozedur wird jedesmal neu ausgeführt, wenn neue Daten dazukommen ... dafür sind die DWH Server ausgelegt ... wie DB funktionieren ist in unserer Firma bekannt, doch kann ich den Umstand, dass Millionen von Daten nicht an das Frontend zurückgegen werden sollen nicht ändern .. durch die Rückgabe der IDs wird erhebliche Bandbreite beim Schicken der Daten aus dem DWH zum Frontend eingesparrt und es werden nur die Namen zu den IDs angefordert, welche auch wirklich angezeigt werden ... da die Analysen intern mit den IDs arbeiten, werden so die korrekten Sortierungen zurückgegeben, wenn die Namen hinter den IDs schon in der korrekten Sortierung vorliegen ...
Es geht hier nicht darum, das Schema der DB zu ändern ... Wenn man mit einem System arbeitet, welches nun einmal so konzipiert worden ist, dann muss man auch mal versuchen, aus den gegebenen Tatsachen das Beste zu machen. So läufts nun einmal in der freien Wirtschaft. Und das ich und die meisten hier nun einmal in der Uni was anderes gelernt haben, okay, das ist nun mal so. Aber erzähle das mal dem, der deinen Scheck bezahlt.
Nachdem Du offensichtlich im SELECT nicht sortieren willst/kannst, gibt es eigentlich nur den Workaround über CLUSTER.
PostgreSQL: Documentation: Manuals: PostgreSQL 8.4: CLUSTER
Das ordnet die Rows in einer Tabelle physisch nach der Reihenfolge eines Index. Das ist aber eine "einmal" Aktion, und muss letztendlich nach jedem Laden bzw. Ändern der Daten wiederholt werden.
Ob das praktikabel ist in eurer Umgebung musst Du selber rausfinden.
Übrigens: was sollen eigentlich die ganzen ... in Deinem Posting? Das verwirrt mich etwas.
Normalerweise nimmt man das her um zu zeigen, dass man Text weggelassen hat![]()
CLUSTER hilft dabei gar nichts. Das ordnet zwar die Indexdaten um, aber:
a) ist diese Sortierung nicht permanent sondern verflüchtigt sich bei nachfolgenden Änderungen wieder
und
b) betrifft das nur die physikalische Anordnung der Daten auf der Festplatte. Das hat mit der eigentlichen Ausgabe überhaupt nichts zu tun.
So, zurück zum Problem:
Sortieren tust du deine Daten bei der Ausgabe. Updaten tust du sie beim Aktualisieren. Ich sehe jetzt nicht ganz, wo es da ein Problem gibt - außer, dass ein SELECT nun mal kein UPDATE ist.
Wenn du sagst, dass DB-Erfahrung bei euch in der Firma vorhanden ist, dann zählt so etwas aber zu den absoluten Grundlagen. Und ein Data Warehouse System erfordert einige Vorarbeiten in einer relationalen Datenbank. Wenn man wie ihr optimieren möchte, gibt es sicher einige wege, aber das tut man im Detail analysieren und sich passende Lösungen dafür schreiben.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
Links: Tobias Bauer - IT- und Funkdienstleistungen - Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen - Funkforum
Lesezeichen