aktuelles Update 2.0.7.0 - Fragen dazu

[lullifatz]

Hallo,

wir haben aktuell 1.258.744 attribute. Der letzte Eintrag, bevor ein neues Attribut vor der Umstellung auf BIGINT gespeichert wurde, war 503321206. Beim Speichern des neuen attributes wurde die ID 2147483648 automatisch vergeben.

Das Problem kann daran liegen, dass wir die Attribute per SQL Befehl direkt in die Datenbank schreiben und die ID praktisch selbst festlegen.

Gruß Matthias

[snocer]

prüft noch einmal Eure IDs, Das Problem mit dem Datentyp "int" bei Euch scheint wirklich daran zu liegen, das Eure ID eben schon größer ist als 2.147.483.647. Hier würde ich mal ansetzen und das prüfen warum bei nur einer Million Einträge Ihr bereits IDs im Milliarden Bereich verwendet.

Man kann den Wert auch wieder korrigieren.

[noRiddle (revilonetz)]

Es werden ja sicherlich nicht immer mehr Attribute. Es stellt sich also die Frage wie

[...]
...die Attribute per SQL Befehl direkt in die Datenbank...
[...]

geschrieben werden.
Wenn es jedesmal dieselben sind, lediglich mit anderen Werten, braucht man die Tabelle nur zuerst mittels TRUNCATE zu leeren, dann setzt sich der AUTO_INCREMENT-Wert automatisch wieder auf 1.

Gruß,
noRiddle

[snocer]

Sehr gute Antwort. Und auch wirklich die beste Lösung. Müssen ja nur Ihre aktuellen Attribute danach einmal neu schreiben.
Danach ist der kurzfristige Workaround mit "BigInt" auch nicht mehr nötig und der Typ kann wieder auf "Int" gesetzt werden.
Im Anschluss noch einmal alle Attribute inkl. der IDs exportieren und zukünftig diese auch für die Aktualisierung verwenden. Dann kann das eigentlich nicht passieren, was da gelaufen ist.

[lullifatz]

Hallo,

Es werden ja sicherlich nicht immer mehr Attribute. Es stellt sich also die Frage wie

Doch es sind immer mehr neue Attribute. Da die Suche nun super funktioniert, werden es noch einige mehr werden. Diese werden mit einem Insert Befehl eingefügt.

Gruß Matthias

[noRiddle (revilonetz)]

Klingt nach verkehrtem Shop-Konzept. Selbst wenn du Schrauben Würth wärst und nur einen Artikel als Schraube angelegt und dann die Maße, Gewindesteigungen, Materialien, Schraubenköpfe, Längen alle mittels Attributen gemacht hättest kämst du nicht annähernd an 1 Mio. Attribute.
Aber egal, wenn es läuft bei dir...

Gruß,
noRiddle

[snocer]

wenn ich es richtig gelesen habe, hat er bereits etwas mehr als 5xx.xxx Attribute. Ob es jetzt wirklich so viele sind, lassen wir mal dahin gestellt. Auf alle Fälle sind es anscheinend sehr viele. Und mit seinem Konzept kann er nicht so verkehrt liegen, wen er damit erfolgreich ist. Jede Klientel hat eben auch ihre Bedürfnisse.

Entscheidend ist doch, seine Suche läuft jetzt so wie er es sich gewünscht und erhofft hat. Und wenn er jetzt bei der Suche innerhalb von 1s + 8000 Ergebnisse geliefert bekommt bei nur 4 Zeichen und Enter ist doch alles Prima. Vorher war es eben min. die 5-10 fache Zeit für nicht mal die Hälfte an Ergebnissen. Und das alles ohne MyISAM nur mit den richtigen DB Einstellungen und InnoDB. Dann können wir doch auf den nicht signifikanten Read Vorteil bei MyISAM mit älteren DB Engines verzichten.

cu snocer

[noRiddle (revilonetz)]

Hab' ja eigtl. keine Lust mehr, aber das hat überhaupt nichts mit InnoDB zu tun. Die Verbesserung ist allein darin begründet, daß, was das Thema hier betrifft, die max. Zahl für INT überschritten wurde und Karsta, wie im anderen Thread erklärt, die DB vereinheitlicht hat.
Verkehrte Schlüsse ziehen nur weil sie einem in die Ideologie (= MyISAM iss schlecht, InnoDB iss gut)  passen ?

 

