MySQL: Probleme mit Primary-Key

[~Gh05t~]

Hallo zusammen,
ich schreibe gerade ein PHP-Script zum auswerten von Logfiles.
Eigentlich brauche ich dafür keinen primary-key, dieser stört mich eher, da ich keine ID oder sowas habe und die Berechnung solcher relativ lange dauert und ein auto_increment sehr schnell sehr groß wird (da beim neu Einlesen der Logs große Teile der DB gelöscht werden).
Da ich jede Zeile der Logfiles in die DB lesen will dauert der Programmaufruf relativ lange, da ich etwa 200.000 Zeilen einlesen muss. Kann ich den Primary-Key weglassen? Ich habe gelernt, dass der immer da ein muss. Wäre es tragisch, wenn ich ihn weglasse?

[mwanaheri]

Du solltest niemals eine Tabelle ohne primary key anlegen. Selbst wenn das dbms es dir gestattet, kannst du hinterher kaum sinnvoll mit der Tabelle arbeiten, weil ja nicht sicher ist, dass du einen bestimmten Eintrag triffst, z.B. beim update. Was du aber machen kannst:
lege eine bigint-Spalte als primary key an und fülle den Wert aus dem Programm heraus. Du hast ja ohnehin eine Schleife zum Einlesen, da tut eine Zählvariable nicht weh. Du kannst den letzten Wert anschließend entweder in einer eigenen Tabelle speichern oder vor dem nächsten abspeichern den maximalwert ermitteln und eins raufzählen.
Bei so massenhaftem Einspeichern halte ich das für vertretbar, denn es ist schneller als ein autoincrement der Datenbank.

[Christoph]

Du kannst auch einen zusammengestzten Schlüssel verwenden, z.B. Tagesdatum + fortlaufende Nummer.

[~Gh05t~]

Ich brauche den Primary_Key in diesem Fall ganz sicher nicht.
Meine Logfiles sind CSV-Files von etwa 30 verschiedenen Anlagen, die pro Zeile Datum+Zeit und den zu dieser Zeit beginnenden Status enthalten.
Mein PHP-Script generiert aus dem Datum+Zeit ein Timestamp und schreibt Status-Begin, Status-Ende, Status, Anlagennummer in die DB. Es gibt also keine Doppelten Einträge für eine Anlage. Und ich mache auch ganz sicher keine DB-Abfragen über den Primary-Key sondern über Anlagennummer und Timestamp. Also auch keine Zeit-Nummer kombination.

Beim Update lösche ich zunächst alle Einträge der entsprechenden Anlage, was eine Lücke in der Primary-Key folge hervorruft. Die später wieder zu füllen braucht absolut zuviel Rechenleistung.

BTW: Was passiert, wenn der Primary-Key zu groß wird?

[mwanaheri]

Ich brauche den Primary_Key in diesem Fall ganz sicher nicht.
Meine Logfiles sind CSV-Files von etwa 30 verschiedenen Anlagen, die pro Zeile Datum+Zeit und den zu dieser Zeit beginnenden Status enthalten.
Mein PHP-Script generiert aus dem Datum+Zeit ein Timestamp und schreibt Status-Begin, Status-Ende, Status, Anlagennummer in die DB. Es gibt also keine Doppelten Einträge für eine Anlage. Und ich mache auch ganz sicher keine DB-Abfragen über den Primary-Key sondern über Anlagennummer und Timestamp. Also auch keine Zeit-Nummer kombination.

Beim Update lösche ich zunächst alle Einträge der entsprechenden Anlage, was eine Lücke in der Primary-Key folge hervorruft. Die später wieder zu füllen braucht absolut zuviel Rechenleistung.

BTW: Was passiert, wenn der Primary-Key zu groß wird?

Demnach bist du wohl inder glücklichen Lage, einen natürlichen Schlüssel benutzen zu können: timestamp und Anlagennummer.
Du kannst diese beiden Felder als Schlüssel definieren (gemeinsam bilden sie _einen_ schlüssel) und bist aus dem schneider.
Diese beiden lassen sich identifizieren und anhand der beiden kannst du also einen Eintrag eindeutig bestimmen.

Eine Lücke in der primary-key folge ist übrigens unproblematisch und muss nicht gefüllt werden. Ein Primärschlüssel stellt die Einzigartikeit einer Zeile sicher, nicht die durchgängigkeit einer Zahlenfolge.

[michael.sprick]

BTW: Was passiert, wenn der Primary-Key zu groß wird?
Wenn Du damit einen künstlichen PK meinst, der aus einem Auto_increment Feld besteht, dann gilt:
übersteigt der Wert eines auto_increment Feldes die Range des Datentyps, gibt es einen Fehler beim Einfügen. Es gibt KEINEN Überlauf, so dass er wieder bei 0 anfangen würde...

[~Gh05t~]

Demnach bist du wohl inder glücklichen Lage, einen natürlichen Schlüssel benutzen zu können: timestamp und Anlagennummer.
Das ist natürlich eine gute Idee... Thx, das Löst mein Problem denke ich.



Eine Lücke in der primary-key folge ist übrigens unproblematisch und muss nicht gefüllt werden. Ein Primärschlüssel stellt die Einzigartikeit einer Zeile sicher, nicht die durchgängigkeit einer Zahlenfolge.
Ich fände das deshalb recht sinnig, weil die Daten u.U. relativ häufig aktualisiert werden und somit die PK-Werte relativ schnell einen Überlauf hervorrufen würden. Aber das hat sich ja so erledigt :rolleyes:


Danke für eure Hilfe!! :)

[mwanaheri]

Ich fände das deshalb recht sinnig, weil die Daten u.U. relativ häufig aktualisiert werden und somit die PK-Werte relativ schnell einen Überlauf hervorrufen würden.

Wenn du die Angewohnheit hast, dauernd 200.000 Einträge hinzuzufügen, stimmt das wohl. ;)