MySQL

[nina]

hi!
hab ne relativ große (2GB) große tabelle. in der habe ich neben vielen andren queries häufig folgende bedingungen:
WHERE(shop = "...")AND(kategorie = "...")
derzeit existieren bereits einige indexe, welche auf grund der anderen queries erforderlich sind und folglich nicht ersetzt/entfernt werden können:
 PRIMARY    PRIMARY    271592     Bearbeiten     Löschen     id
produktindex  UNIQUE  271592   Bearbeiten  Löschen  shop_id
shop
suchindex  FULLTEXT  271592   Bearbeiten  Löschen  bezeichnung  1
beschreibung1  1
beschreibung2  1
beschreibung3  1

-> das sind dann also 3 stück, einer nur auf ID, der is wohl standard, dann einer für shop_id und shop, und ein dritter für die bezeichnungen und für die verschiedenen beschreibungen.

welchen index soll ich nun für die genannten queries einrichten?
(shop=VARCHAR und kategorie=TEXT)

danke für eure tipps

[Alexander Brock]

Hallo Freunde des gehobenen Forumsgenusses,

welchen index soll ich nun für die genannten queries einrichten?
(shop=VARCHAR und kategorie=TEXT)

Warum ist die kategorie vom Typ Text? Reichen 255 Zeichen nicht?
Ich würde eine varchar-Spalte für die Kategorie machen und dann einen Index über shop und kategorie.

Gruß
Alexander Brock

[wahsaga]

hi,

Warum ist die kategorie vom Typ Text? Reichen 255 Zeichen nicht?
Ich würde eine varchar-Spalte für die Kategorie machen und dann einen Index über shop und kategorie.

Ist die Frage nicht eher, warum Kategorie überhaupt als Klartext (offenbar?) abgelegt wird?

Da sollte wohl noch ein wenig mehr normalisiert werden.

gruß,
wahsaga

[nina]

hi,

Warum ist die kategorie vom Typ Text? Reichen 255 Zeichen nicht?
Ich würde eine varchar-Spalte für die Kategorie machen und dann einen Index über shop und kategorie.

die bezeichnung "kategorie" irritiert vermutlich etwas. das was Ihr meint, heißt in meiner tabelle shop_kategorie... in dem problem-feld stehen viele infos drin, die oftmals mehr als 255 zeichen lang sind.

Ist die Frage nicht eher, warum Kategorie überhaupt als Klartext (offenbar?) abgelegt wird?

da (derzeit) kaum eine kategorie doppelt vorkommt, macht eine "normalisierung" wenig sinn.

nun angesichts der gegebenen umstände bleibt meine frage,
ob/wie ein index sinn macht.?

[wahsaga]

hi,

die bezeichnung "kategorie" irritiert vermutlich etwas. das was Ihr meint, heißt in meiner tabelle shop_kategorie... in dem problem-feld stehen viele infos drin, die oftmals mehr als 255 zeichen lang sind.

Und was für welche wären das?

da (derzeit) kaum eine kategorie doppelt vorkommt, macht eine "normalisierung" wenig sinn.

Doch, macht sie.
_Dann_ hättest du nämlich eine Verknüpfung zum Textinhalt über eine einfache Integer-ID - und auf der lässt sich viel effektiver mit einem Index arbeiten, als auf einem Textfeld, wie Tom schon sagte.

nun angesichts der gegebenen umstände bleibt meine frage,
ob/wie ein index sinn macht.?

Für ein größeres Textfeld: Wohl kaum.
Der kostet vermutlich mehr, als er bringt.

gruß,
wahsaga

[Hans]

Hi !

da (derzeit) kaum eine kategorie doppelt vorkommt, macht eine "normalisierung" wenig sinn.

Naja, vielleicht kann man wenigstens den Shop normalisieren ?

1 = ShopA
2 = ShopB
...
155=Shop_was_weiss_ich

Dann in der Ursprungstabelle den Klartext-Name durch die Shop-Nummer ersetzen und auf diese Spalte einen Index setzen.

Danach ist die Abfrage:

...where Tabelle.Shop=Shop_zu_Klartext_tabelle.id and Shop_zu_Klartext_tabelle.name='ShopA';

