Die Tabelle oxarticles ist “normal” aufgebaut wie man Sie kennt.
Die Tabelle oxcategories verwendet als ID einen Zufallswert anstatt einer fortlaufenden ID. Warum? Wo liegt der Vorteil?
Die Tabelle oxobject2category scheint diese beiden Tabellen zu verbinden. Mir ist die Logik dahinter allerdings nicht klar, da hier die oxarticles ID gar nicht mehr auftaucht. Also nicht wie ich es normalerweise von MM Relationen kenne.
Würde mich freuen, wenn jemand ein Licht ins Dunkel bringen kann. Möchte gerne Artikel und Kategorien per csv importieren. Das geht aber scheinbar nicht vollautomatisch, so dass ich ein kleines Skript schreiben wollte.
in der oxobject2category wird der artikel über oxobjectid der oxcatnid zugeordnet.
Also sollte oxobject2category.OXOBJECTID ja eigentlich mit der oxarticles.OXIDID verknüpft sein.
Nur bei dem einen Feld handelt es sich um Zufallswerte. Bei dem anderen Feld um einen fortlaufenden Index.
Ich hab allerdings auch gerade bemerkt, dass die oxid bei oxarticles im 4er shop der oxartnum entspricht - verstehe ich nicht wirklich…
Ist nur bei den Testdaten so, wenn du einen neuen artikel hinzufügst sind OXID und oxartnum unterschiedlich.
Die Tabelle oxobject2category scheint diese beiden Tabellen zu verbinden. Mir ist die Logik dahinter allerdings nicht klar, da hier die oxarticles ID gar nicht mehr auftaucht. Also nicht wie ich es normalerweise von MM Relationen kenne.
Doch tut sie. die OXID ist zufällig, da es einfach nur ein schlüssel ist um die zeile zu identifizieren. die OXID des oxarticle ist die oxobjectid und die oxcatnid ist die oxid der category. Das ist einfach nur eine Zuordnungs Tabelle für die n:m relation.
Ich hab die struktur grad nicht vor mir, aber so wars meine ich.
Du hast Recht! Es sind wohl importierten Datensätze, wo die ID anders dargestellt werden.
D.h. die ersten 2000 Einträge sind bei mir importiere Datensätze wo die ID beispielsweise “076360”
heißt. Bei den übrigen Artikeln wird bei der ID dieser zufällige Hash Wert angezeigt.
Auf die Idee, dass das unterschiedlich gehandabt wird, bin ich nicht gekommen.
Wieso arbeitet man dann nicht konsequenterweise auch beim Import mit diesen Hash Werten? Oder nutzt grundsätzliche “ganz normal” ein fortlaufenden Index?
csimon hat es doch oben schon geschrieben. Oxid arbeitet normalerweise immer mit einem 32bit Char Wert. Lediglich die Musterartikel die im Shop sind weichen von diesem Schema ab. Legst Du jetzt neue Artikel an haben die auch den 32bit Key.
[QUOTE=Michael Fritsch;10574]csimon hat es doch oben schon geschrieben. Oxid arbeitet normalerweise immer mit einem 32bit Char Wert. Lediglich die Musterartikel die im Shop sind weichen von diesem Schema ab. Legst Du jetzt neue Artikel an haben die auch den 32bit Key.[/QUOTE]
Warum wurde denn offenbar mittendrin auf UUID’s umgestellt? Weiß das jemand?
csimon hat es doch oben schon geschrieben. OXID arbeitet normalerweise immer mit einem 32bit Char Wert. Lediglich die Musterartikel die im Shop sind weichen von diesem Schema ab. Legst Du jetzt neue Artikel an haben die auch den 32bit Key.
Mir ist klar, dass OXID so arbeitet. Die Frage ist, warum OXID so arbeitet. Und warum es beim Import dann wieder anders ist.
um jedes objekt in der datenbank eindeutig identifizieren zu können. Die OXID eines Artikels kommt nach dem system von oxid auch nur ein einziges mal vor, wäre es beispielsweise eine nummer hättest du einen oxarticle der die id 1 hat und eine kategorie die auch die id 1 hat, und einen user der die id 1 hat, und so weiter und sofort. Ist größtenteils sicherlich auch ansichtssache.
[QUOTE=csimon;10802]wäre es beispielsweise eine nummer hättest du einen oxarticle der die id 1 hat und eine kategorie die auch die id 1 hat, und einen user der die id 1 hat, und so weiter und sofort[/QUOTE]
Halt, entspricht das wirklich der Wahrheit oder verstehe ich Deine Aussage gerade nicht ganz?
Die regulären oxids die der Shop vergibt sind doch über die komplette Datenbank gesehen eindeutig oder nicht? Dh. wenn ein Artikel die 1 hätte, kann eine Kategorie unmöglich auch die 1 haben.
Kann jetzt leider nicht in der DB nachschauen aber mir ist absolut kein Fall bekannt, in dem eine oxid mehrfach in der Datenbank vorkam.
Du widersprichst Dir da auch selbst. Wenn Artikel, Kategorie und User die 1 haben, würde Deine Aussage, jede oxid kommt nur ein Mal vor nicht passen.
das beispiel mit der 1 bezieht sich auf die methode, wenn oxid KEINE datenbankweit eindeutige OXID vergeben würde, sondern je tabelle eine fortlaufende nummer. So mein ich das.
Natürlich ist die OXID eindeutig, ich wollte nur den ansatz erläutern, warum oxid wahrscheinlich diese methode verwendet hat. Bezog sich auf die frage hier:
Mir ist klar, dass OXID so arbeitet. Die Frage ist, warum OXID so arbeitet