bituniverse.com

[Holger (HMR)]

Hallo Zusammen,
Slavas Hartnäckigkeit hab ich es zu verdanken, das ich nun gründlich über ein sehr altes Tabellensystem (MySQL DB) nachgedacht habe und es nun mal langsam
angehen lasse, das zu optimieren.

Im Moment habe ich eine Tabelle und ein menge txt Dateien.

Die Tabelle ist im Prinzip so aufgebaut:

Zitat:

Zuordnungskennzeichen; Kurzbeschreibung; num.wert, num.wert

in den Textdateien stehen die Langbeschreibungen,
diese sind mit Bildern in einer Verzeichnisstruktur abgelegt.

Alle Daten sind in der Verzeichnisstruktur so organisiert:

Zitat:

Projekt, Kategorie, Gruppe, Untergruppe

Zu einzelnen Datensätzen können Variationen existieren.
Als Beispiel: Hemd, Größe, Farbe
Da die Quelle der Daten keine Variationen zulässt, ist die Differenzierung
der Datensätze über den Zuordnungsindex geregelt.
Als Beispiel das obige Hemd, XL, grün
der Zurodnungsindex wäre jetzt C102230XLgrün
Der Zuordnungsindex enthält nun folgende Informationen:

Zitat:

C10 - ein Bezug zu z.B. Hersteller o/u. Lagerort| 2230 - das Hemd | XL -die Größe | grün-die Farbe

--------------------------
Jetzt will ich zusätzliche Informationen,
- Thumb und Imagedateipfade
- Struktur Zugehörgkeit
- Langbeschreibungen
ebenfalls in Tabellen ablegen.
---------------------------

Nun grübele ich über die Sinnhaftigkeit der Organisation nach.

Da Datensätze zu verschiedenen Projekten und Kategorien, oder Gruppen und Untergruppen gehören können, scheint es mir nicht sinnvoll, die Zugehörigkeit in die Stammtabelle zu packen.
Folglich habe ich eine neue Tabelle, in der die Zugehörigkeit-EN notiert sind.
Die könnte so aussehen:
Zugehörigkeitskennzeichen, Kategorie, Gruppe, Untergruppe

und eine weitere Tabelle für die Langbescheibungen und die Imagepfade,
die könnte so aussehen:
Zugehörigkeitskennzeichen, Text, Pfad_thumb, Pfad_image
--------------------------------
Ist das so sinnvoll???

Oder hat da wer eine bessere Option?
z.B.
Für jede Kategorie, Gruppe, Untergruppe und Kombinationen daraus(was möglich ist) eine Tabelle anlegen und dort nur die Zugehörigkeitskennzeichen notieren?

Und dann ist noch die Frage nach dem tabellen-index.
Da hab ich ein Verstädnisproblem.
Da im Zuordnungskennzeichen selbiges beliebig oft auftauchen kann,
kann ich diese Spalte in der Tabelle nicht indexieren. jedenfalls nörgelt mein MYSQL wg. doppelter Indexe.

Macht es irgendeinen Sinn, den Tabellen vorab eine, z.B. laufende Nummer als index zu verpassen, obwohl diese ja keinerlei Verwendung findet.

Und macht es einen Sinn, die Variationen eines Datensatzes ebenfalls zusätzlich in eine eine Tabelle zu trennen? Die zugehörigen numerischen Werte können allerdings auch voneinander abweichen.
z.B. das Hemd:
C102230 ; m; grün
C102230 ; L; grün
C102230 ; XL; grün
C102230 ; XXL; grün
C102230 ; m; blau
C102230 ; L; blau
C102230 ; XL; blau
C102230 ; XXL; blau

und in den anderen Tabellen dann nur noch C102230 als Zuordnungskennezichen zu notieren??
Dadurch hätte ich eine zusätzliche Variationstabelle und erheblich weniger Datensätze in den anderen Tabellen. Wie löse ich dann aber das Problem, wenn auch die zugehörigen Werte, wie z.B. Kurzbeschreibung und num. Werte in den Optionen von einander abweichen??

Und nun :
Bisher habe ich aus einem Verzeichnisse mit glob() die Textdateien geholt,
und mit basename(.txt) das Zuordnungskennzeichen selektiert und konnte nun mit einer sql-abfrage alle relevanten Datensätze abgreifen.

Die Textdatei zu dem o.g. Hemd : C102230.txt, die Bilder analog.
Strukturiere ich das alles um, wie greife ich jetzt den Zugehörikeitsindex ab ??
Select 'e ich jetzt nach kategorie, gruppe, untergruppe,
bekomme ich nicht nur das Hemd einmal, sondern mit allen Variationen zurück. Ich brauche aber nur den, sagen wir mal, Stammdatensatz.
Erst in einem späterem Prozess benötige ich auch alle Variationen EINER Zugehörigkeit, zuvor aber eben alle Zugehörigkeiten einer Untergruppe OHNE Variationen.

Ist alles sehr komplex. Hoffe, es hat trotzdem wer die zeit gefunden.
Dafür herzlichst dankeschön!