nun angesichts der gegebenen umstände bleibt meine frage,
ob/wie ein index sinn macht.?

Stell Dir vor, Du greifst in eine große Kiste mit aber tausenden von Zahlen und suchst dabei alle Vorkommen von 1234 haben. Sprich, Du mußt immer die Kiste auskippen und jede Zahl <> 1234 in die Kiste zurück und die Treffer immer behalten. Wäre es dan nicht toll, die Zahlen aufsteigend sortiert an einer Schnur aufzuhängen ? Wenn Du 1234 suchst, weißt Du, daß Du nicht beim ersten Zentimeter der Schnur sondern bei 12,34 Meter anfangen mußt, weil die Verwaltung des Index das Dir sagt.

Bei Strings wird es etwas schwieriger (gut, daß dieser Text deutsch ist, denn String ist nicht nur Zeichenkette, sondern auch Schnur ;-)) Hier muß man versuchen, den String in eine Zahl zu "codieren" um ihn dann in das obige Verfahren zu bringen. Dabei kann es sein, daß die Verwaltung fast so groß wie die Tabelle wird und der Performance-Gewinn fraglich wird.

Ich hoffe, das hat Dir jetzt etwas geholfen.

Gruß

Hans

[nina]

hallo!
danke für die erklörung und das beispiel.
aber wenn ich es so mache, wie Du sagst, dann würde es doch wieder ne gewisse zeit in anspruch nehmen, bis die 2.bedingung geprüft wird, oder? somit wird ja noch auf ne zweite tabelle zugegriffen.

where Tabelle.Shop=Shop_zu_Klartext_tabelle.id and Shop_zu_Klartext_tabelle.name='ShopA';

andererseits kann ich mir den schritt fast sparen, wenn ich es im script in ner  variable speichere, wie der shop heißt und welche nr er hat...
wie viel zeit (%) würde ich mir denn ca sparen, wenn alles umgestellt wird auf querverweise vom typ short oder int?
danke

[Struppi]

aber wenn ich es so mache, wie Du sagst, dann würde es doch wieder ne gewisse zeit in anspruch nehmen, bis die 2.bedingung geprüft wird, oder? somit wird ja noch auf ne zweite tabelle zugegriffen.

where Tabelle.Shop=Shop_zu_Klartext_tabelle.id and Shop_zu_Klartext_tabelle.name='ShopA';
andererseits kann ich mir den schritt fast sparen, wenn ich es im script in ner  variable speichere, wie der shop heißt und welche nr er hat...

Genau so macht man das üblicherweise, dass du den eventuellen Klartext entweder nach der Anfrage umwandelst, also die ID aus der DB holst, oder aber schon bei der Abfrage (ich gehe jetzt mal von einem Formular aus) den Text anzeigst, aber nur die ID überträgst.

wie viel zeit (%) würde ich mir denn ca sparen, wenn alles umgestellt wird auf querverweise vom typ short oder int?

Viel. Bis sehr viel (da dein Feld das denkbar schlechtmöglichste ist)

Struppi.

[Alexander Brock]

Hallo Freunde des gehobenen Forumsgenusses,

wie viel zeit (%) würde ich mir denn ca sparen, wenn alles umgestellt wird auf querverweise vom typ short oder int?

Viel. Bis sehr viel (da dein Feld das denkbar schlechtmöglichste ist)

Und viel bedeutet hier viele Zehnerpotenzen.

Gruß
Alexander Brock

[Tom]

Hello,

welchen index soll ich nun für die genannten queries einrichten?
(shop=VARCHAR und kategorie=TEXT)

Ein Index auf ein Feld vom Typ TEXT ist immer eine Bremse, es sei denn, dass das Feld in Wirklichkeit berenzt ist.
Mit dem auf das VARCHAR-Feld sieht es aber nicht viel besser aus.

Allerdings nützt es auch nichts, die Felder zu CHAR umzuwandeln, wenn es auch nur ein Feld vom Typ TEXT oder VARCHAR in der Tabelle gibt. Dann wird nämlich das Feld vom Typ CHAR intern auch in ein VARCHAR umgewandelt.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom