Max. Anzahl Tabellen

[lgtime]

Hallo beisammen,

bei einem Projekt habe ich folgendes Problem:

Eine vorhandene Tabelle fasst ca. 148.000 Datensätze und läuft zwangsweise irgendwann über.
Je nach Anwender passiert die unter umständen schon nach Wochen. Es werden halt sehr viele Datensätze generiert. Meine Idee ist es nun, die Daten in zur Laufzeit zu generierenden Tabelle tageweise zu speichern. Hierbei ergeben sich gleich mehrere Fragen:

1. Wie kann ich das Vorhandensein einer Tabelle abfragen (Try except ist unbefriedigend)
2. Gibt es generell eine bessere Lösung zu diesem Problem
3. Wieviele Generatoren für die eindeutige ID kann ich erzeugen.

Ich danke euch für Eure Mühen

Gruß

Peter

Ich danke

[Lucas Franzen]

1. Scheinst Du Tabellen und Datensätze zu verwechseln.

2. Wie läuft bitte eine Tabelle über?

3. Wenn Du jetzt 148.00 Datensätze hast und den Primary Key mit einem Generatorwert erzeugst und einen 32-bit Generator benutzt, dann kannst Du noch 14500 mal 148.000 Datensätze speichern, wenn Du auch negative Generatorenwerte zulässt, dann sind es 29.000 mal so viele.
Wenn Du also 1 Woche gebraucht hast, um 148.000 Datensätze zu speichern, dann hast Du noch ca. 70 (140) Jahre Zeit, bis Dein Generator (so er 32 bit ist) überläuft und ins Negative (von 2^31 - 1 nach -2^31) umschlägt ...
So was nenne ich dann PAL - ein Problem Anderer Leute ;-)

4. wenn Du wirklich mit mehreren Trillionen Datensätzen rechnest und mit einem 32 Bit Generator auskommen musst, gibt es immer noch die Möglichkeit einen aus zwei Integer-Feldern kombinierten Primär-Schlüssel zu definieren, deren zweiter Eintrag an einem zweiten Generator hängt, der immer erst um eins erhöht wird, wenn der erste "überläuft" (der dann wieder auf 1 gesetzt wird).
So hat man auch 64-Bit ...

Luc

[lgtime]

Hallo Lucas,
ich habe mich wohl etwas unklar ausgedrückt.
Zu Deinen Antworten:

1. Ich importiere neue Datensätze und suche entsprechend dem Datum nach einer passenden Tabelle. Ist diese nicht vorhanden, so wird zur Laufzeit eine neue erzeugt. Kann man nach TABELLEN suchen?

2. Mit überlaufen meinte ich, dass beim Speichern eines Datensatzes eine Exception mitteilt, "die Tabelle ist voll".

3. Jede erzeugte Tabelle soll einen eigenen Generator bekommen für die ID

4. Pro Jahr werden also bis zu 365 Tabellen erzeugt.

Wann also ist Schluß bei dieser Methode? Was gibt es an Alternativen?

Gruß

Pete

[Lucas Franzen]

Peter,

Nach Tabllen kann man in der Metadaten-Tabelle RDB$RELATIONS suchen.

2. Tabelle ist voll gibt es nicht. Eine Tabelle kann nicht auf eine bestimmte Anzahl von Datensätzen beschränkt werden (außer mit Triggern, die bei Insert eine Exception auslösen würden, was weitere Inserts unterbinden würde)

3. Generatoren sind in ihrer Anzahl, abhängig von der Page Size der Datenbank, stark beschränkt. Da alle Genaratoren auf EINER einzigen Page gespeichert werden, steht eben nur eine begrenzte Anzahl zur Verfügung.
Bei Interbase müßte, ab Version 6, folgendes gelten:<br>
Page Size 1K - 124 Generatoren<br>
Page Size 2K - 257 Generatoren<br>
Page Size 4K - 508 Generatoren<br>
Page Size 8K - 1020 Generatoren<br>

4. Halte ich *überhaupt* nichts davon, Tabellen von einem Programm zur Laufzeit generieren zu lassen. Das mag vielleicht mit dBase, etc. in Ordnung sein, aber nicht mit einem SQL-Server.

Die Anzahl der Tabellen ist beschränkt, aber der Wert ist so theoretisch, dass ich ihn mir einfach nie gemerkt habe.

Alternative?<br>
Eine Tabelle, wie bereits gesagt.
Tagesdatum nicht als Tabellenname sondern als Feldname innerhalb der Tabelle (dies wird auch Auswertungen bedeutend leichter / schneller machen).
Und wenn Du mit 2 Milliarden Sätzen nicht hinkommst, eben den doppelten PrimaryKey verwenden, dann sind es 2^18 Datensätze (wie bei 64-bit Generator)
Im ersten Falle kannst Du fast 70 Jahre lang einen Satz pro Sekunde einfügen, mit der zweiten Methode kanpp 300 Milliarden Jahre lang. Sollte wohl reichen ;-)