Also...
Vielen Dank schon mal fürs lesen
Einen schönen Tag
Holger

[Simon W.]

also für mich klingt das so, als möchtest du gerne folgendes layout haben:

tabelle produkte:
id beschreibung bild

tabelle variationen:
id produktid variation_parent variation
das _parent ist natürlich optional, aber so kann man eben verschiedene variationen aneinander knüpfen. z.b. wählt man zuerst eine der variationen mit parent=0 aus und bekommt dann alle unter-variationen aufgelistet und darf sich wiederum eine aussuchen. aber dieses design muss man natürlich je nach verwendungszweck/sinnhaftigkeit selbst gestalten.

wenn die produkte die gleichen variationen aufweisen, wäre es natürlich sinnvoll, eine unabhängige variations-tabelle und eine produkte<->variationen-zuordnungstabelle zu erstellen. wichtig ist, dass in der datenbank keine redundanten informationen stehen. der text "XL" sollte dort z.b. maximal einmal vorkommen.
stell dir einfach vor, was du in deiner jetzigen struktur alles machen müsstest, wenn die größe "L" plötzlich in "M" umbenannt werden sollte. genau solche zukunfts-fragen sollten dich beim design der tabellen dauernd quälen.

und dann eben jeweils noch tabellen für die projekte, kategorien, gruppen und untergruppen, hersteller, lagerorte und deren zuordnungen (also auch eine zuordnungsliste für produkte<->untergruppen)

nun könntest du auf jeden fall alle einträge in irgendwelchen tabellen immer nur noch auf die produktid beziehen (oder gar eine spezielle variation, die haben ja auch alle nummern) und benötigst nicht dieses kennzeichen.

entschuldige bitte die vernachlässigung von groß/kleinschreibung trotz des längeren textes, aber ich dachte mir gerade, dass es dann halt etwas schneller geht, das ganze zu schreiben.

[Holger (HMR)]

Hallo Simon,
danke für die mühe des lesens und den aufwand des verstehens!!!!

das ganze fühlt sich für mich exorbtant komplihihizieehrt an.
deshalb versuche ich mal eines nach dem anderem zu schnallen.

Simon W. hat Folgendes geschrieben:

also für mich klingt das so, als möchtest du gerne folgendes layout haben: tabelle produkte: id beschreibung bild tabelle variationen: id produktid variation_parent variation das _parent ist natürlich optional, aber so kann man eben verschiedene variationen aneinander knüpfen. z.b. wählt man zuerst eine der variationen mit parent=0 aus und bekommt dann alle unter-variationen aufgelistet und darf sich wiederum eine aussuchen. aber dieses design muss man natürlich je nach verwendungszweck/sinnhaftigkeit selbst gestalten.

Erstmal, das mit dem aussuchen findet so nicht statt. (usertechnisch)
da wird ein user ja irre, bis er endlich weis, was der artikel kostet.
der bekommt eine liste unter der beschreibung, aus der er auswählen kann.
ich pn dir mal einen link.
in der o.g. produktetablle wären dann noch die preise notiert.

Nehmen wir mal an, das ganze ist ein shop, in dem es autos, hemden, und flitzebogen und schuhe gibt. die art der variationen ist nicht gänzlich transportabel.
schuhe und hemden, ok, farbe und größe. aber autos und flitzebögen? die nicht mehr.
das dumme an der sache ist jetzt ausserdem, das die variationen auch unterschiedliche preise haben (können).
in der stammtabelle stehen z.zt. alle variationen als separater eintrag.
lese ich jetzt per glob() alle beschreibungstexte aus einer gruppe,
habe ich durch die nomenklatur der dateinamen den basisartiklecode und kann so alle zugehörigen datensätze abgreifen.
Beispiel mit dem hemd:
- select where code='basename($datei,'.txt')%'- / dateiname= c102836.txt
damit bekomme ich auch c102836lblau, XLblau, etc...

nun müsste ich eigentlich, unter berücksichtigung von autos, hemden und schuhe, flitzebögen auf jeden fall 3 tabellen nur für die variationen haben.
[Kopfkratz]

Mein größtes Problem ist aber, wie bekomme ich den Artikelbasiscod,
wenn ich nun keine textdateien mehr verwende.
Dann müsste ich alle artikel mit variationen aufsplitten in basiscode und variationen und hätte dann eine tabelle, die nur die basiscodes enthält,
und in der müssten dann die zugehörigkeiten notiert werden.
wegen der differenten preise müssten aber trotzdem die artikel mit variationen in der stammtabelle, in der die preise hinterlegt sind, auch notiert sein.
die variationstabelle für hemden würde jetzt so aussehen:
C102836 | M | blau
C102836 | M | grün
C102836 | M | lila
C102836 | XL | blau
C102836 | XL | grün
C102836 | XL | lila
usw. usw. usw.
nehmen wir mal an, da sind insgesamt nur 200 artikel, die diesem variationsmuster folgen, für jeden artikel gibt es die größen s,m,l,xl,xxl und druchschnittlich 5 farben, das sind 200 x 5 größen x 5 farben,
somit wäre ich bei den hemden schon bei 12500 einträgen.
nur für die variationen, die sind jetzt natürlich auch wieder in der stammdatenbank. (nicht alle, aber eben die, bei denen durch die variation
auch der preis variiert.)
macht das irgendeinen sinn??