noRiddle

[snocer]

ich ziehe da keine Schlüsse aus ideologischen Gründen. Ich weiß um wen und was es da geht. Und wie das Problem erst einmal gelöst würde.

Wünsch Dir noch eine gute Nacht, bin jetzt weg. Heute um 08.xx sind die Handwerker da.

cu snocer

[karsta.de]

[...]
braucht man die Tabelle nur zuerst mittels TRUNCATE zu leeren, dann setzt sich der AUTO_INCREMENT-Wert automatisch wieder auf 1.
[...]

Eine gute Idee, besser finde ich aber den Primärschlüssel neu durchzunummerieren und dabei den AUTO_INCREMENT-Wert mittels SQL-Befehl neu zu setzen:

Code: SQL  [Auswählen]

SET @a = 0;
UPDATE products_attributes SET products_attributes_id = (@a := @a +1);
ALTER TABLE products_attributes  AUTO_INCREMENT = 1;

Damit nach einem Shop-Update > Strukturupdate, wobei wahrscheinlich BIGINT wieder auf INT zurückgesetzt wird, keine Daten aus der DB verschwinden.

BG Karsta

[noRiddle (revilonetz)]

Neu durchnummerieren verstehe ich wenn man Lücken hat weil man zwischendurch Zeilen aus der Tabelle gelöscht hat.
Im vorliegenden Zusammenhang verstehe ich es nicht. Erklärst du bitte ein wenig mehr ?

Gruß,
noRiddle

[karsta.de]

Meine Antwort bezog sich auf deinen zitierten Vorschlag, um die unnötige Verwendung von BIGINT zu vermeiden.
Außerdem muß bei deinem Vorschlag die exportierte Tabelle bearbeitet werden, was mit meinem Vorschlag nicht notwendig  wird.

[...]
wir haben aktuell 1.258.744 attribute. Der letzte Eintrag, bevor ein neues Attribut vor der Umstellung auf BIGINT gespeichert wurde, war 503321206. Beim Speichern des neuen attributes wurde die ID 2147483648 automatisch vergeben.
[...]

An dieser Antwort sieht man das scheinbar viele Attribute aus der Tabelle gelöscht wurden und sich die IDs inzwischen unnötig vergrößert haben.
Wahrscheinlich verstehe ich jetzt deine Frage nicht.

BG Karsta

[noRiddle (revilonetz)]

Ah, okay, verstehe, die Lücke hatte ich gar nicht wahrgenommen.

Bzgl. "exportierte Tabelle muß bearbeitet werden" fehlt mir wohl das Wissen über die genaue Vorgehensweise bei lullifatz. Da ist ja entscheidend wie genau neue Attribute importiert werden.
Ich kann mir jedenfalls nicht vorstellen, daß wirklich über 2 Millarden Attribute vergeben sind und wenn ich da richtig liege geht das alles ergonomischer/ökonomischer.

Gruß,
noRiddle

[GTB]

Wie ich bereits hier geschrieben habe:

Wenn die Werte laufend neu gemacht werden ohne dass sich was ändert gehen die IDs nach oben, da die Werte gelöscht und neu eingetragen werden.

Ich probiere es nochmals deutlicher zu schreiben:
Wenn für einen Artikel die Attribute neu gespeichert werden, dann werden zuerst die alten gelöscht und dann die neuen/bisherigen wieder neu eingetragen. Dabei wird stets der Autoincrement Wert hochgezählt.

Diese Routine hat den Vorteil, dass wir uns um gelöschte Werte keine Gedanken machen müssen, aber auch den Nachteil, dass der Autoincrement ständig nach oben wenn sich zB nur der Preis ändert oder noch banaler, der Lagerbestand.

Ich kann mir vorstellen die Durchnummerierung in den Installer zu den Systemupdates zu packen.

Gruss Gerhard

[snocer]

eventuell macht es auch mehr Sinn für @lulli..., wenn er für sein Script statt insert, replace verwendet. So werden vorhanden Datensätze nur aktualisiert (update) und nur nicht vorhandene neu geschrieben (insert). Ein Update bewirkt nicht das hochzählen des AUTO_INCREMENT Wertes.