nicht angemeldet
Hi!
danke fuer Eure Geduld! Ich hab's jetzt wohl so halbwegs kapiert. - Bin ja kein "SQL-Experte". ;-)
Nicht? Dann war das jemand anders der das mal von sich behauptet hat :)
(Allerdings verstaerkt sich bei mir der Eindruck, dass Du "nur" Datensaetze speichern willst, in diesem Fall 'Artikel', die kategorisiert werden sollen.
Ja, darum geht es, warum "nur"? Was hast Du denn gedacht?
- Das habe ich auch schon gemacht - bei mir haben bisher aber immer insgesamt drei "starre" Kategorien und Unterkategorien gereicht. - Kategoriesierung mithilfe von vier Kategorien und dann noch "dynamisch"? Das war fuer mich einfach zuviel.)
es geht ja gerade darum, dass dei Strukturierung flexibel ist. Ich habe keien festen Kategorieren, sondern halt eine komplexe Baumstruktur, wie inzwischen mehrfach beschrieben. Die soll mind. 5 Ebenen tief sein können(bei meiner Version können die "unendliche" tief sein), und Produkte sollen den entsprechenden Kategorien auf allen Ebenen zuzuordnen sein.
dann mach mal eine Zeitmessung und Du wirst staunen.
Das kann ich mangels Daten nicht machen, aber vielleicht generiere ich mir mal ein paar, mal sehen. Aber ich bin mir sehr sicher dass man isn so einer wirklich winzigen Tabelle nur UNterschide im Millisekunden-Berreich bekommen wird - bei einer Abfrage.
Insbesonders das "rekursive Element", realisiert mithilfe von "umgebender Programmlogik", "haut rein".
Klar, aber das mache ich ja nie auf einmal, sondern wie im vorherigen Prosting beschrieben kommt pro Request imme rnur eine SQL-Abfrage - maximal 2 wenn es keine Unterkategoriern gibt. Das ist also vollkommen irrelevant.
Indizes sind immer gut. ;-)
Wie würdest Du di indices legen bei den Anfragen dei ich zuvor beschrieben habe?
btw - Was machst Du, wenn eine Liste aller 'Artikel' angefordert ist, z.B. fuer Exportzwecke. - Welche Laufzeiten erwartest Du dann?
Wenn nur die Liste der Artikel angefordert ist brauche ich ja nur eine einfache SQL-Abfrag auf die Artikel-Tabelle. Wenn ich in der Import-Datei auch die Kategorien brauche, dann mache ich das halt noch mit einem LEFT JOIN auf die Struktur-Tabelle, das dauert dann vielleicht etwas länger, kommt aber im Gegensatz zu den zuvor beschreibenen Anfragen sehr selten vor, ist also ebenfalls nicht vergleichbar relevant, außerdem wird selbst das noch sehr schnell gehen. Guck Dir mal die Suche dieses Forums an, wie lange die braucht um 150 MB zu durchsuchen, das ist unglaublich schnell, und die macht das immerhin linear, das heißt es wird eine Flat-File Wort für Wort durchgegangen und auf Treffer überprüft. Eine Datenbank mit vernünftigen Indices ist da erheblich schneller, außerdem muss ich nicht im gesamten TExt suchen, sondern ich suche direkt über IDs, was den größten Unterschied ausmacht. Wenn ich 100.000 IDs habe wird nur ein Index mit MEDIUMINT(SMALLINT wäre wohl doch zu klein, maximal 65.535 IDs, da will ich lieber auf Nummer sicher gehen), jedenfalls wären das 300.000 Bytes also knapp 300 KB durchsucht. Das ist _sehr_ schnell, und 100.000 Datensätze sind eigentlich absolut unwahrscheinlich. Ggfs. das auslesen der so ermittelten Daten würde bei Dir genauso anfallen, da Du ja dieselben Daten willst.
In beiden Tabellen ein primary-key auf ID und jeweils ein einfacher Index auf die parent_id bzw. kategorie_id spalte. Oder sollte ich noch einen über titel legen, oder vielleicht einen über mehrere Spalten (titel und ID)?
"It depends"
"whereof"?
Mag sein dass Deine Datenstruktur zu Ausgabe des Baums ein wenig prformanter ist, aber beim Auslesen der entsprechenden produkte ine ienr Kategorie sicherlich nicht, außerdem ist mein version auf keine Ebenen-Zahl beschränkt. Außerdem ist bei einer Solch kleinen Tabele(im Schnitt sicher nur 1000-10.000 Datensätze in der Struktur-Tabelle) die Performance sicher nicht mehr das Problem.
Hatte mal was von hunderttausenden Datensaetzen und von einer sehr variablen Kategoriesierung in Erinnerung.
Nein, 100.000 habe ich also absolut pessimistischste Obergrenze Angegeben - für Produkte(hatte iah glaube ich falsch formuliert), und für Struktur 10.000.
Also,
Tabelle "struktur":
ID: MEDIUMINT (3 Byte)
Parent_ID: MEDIUMINT (3 Byte)
Titel: CHAR(32) (32 Byte)
pro Datensatz also 38 Byte
38 Byte * 10.000 = kanpp 400 KB
Tabelle "produkte":
ID: MEDIUMINT (3 Byte)
Struktur_ID: MEDIUMINT (3 Byte)
Titel: VARCHAR(32) (im Schnitt vielleicht 16 +1)
Beschreibung: TEXT (im Schnitt vielleicht 256 + 2)
Spezifikation: TEXT (im Schnitt vielleicht 256 + 2)
Bild: VARCHAR(32) (im Schnitt vielleicht 16 +1)
pro Datensatz also: 3+3+17+17+258+258
ca. 550 Byte * 100.000 = ca. 55 MB
Heißt also, solange ich nur auf die Struktur-Tabelle zugreife spielt Performance keine Rolle, und selbst die Produkte-ZTabelel ist nicht wirklich groß. Und da ich ja nur nach der Kategorie_ID und der ID filtere, kann ich jeweils die wie oben beschriebenen sehr kleinen Indices verwenden. Also sollt edas kein Problem machen. Problematisch wäre es wenn ich auch die Inhalte der TEXT-Felder durchsuche, aber das habe ich nicht vor, und das wäre bei jeder Implementierung das Problem.
Du kannst Dich ja mal melden und zur Umsetzung berichten. - Dein Loesungsansatz ist ja _vielleicht_ wirklich gut. ;-)
Ich hoffe...
Grüße
Andreas