In php uniqueID erzeugen, die nur aus Ziffern besteht?

[Hank]

Hallo Rolf,

danke für deine klasse Antwort.
Damit kann ich etwas anfangen, weil sie auführlicher ist und ich so auch die Ansätze der Mitforisten verstehe.

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

Davon gehe ich erst einmal aus.
Leider machen auch Lieferanten Fehler und es kam schon vor, dass ich 2 Artikelnummern bei einem Lieferanten hatte.

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.

Ok.

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.

Einverstanden.

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.

Ok.

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.

Muss mal überlegen. Dann habe ich z.b. eine Tabelle "Artikel", eine Tabelle "Intern" und eine Tabelle "Lager" (nur als beispiel). Die sind verbunden über LieferantID und ArtikelNr, also Spalten, die in allen 3 Tabellen zu finden sein werden. (mal unabhängig davon, dass ich in der lagertabelle auch die InternID nutzen könnte).

Aber solange ich die Preise weiterhin in der Artikeltabelle habe, kann ich meine "Abriss und Neubau"-Strategie dann doch nicht weiter führen. Denn wenn ein Artikel beim Lieferanten aus dem Sortiment gestrichen wird, fehlt mir der Eintrag in der Artikeltabelle. Weiterhin fehlen mir Stammdaten. Dann habe ich Lagerbestände zu "Geisterartikeln", nicht wahr?

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.

Race-Conditions sind unproblematisch, genau wie du sagst.

Hank