motion - Di 22.11.11 15:38
Titel: Hash Algorithmus gesucht: Artikel-Nr+Farbennr+Grössennr

---

Hallo,
für einen Webshop muß ich ein kniffiliges Problem lösen:
Der Webshop speichert die Artikel intern mit eindeutigen IDs (Long Integer; nur Positive Zahlen benutzbar; also eigentlich 31Bit von 0..2147483648

Jetzt muß ich für jeden einzelnen Artikel ein eindeutige ID generien:
HauptID: Bereich von 1..50000
Farben: Bereich 1..9999
Größen: Bereich 1..9999

Tja: ID=HauptID* 10000 * 10000 + Farben * 10000 + Größen
fällt leider aus, das ich damit den zulässigen Zahlenbereich sprenge.

Wie kriege ich die IDs bloß eingedampft auf die maximal mögliche Zahlengröße?

Bei jedem Artikel kommen maximal 20 Farben und max. 20 Größen aus dem gesamten Farben und größen Pool vor.
Irgendeine Abstraktionsebene muß da noch rein.

bummi - Di 22.11.11 16:49

---

FFFF FFFF
hier die Hauptnummer 0010 0111 0000 1111 für 9999 Farbe
50000 1010 0111 0000 1111 für 9999 Größe
1100 0011 0101 0000

motion - Di 22.11.11 17:40

---

@brummi:
Ich glaube ich verstehe Deine Ausführungen nicht ganz.
Kannst Du mir das noch mal erläutern?
Selbst wenn man den Bereich der notwendigen ID-Bereiche etwas verkleinert z.B.
HauptID (d.h. Anzahl der Standardartikel) auf 32767 = 15 Bits
Farben und Größen jeweils 4095 = 12 Bits + 12 Bits
dann bin ich insgesamt immer noch bei 39 Bits, somit 8 zuviel.

Ich habe schon überlegt sämtliche Farben und Größen-Kombinationen eines Artikels sortiert aufzulisten und durchlaufend zu nummerieren (auch wenn das mit [My]SQL ein Albtraum ist). Dann kommt man auf weniger als 1000 Kombinationsmöglichkeiten pro Artikel, hier mal X genannt. Dann könnte man eine ID genieren:
HauptID*1000+X

Mit dieser Logik käme ich nur in Schwierigkeiten, wenn im nachhinein Größen und Farben HINZUGEFÜGT werden. Das kann ich eventuell ausschliessen, weil bei Anlage der Artikels alle Größen und Farben festgelegt werden und dann nicht mehr lieferbare Artikel über den Bestand=0 festgelegt werden.

bummi - Di 22.11.11 18:26

---

Sorry, ich hatte einen Hänger, klar so geht es nicht.
Wie wäre es mit einer Hilfstabelle mit AutoID die Deine gesuchte Artikelnummer darstellt
sowie HauptID,Farbe und Größe, so kommst Du zumindest beim erweitern nicht ins schleudern.

motion - Di 22.11.11 19:05

---

@brummi.
Hmmm... Stichwort Hilfstabelle ist nicht schlecht. Da könnte ich mit autoincrement die IDs sicher stellen und immer rückwärts suchen, um eine ID wieder in die Einzelelemente mit Farben und Größén aufzulösen. Mit SQL kann ich die Daten schnell umpumpen und mit insert/update die Daten erstellen/aktualisieren.
Ich glaube DAS ist die beste Idee. So werde ich das mal angehen.

bummi - Di 22.11.11 20:48

---

@motion

ok, aber ich heiße nicht brummi, grrrr....

motion - Di 22.11.11 21:12

---

bummi hat folgendes geschrieben :

@motion ok, aber ich heiße nicht brummi, grrrr....

Sorry ...

Sinspin - Mi 23.11.11 15:01

---

Hallo,

ich denke Du stellst dir das ganze immernoch etwas komplizierter vor als es ist.
Du hast in deiner Artikeltabelle ja noch weitere Felder die jeden einzelnen Artikel beschreiben. Warum schaffst du dann nicht noch ein weiteres Feld "ArticleNumber" oder so als String (Char) mit einer Länge von 50 Zeichen zum Beispiel. So ist auch noch Platz für Später falls noch Artikel mit weiteren Eingeschaften hinzukommen. Nun legst du für jeden Wert den deine Eigenschaften (Artikel-Nr., Farbe und Größe) annehmen können eine Kurze, eine eindeutige Kennung fest. Beim Eintragen der Artikel in die Tabelle setzt Du dann den String aus den Kennungen der Eigenschaftswerte zusammen.
Allgemein sollte jede Tabelle ein Feld "Id", oder so ähnlich, von Typ Autoinc haben. Das macht einem die Arbeit deutlich leichter wenn es um eindeutige Zuodnungen von Datensätzen geht. Auf das Feld einen Index und das ganze geht auch dann noch ordentlich flott wenn die Tabellen richtig groß werden.
Deine Artikelkennung die Du so schaffst ist solange eindeutig wie du nicht den gleichen Artikel mit den gleichen Eingeschaften erneut einfügst. Das kannst Du über einen UNIQUE Index auf das Feld verhindern.
Zur Anzeige eines Artikels hast Du so dann die Möglichkeit den Autoincwert zu nehmen der aber nicht sehr aussagekräftig ist. Oder die Artikelkennung die Du nun auch zur Verfügung hast. Diese ist bei einer kleveren Wahl der Eigenschafskennungen perfekt geeignet um Dir und den Kunden gegenüber den Artikel leicht und verständlich zu representieren ohne den Namen oder die Beschreibung lesen zu müssen.
Ich arbeite in meinem Fall mit einem virtuellen Atikel der mir nur die Artikelnummer bringt und die Eigenschaften festlegt die die realen Artikel des Artikels haben können. Der Artikel selber kann nicht verkauft werden sondern nur die Artikel sich aus ihm erzeugen lassen.
Das ganze schaut dann zum Beispiel so aus:
Das einzige was nicht ganze einfach ist und was ich ganz ehrlich nicht mit SQL Lösen wollen würde ist das Erstellen der Artikelnummern aus den Eigenschaften.
In Delphi ist das eine relativ einfache N-Dimensionale Matrix ausmultiplikation. (N ist die Anzahl der Eingenschaften)

motion - Mi 23.11.11 15:56

---

@SinSpin:
Danke für Deine Bemühungen.
Diese eindeutige Artikel-Nr. welche Haupt-Art-Nr.+Farbcode+Größencode enthält habe ich schon, allerdings ist damit nur schwer zu arbeiten. Eindeutige IDs sind zum Abgleich beider Datenwelten (WaWi und Webshop) sehr viel einfacher zu handhaben.
Der gesamte Transfer muss mittels php und möglichst SQL ausgeführt werden um die Verarbeitung möglich zu machen.