Ich weiss, dass 148.000 Datensätze auf den ersten Blick wie eine ganze Menge aussieht, aber dennoch ist es bis zu 2 Milliarden ein recht weiter Weg...

Luc

[lgtime]

Hallo Lucas

vielen Dank erst einmal für Deine Hilfe!

Dies ist die Tabelle:

CREATE TABLE "JOURNAL"
(
"ID" INTEGER NOT NULL,
"DATUM" DATE NOT NULL,
"ZEIT" TIME NOT NULL,
"KID" INTEGER NOT NULL,
"TID" INTEGER,
"AID" INTEGER,
"NUM1" DECIMAL(5, 3),
"NUM2" DECIMAL(5, 3),
"NUM3" DECIMAL(5, 3),
"BYTE1" SMALLINT,
"FID" INTEGER NOT NULL,
"APID" SMALLINT,
"INT1" INTEGER,
"INT2" INTEGER,
"INT3" INTEGER,
PRIMARY KEY ("ID")
);

ID wird von einem Generator erzeugt. Bei etwas über 148.000 kommt eine Meldung welche ich als Tabelle ist voll interpretiert habe.
Zudem wird diese Tabelle recht langsam. Schon das Abspeichern des ersten Datensatzes dauert mehrere Sekunden. Dabei wird beim Einlesen der ASCII- Daten zwischen dem Abspeichern der einzelnen Datensätze weder commit noch commitretaining ausgelöst.

Eventuelle sollte ich mal mit backup/Restore versuchen.

Du meinst, diese Tabelle fasst 2 Milliarden Datensätze? Dann hat sich mein problem erledigt.

Gruß

Pete

[Thomas Steinmaurer]

Hallo Peter,
<br><br>
Du hast zwar bis jetzt noch nicht erwähnt welche genaue Serverversion Du einsetzt, aber der folgende Link könnte hilfreich sein, obwohl er schon ein bißchen überholt ist. http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_techspec&
<br><br>
Schöne Grüße,<br>
Thoma

[Heiko Luettge]

Hallo lgtime,<p>
wie heißt denn die Fehlermeldung ?<br>
148000 Datensätze sind wenig.<br>
Vielleicht hast du ja keinen Index auf dein Suchfeld ?<p>
Ansonsten stimme ich mit Lucas voll überein, dass es keinen Sinn macht Tabellen anzulegen (abgesehen von den Beschränkungen in IB bezüglich der Generatoren).<br>
Falls du später mal Probleme bezüglich Geschwindigkeit hast, kannst du immer noch die Daten eines Jahres in eine (1 !) eigene Tabelle auslagern und z.B. nur mit den Daten der letzten 2 Jahr arbeiten.
<p>
Zum Prüfen deiner Abfrage empfehle ich ibplanalyzer (einfach mal im netz suchen).
<p>
Ein bißchen Code wäre auch gut... Du nimmst ja hoffentlich ne Query zum Suchen .
<p>
Heik

[Lucas Franzen]

Peter,

Diese Tabelle fasst mehr als 2 Milliarden Datensätze.
Die Grenze wird mehr oder weniger vom Speicherplatz auf der Festplatte bestimmt.
2 Milliarden ist nur der Wert, den ein 32-Bit-Generator im positiven bereich annehmen kann, bevor er ins negative umschlägt.
32-Bit-Generatoren liefern einen SIGNED - d.h. vorzeichenbehafteten - INTEGER zurück. Diese gehen von - 2^31 bis 2^31 - 1, d.h. von -2.147.483.648 bis + 2.147.483.647.<p>
Zur Performance:<br>
Wir wissen immer noch nichts über den Server den Du einsetzt und ich nehme mal an, Du hast einige Trigger auf der Tabelle oder viele (oder unsinnige) Indizes, die bei Insert gepflegt werden müssen.<br>
Ich habe gerade mal spasseshalber 10.000 Datensätze (mit komplexerer Struktur und relationaler Verteilung in mehrere Tabellen) über eine Schnittstelle eingelesen und habe dafür ca. 25 Sekunden benötigt.
Und ich habe auch nur einen 1200er AMD.<br>
Also liegt das Problem woanders.<br>
Vielleicht solltest Du mal alle zugehörigen Metadaten zeigen (also auch Indizes, Trigger, etc.)
<p>
Luc

[lgtime]

Hallo beisammen,

zuerst einmal vielen Dank für eure Hilfe.

ich arbeite mit
IB6.0.1.0
Delphi 6.0 pro
WinXP Home Win2000

Nach dem Backup/Restore ist der Fehler weg. Es war etwas wie Queue ist in Gebrauch oder so ähnlich.

Nach wie vor jedoch habe ich das Phänomen, dass die erste Postanweisung langsam ist (mehrere Sekunden), alle weiteren sind schnell.

Trigger habe ich keine. Als Index existiert nur der PrimäIndex auf der ID

Gruß an alle

Pete