[Oracle 9i] 3 Tabellen zu einer?

L

Loki2

Erfahrenes Mitglied
Hallo

Ich habe eine Datenbank mit einem riesig großen Table. Insgesamt mit über 100 Feldern.
Da dieser Aufbau einfach schrecklich ist und vollkommen gegen den Sinn einer Datenbank verstoßen hat, habe ich diesen Table in insgesamt 3 Table aufgeteilt.

Jetzt ist es aber so, das die Daten in den insgesamt drei neuen Tables, zumindest übergangsweise, auch in den einen großen Table kopiert werden sollen. Es sollen immer die neu hinzugefügten Daten zu einem bestimmten Zeitpunkt in den großen Table kopiert werden. Erkennen kann man die Datensätze an einem Schlüssel.
Wie kann ich also die Datensätze bekommen die in dem neuen Table dazu gekommen sind und es somit in dem alten noch nicht gibt um diese dann in den alten großen Table einzufügen?

Ich hoffe ich konnte mein Problem einigermaßen verständlich erklären und ihr könnt mir weiterhelfen. Fragt nicht wieso und warum das gemacht werden muss, das weiss ich ja selber kaum. Fakt ist das es gemacht werden muss und mir noch nicht ganz klar ist wie...

Vielen Dank schonmal im voraus.

Gruß und so
Loki2
 
Hi,

Ich nehm mal an, dass es in deinen Tabellen eine ID für jeden Datensatz gibt. Wenn ja, dann hol dir dach die maximale ID aus deiner Monstertabelle und welektier in den drei Neuen alles, was eine größere ID hat. Das select würde ich mt einem Cursor machen, mit dem du anschließend alles gleich wieder in die Haupttabelle schreibst.

Wenn ich dich richtig verstanden hab, wäre das meine Vorgehensweise.

*wunder, wer Tabellen mit 100 Spalten anlegt :confused: *
 
Ich denke es ist sehr unpraktisch die Daten erst aufzuteilen, und sie dann wieder zusammen zu kopieren. Du läufst nur Gefahr inkonsistente Daten zu bekommen und musst ausserdem alles doppelt speichern. Wie wärs denn mit einer View über die drei Tabellen, welche die Sicht auf die Daten einschränkt (falls das sein muss ? ) und den Stand deiner alten Tabelle rekonstruiert ?

Beispiel:

Code: 
CREATE TABLE SMALL_1 (
  PK_ID1    NUMBER(10),
  FELD_S1  VARCHAR2(30)
);

CREATE TABLE SMALL_2 (
  PK_ID2    NUMBER(10),
  FELD_S2  VARCHAR2(30)
);

CREATE TABLE SMALL_3 (
  PK_ID3    NUMBER(10),
  FELD_S3  VARCHAR2(30)
);

CREATE OR REPLACE VIEW BIG_ONE (
  PK_ID_ALL,
  FELD_ALL )
AS
 SELECT *
   FROM SMALL_1
 UNION ALL
 SELECT *
   FROM SMALL_2
 UNION ALL
 SELECT *
   FROM SMALL_2;
 
Nur weil es technisch möglich ist, heißt es aber nicht, dass das auch gut ist. Oracle verwaltet die Datensätze in Einheiten namens Blocks. Diese sind in der Regel 8192 Bytes groß. Wenn ihr nun eine Zeile lest, egal ob sie nun 8k groß ist oder nicht, wird immer der komplette Block gelesen und auch im Speicher gehalten. Je häufiger auf diesen Block zugegriffen wird, desto höher ist auch die Wahrscheinlichkeit dass er im Speicher bleibt und beim nächsten mal wesentlich schneller gelesen werden kann.

Sind die Tabellen nun sehr breit, sprich viele Spalten, so wirkt sich das natürlich auch auf einen einzelnen Satz aus und so passen weniger Sätze in einen Block. Noch schlimmer wird es, wenn eine Zeile zu groß für einen Block wird, dann muss Oracle 2 oder mehr Blöcke lesen. Das kann besonders bei Updates ein Problem werden, denn wenn Daten geändert werden, wird immer der komplette Datensatz an einem Stück neu geschrieben. Passt dieser Datensatz nun nichtmehr in den Block muss neuer Speicher alloziiert werden. Zudem muss ein Verweis im alten Block auf die neue Position des Datensatzes verbleiben...

Da sowieso nur in den seltensten Fällen alle 250 Felder gleichzeitig gelesen werden (und wenn doch würde ich mal die Anwendung überdenken) kann man die Daten ruhig in mehrere Tabellen aufsplitten. Das macht das Datenmodell schöner und ist auch performanter.
 
Hallo!

ich habe ja nicht gesagt, dass ich diese vielen Spalten begrüße ... ;-)
... mir wurde das ganze als "historisch gewachsen" verkauft. Na ja, vielleicht schrumpfts ja irgendwann wieder...

Gruß Tom
 
Thomas Darimont hat gesagt.:
Hallo!

ich habe ja nicht gesagt, dass ich diese vielen Spalten begrüße ... ;-)
... mir wurde das ganze als "historisch gewachsen" verkauft. Na ja, vielleicht schrumpfts ja irgendwann wieder...

Gruß Tom
Zum Vergrößern anklicken....

Das dachte ich mir auch, wollte nur mal den technischen Hintergrund erläutern.

Und wenn ich eins hasse, dann "historisch gewachsen". Kann ich nicht mehr hören ;-)
Und dann am besten noch Datum als VARCHAR2(6) = "010205" und Beträge als VARCHAR2(60) = '1.234,04' *grrrr* ... .alles schon gesehen...
 
Hallo!

Oracle bietet ja von Haus aus nur Unterstützung für 256 Spalten... jetzt stell dir mal vor da kommen Leute auf die Idee in der 256.te Spalte einen Blob abzulegen welcher nochmal 50 Spalten in einem "proprietären" Format beherbergt ... das solls auch geben.

Gruß Tom
 
Thomas Darimont hat gesagt.:
Oracle bietet ja von Haus aus nur Unterstützung für 256 Spalten...
Zum Vergrößern anklicken....
Das ist schon richtig, aber muss man das wirklich bis zum letzten ausnutzen? Ich hatte zwar bisher noch nicht mit Datenbanken > 5GB zu tun gehabt, aber ich finde es besser, wenn es etwas übersichtlicher ist und damit auf mehrere Tabellen aufgeteilt.
Außerdem fällt jetzt nicht wirklich was ein, wofür man 256 Attribute speichern müsste

Thomas Darimont hat gesagt.:
jetzt stell dir mal vor da kommen Leute auf die Idee in der 256.te Spalte einen Blob abzulegen welcher nochmal 50 Spalten in einem "proprietären" Format beherbergt ... das solls auch geben.
Zum Vergrößern anklicken....

sowas stell ich mir besser nicht vor, da wird mir nur schlecht.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück