In php uniqueID erzeugen, die nur aus Ziffern besteht?

[Rolf B]

Hallo Hank,

Problematisch hieran ist aber, dass ich, wenn ich neue Artikelpreise einlese, die alten Artikel heraus lösche und dann die neuen eintrage.

Ja. Das ist das Problem. Wenn man Daten von Dritten einbindet und diese Daten mit eigenen Attributen anreichert, muss man sich überlegen, wie man mit Updates umgeht.

Fremd- und Eigendaten in einer gemeinsamen Tabelle zu speichern ist offensichtlich suboptimal.

Aber Du sagtest ja, dass deine Daten einen eindeutigen Schlüssel haben: Lieferanten-ID und dessen Artikel-ID.

Damit kannst Du Mitlesers Idee aufgreifen: Eine eigene Tabelle, mit Lieferanten-ID, Fremd-ArtikelID und Eigen-ArtikelID. Die Eigen-ArtikelID braucht einen UNIQUE Index, damit Du schnell herausbekommst, ob eine Kollision entsteht.

Nach einem Datenimport musst Du dann ein Script laufen lassen, das die Fremddaten-Tabelle mit der Tabelle für eigene ArtikelIDs verknüpft, und zwar so, dass Du die Fremddaten-Rows bekommst, für die Du noch keine eigene Artikel-ID hast.

select lieferantid, lieferant_artikelid
from   lieferantendaten l
where not exist(select * from eigenedaten e
                where e.lieferantid = l.lieferantid
                  and e.lieferant_artikelid = l.lieferant_artikelid)

Das Ergebnis haust Du Dir in ein Array (oder eine Datei, falls Du Millionen von Sätzen hast). Dann läufst Du da drüber. Pro Eintrag

• Erzeugst Du eine Eigen-ID. Hier musst Du entscheiden, ob die Eigen-ID reine Zufallszahlen sein können (z.B. von 100000 bis 999999) oder ob Du für irgendwas Nummernkreise bilden willst, wie Tom andeutete. Ob Du eine Prüfziffer brauchst, weiß ich nicht, sowas ist eigentlich nur nötig wenn deine Artikelnummern den Computer verlassen und fehlerbehaftet wieder eingegeben werden können.
• Machst Du einen INSERT (lieferantid, lieferant_artikelid, eigen_artikelid) in die Tabelle für die Eigen-IDs. Ist die Eigen-ID schon da, geht der INSERT mit einem DUPLICATE-KEY in die Binsen. Jetzt brauchst Du eine schlaue Möglichkeit, eine neue ID zu finden. Mit der neuen ID wiederholst Du diesen Schritt. Ist der Algorithmus hinreichend schlau, wird es für die meisten Artikel gar keine Kollision geben. Und wenn es eine gibt, dann nicht öfter als ein- oder zweimal. Bau aber eine Kontrolle ein, dass Du maximal 3 Ersatz-IDs erzeugst. Du willst bei einem Bug in der Ersatz-ID Suche nicht in eine Endlosschleife laufen.

Damit hast Du die Lieferantendaten von deinen eigenen Daten getrennt und kannst deine Preis-Updates wie gehabt per "Abriss und Neubau" einspielen. In der Tabelle für die eigenen Daten kannst Du auch weitere Infos unterbringen, wie Lagerbestand oder andere Infos, die für Dich wichtig sind.

Mit Race-Conditions, wie Mitleser andeutete, solltest Du bei der ID-Generierung kein Problem haben, da Du Preis-Updates ja sicherlich während einer Downtime des Shops einspielst und dann niemand sonst auf der DB ist. Der ID Generator wird beim ersten Mal länger brauchen, weil noch gar keine Eigen-IDs vorhanden sind, aber in den Folgeläufen dürften die meisten Artikel schon da sein und es muss nur wenig angelegt werden.

Rolf