DAS fühlt sich irgendwie grottenkompliziert an,
und der recht nutzen will sich mir nicht erschließen.
Da stellt sich dann für mich die frage, macht es tatsächlich sinn,
die variationen in einer sepateten tabelle zu verwalten?

Zitat:

entschuldige bitte die vernachlässigung von groß/kleinschreibung trotz des längeren textes, aber ich dachte mir gerade, dass es dann halt etwas schneller geht, das ganze zu schreiben.

nene, also sooo nich ! wenn das die dudenpolizei sieht !

[Slava]

Hi Holger.
1)Tabelle Kategorien, und zwar wie es in sql-bücher für die Anfänger stehet.
id | Kategoriename | id_parent (zeigt auf obere kategorie, wenn vorhanden, sonnst null)

Auch wenn du mit einer reqursiver funktion an eine Kategorie - Hierarchie durchlaufen muss, wird es kaum langsamer, als rekursiv in einer
Ordnerstruktur nach einer Datei zu suchen(Vorraussetzung Mysql ist nicht durch 1000 Benutzer geteilt).
Sonnst kommt auch nestendset wunderbar für Kategorien in Frage.

2) Ganz normale Artikel-Tabelle wo du die gemeinsame Eigenschaften von
allen Hemden, Bogen, Eimer und Lei-Elefanten hast.

das könnte zbs eine Interne ID sein, Bezeichnung, Hersteller-ID, Lagerort-ID, image-pfad,
VerkaufsPreis,AnkaufsPreis, Menge-am Lager, Menge-Typ-ID(kg,cm,Meter,Meter2,Meter3,Stück,....)

und andere Dinge, die wirklich bei Jedem Artikel vorkommen.

Jetzt Kommt die Frage
ist ein Artikel nur zu einer Kategorie zuzuordnen, oder könnte es vorkommen, dass ein Artikel zu mehreren Kategorien gehört.

wenn du dich für eine Kategorie entscheidest, dann bringst du direkt eine kategorie_id als fremdschlüssel in deine Artikeltabelle rein (bei 99% Shop-Einsatz wird es ausreichen).

sonnst machst du eine Extratabelle, die( id_kategory | id_artikel) hast und pflegst in dieser Tabelle die zugehörigkeiten von Kategorien und Artikel.
(natürlich macht man so was nicht von hand )

die Idee mit zusammengesetzten schlüssel wie ( C102230XL), würde ich nur als zusatzlösung betrachten, sonnst pack jede einzelne Eigenschaft in ein Extrafeld.
--------------------------------
3)
Jetzt kommen die Eigenschaften von verschiedenen Dingen die nichts mit einander zutun haben (Elefant-Eigenschaften, Hemden-eigenschaften , Bogen-eigenschaften)
Dafür gibt es mehrere Einsätze, die man bei Informatik-Studium als auch in realem produktivem Einsatz gelernt hat( nicht immer das gleiche )

3.1) man erstellt die Tabellen, mit den Namen, die gleich mit dem Namen in Artikelbezeichnung sind (bzw id von einer extratabelle, wo die namen von Tabellennamen stehen) und nach dem man ein passender Artikel geschnappt hat, dann wird einfach eine passende Tabelle selectirt mit der artikel_id, die uns interessiert.

3.2) Denormalisierung
Wenn man nicht zu viele Eigenschaften hat, dann macht man einfach eine einzelne tabelle, wo man alles reinpackt.
id | artikel_id| breite | laenge | Oktanzahl | farbe | maximale_geschwindigkeit|.....
in diesem fall kannman auch alle eigenschaften direkt in artikelid packen.
dann fragt man einfach bei Hemd nach Farbe und bei Benzin nach oktanzahl
Praxis zeigt, dass bei sehr vielen spalten die tabelle langsam wird und ein zusätzlicher Bedarf für die Beschreibung von erlaubten Eigenschaften besteht, also man muss berücksichtigen, dass bei Suche nach 'Hemden' ein 'Oktanzahl' nicht besonders passend ist.
Wenn das so weit kommt, dann besser direkt mit dem Einsatz 3.1 beginnen
sonnst:
Die Gedanken über die überflüssige Belegung von Festplattenspeicher, die bei leeren Felder besteht können wir bei einem Shop und aktuellen Festplatten-grössen ausser Acht lassen.

3.3) Kompliziert! eine DB-Object Model
an dieser stelle reicht es SQL nicht mehr aus und man muss auf die spezifische Future wie X-Query zugreifen und eine extra Schicht für die Kommunikation mit DB benutzen. am bestens vergessen wir 3.3 und machen uns die Gedanken über 3.1 und 3.2
-------------------------