MySQL: Was ist effizienter?

[Serjosha.]

Hallo!

Ich bin dabei, eine MySQL DB zu entwerfen und frage mich, welche der folgenden Möglichkeiten in bezug auf Performance die bessere ist.
Die grundsätzliche Aufgabe besteht darin, verschiedene Inhalte geordnet nach Städten (Bundesländern, Bezirken) auszugeben. Die Haupttabelle wird vermutlich nicht mehr 5000 bis maximal 10000 Einträge haben.

Möglichkeit 1:
--------------

Die Ortsnamen werden direkt in die Content-Tabelle geschrieben.

select a,b,c from tbl_content where staedte_name = 'berlin'

Der Vorteil bei dieser Variante ist, dass man nur in einer Spalte suchen muss, um zu einem Ergebnis zu kommen. Der Nachteil ist, dass man den Typ "varchar" nehmen muss und die DB größer wird.

Möglichkeit 2:
--------------

Die Ortsnamen werden in eine separate Tabelle geschrieben, während die Content-Tabelle jeweils einen entsprechender Index enthält.

select a,b,c from tbl_content, tbl_staedte

where tbl_staedte.name = 'berlin'
   and tbl_content.staedte_id = tbl_staedte.id

Vorteil: hier kann man nun den Typ "int" verwenden, so dass die Tabelle kleiner wird, andererseits muss man mindestens zwei oder mehr Spalten in unterschiedlichen Tabellen miteinander vergleichen.

Das MySQL Handbuch rät ganz allgemein, möglichst kleine (effiziente) Typen zu nutzen, andererseits kostet eine Verknüpung auch Performance.

Was haltet Ihr für effektiver?

Serjosha

[TomIRL]

Zunächst ist die Performance nicht der Auschlagebende Punkt.
Befasse Dich dazu mal mit der indizierung bestimmter Spalten.
Ich würde reduntante Daten in jedem Fall vermeiden.
D.h. die Orte in eine separate Tabelle packen.
Stell Dir mal vor der Ortsname ändert sich und Du müßtest den Namen an allen Stellen in der DB ändern...
Nun magst Du sagen das ändert sich selten.. da magst Du recht haben aber denken wir nur an die Länderfusion und Gemeindefusionen in Berlin und Brandenburg.

Wie gesagt die Performance läst sich über indizierungen verbessern.
ToMIRL

[Serjosha.]

Zunächst ist die Performance nicht der Auschlagebende Punkt.

Richtig wäre: _Zuletzt_ ist die Performance nicht der ausschlaggebende Punkt.

Zunächst ist die Frage nach der Performance einfach diejenige, die mich interessiert, weil die Antwort u.a. in die Entscheidung mit einfließt, wie ich's am Ende mache.

Ich tendiere auch _sehr stark_ zur Variante mit der separaten Ortsabelle, allein schon deshalb, weil ich Nutzern die Möglichkeit biete, bestimmte Daten selbst einzutragen, was ohne diese Vorgabe zwangsläufig zu einem Durcheinander veschiedener Schreibweisen führen würde (Berlin, Bärlin, Bln-Kreuzberg usw).

Serjosha

[TomIRL]

Zunächst ist die Performance nicht der Auschlagebende Punkt.

Richtig wäre: _Zuletzt_ ist die Performance nicht der ausschlaggebende Punkt.

Nein.. Zunächts entwickelt man eine Datenbank nur auf dem Papier.
Dann trifft man anhand der Datenstruktur und der technischen Vorraussetzung eine Entscheidung für ein DBMS.
Man kann auch das Pferd von hinten aufzäumen, macht aber in aller Regel keine Sinn.

TomIRL

[wahsaga]

hi,

Nein.. Zunächts entwickelt man eine Datenbank nur auf dem Papier.
Dann trifft man anhand der Datenstruktur und der technischen Vorraussetzung eine Entscheidung für ein DBMS.
Man kann auch das Pferd von hinten aufzäumen, macht aber in aller Regel keine Sinn.

um es anders auszudrücken, und dabei im kontext der metapher zu bleiben:
man kann sich dabei schmerzhafte tritte einfangen :-)

gruß,
wahsaga

[Ilja]

yo,

Zunächst ist die Performance nicht der Auschlagebende Punkt.

ich kann nicht nachvollziehen, wie man das so allgemein beurteilen kann. für den einen ist es der ausschlaggebene punkt, für den anderen nicht. warum sollte es für alle gleich wichtig oder unwichtig sein ?

Befasse Dich dazu mal mit der indizierung bestimmter Spalten.

indizierung ist kein allheilmittel, dass immer vorteile bringt. in bestimmten fällen verlangsamt eine indizierung die suche und ganz besonders trifft das auf spalten wie ortsnamen zu, wo die kardinalität sehr niedrig ist. wenn man dann den falschen index erstellt, verliert man an performance.

Ich würde reduntante Daten in jedem Fall vermeiden.

ich nicht, ich würde es von fall zu fall entscheiden, die unterschiedliche vorgaben haben können.

Stell Dir mal vor der Ortsname ändert sich und Du müßtest den Namen an allen Stellen in der DB ändern...

ein befehl pro tabelle, wo die ortsnamen stehen ist nicht die welt und kann über ein script genauso einfach erledigt werden.

Wie gesagt die Performance läst sich über indizierungen verbessern.

nein, das ist nicht in allen fällen so. sicherlich in vielen, aber nicht generell

Ilja

[TomIRL]

»

Zunächst ist die Performance nicht der Auschlagebende Punkt.

ich kann nicht nachvollziehen, wie man das so allgemein beurteilen kann. für den einen ist es der ausschlaggebene punkt, für den anderen nicht. warum sollte es für alle gleich wichtig oder unwichtig sein ?

Weil die Performance, und da wirst Du mir recht geben, von 2 Sachen abhängt,
1. von der Datenstruktur
2. vom verwendeten DBMS

Da sich Serjosha aber aus welchen Gründen auch immer für MySQL entschieden hat kann die Performance nicht im Vordergrund stehen.

Das Du solche Sachen wie die Daten mal eben mit einem Skrpit austauschen hier schreibst, lässt eigentlich darauf schliessen, das Du noch nie mit einer etwas komplexeren DB zu tun hattes.
Ich glaube mich aber erinnern zu könne, dass Du umfassende Oracle Kenntnisse hast, wo bestimmt Objekthandles tatsächlich anders gemacht werden können.
Nur Serjosha benutzt MySQL.
TomIRL

[Ilja]

yo,

Weil die Performance, und da wirst Du mir recht geben, von 2 Sachen abhängt,

1. von der Datenstruktur
2. vom verwendeten DBMS

du machst den gärtner zum propheten. sicherlich gibt es viele dinge, welche die performance beeinflussen können. das sind aber mittel um das ziel zu erreichen. wenn mir ein kunde sagt, performance ist das wichtigste ziel und er mir sagt, ich soll mysql benutzen, werden ich ihm nicht sagen, die performance ist nicht der ausschlagebende punkt. natürlich muss ich mir eine geeignete struktur überlegen, aber trotzdem bleibt das ziel numero uno die performance, weil er mir diese vorgabe gibt.

Da sich Serjosha aber aus welchen Gründen auch immer für MySQL entschieden hat kann die Performance nicht im Vordergrund stehen.

wie kann man den für andere beurteilen, was man für wichtig zu halten hat und was nicht. ich sehe keinen grund, warum jemand nicht auf performance wert legt und mysql benutzt.

Das Du solche Sachen wie die Daten mal eben mit einem Skrpit austauschen hier schreibst, lässt eigentlich darauf schliessen, das Du noch nie mit einer etwas komplexeren DB zu tun hattes.

sorry, ich kann deine schlüsse nicht nachvollziehen.

Ilja

[TomIRL]

Das Du solche Sachen wie die Daten mal eben mit einem Skrpit austauschen hier schreibst, lässt eigentlich darauf schliessen, das Du noch nie mit einer etwas komplexeren DB zu tun hattes.

sorry, ich kann deine schlüsse nicht nachvollziehen.

Wenn Du Redundanzen zuläst, dann weist Du in Komplexen DB`s irgendwann nicht einmal mehr anstazweise wo Dein Skript überhaupt suchen soll.

Du willst nicht...
Das ist ein Unterschied.
und mir ist es für Streiterei eindeutig zu warm.
Viel Spaß noch
TomIRL

[Ilja]

yo,

Wenn Du Redundanzen zuläst, dann weist Du in Komplexen DB`s irgendwann nicht einmal mehr anstazweise wo Dein Skript überhaupt suchen soll.

ich würde den schluss nicht ziehen, dass funktionierende, komplexe datenstrukturen keine redundanzen haben können.

und was deinen tipp zu indizieren betrifft, so würde ich ihm sogar davon abraten, falls mysql nur b-tree indezes kennt. das macht es nämlich eventuell nur noch langsamer. und das hängt nicht mit der wärme des wetters zusammen.

Ilja

[TomIRL]

yo,

Wenn Du Redundanzen zuläst, dann weist Du in Komplexen DB`s irgendwann nicht einmal mehr anstazweise wo Dein Skript überhaupt suchen soll.

ich würde den schluss nicht ziehen, dass funktionierende, komplexe datenstrukturen keine redundanzen haben können.

»»
Hab ich das behauptet?
Es gibt die 5 Normalform die noramlisiert überflüssige Sachen zurück.

und was deinen tipp zu indizieren betrifft, so würde ich ihm sogar davon abraten, falls mysql nur b-tree indezes kennt. das macht es nämlich eventuell nur noch langsamer. und das hängt nicht mit der wärme des wetters zusammen.

http://www.mysql.com
Wenn Du schon zum Thema postest dann mache Dich wenigstens vorher schlau, an statt hier nur dumm rumzuprovozieren.
Die Informationen sind alle verfügbar sogar in deutsche Sprache..

*Plonk*
TomIRL dem es wirklich zu dumm geworden ist.

[Ilja]

yo,

Wenn Du schon zum Thema postest dann mache Dich wenigstens vorher schlau, an statt hier nur dumm rumzuprovozieren.

ich habe nur eine andere meinung zum dem thema und komme zu anderen schlüssen. ich bin kein mysql experte, aber ich konnte neben b-index nur den spatial index finden und der löst das problem nicht. vielleicht weisst du ja da mehr, aber ein b-index macht die suche grosser wahrscheinichkeit nach langsamer.

Ilja

[Cheatah]

Hi,

Was haltet Ihr für effektiver?

Du hast eine 1:1-Beziehung vorliegen. Das(!) Mittel, dies in einem relationalen Datenmodell abzubilden, wird "Spalte" genannt.

Cheatah

[TomIRL]

Hi Cheate

Was haltet Ihr für effektiver?

Du hast eine 1:1-Beziehung vorliegen. Das(!) Mittel, dies in einem relationalen Datenmodell abzubilden, wird "Spalte" genannt.

Woher weist Du das eine 1:1 Beziehnug vorliegt?
Es könnte eine ein 1:n Beziehung vorliegen.

Ich verstehe Deine Antwort nicht so richtig..
erkläre mal bitte.

[Cheatah]

Hi,

Woher weist Du das eine 1:1 Beziehnug vorliegt?

ich habe die Fragestellung so verstanden.

Cheatah

[Serjosha.]

Hallo,

Woher weist Du das eine 1:1 Beziehnug vorliegt?

ich habe die Fragestellung so verstanden.

Es ist keine 1:1 Beziehung.

Serjosha

[TomIRL]

Hallo,

Woher weist Du das eine 1:1 Beziehnug vorliegt?

ich habe die Fragestellung so verstanden.

Es ist keine 1:1 Beziehung.

Um  so etwas beurteilen zu können reichen aber beim genauen lesen Deine Angaben nicht aus. Es bleibt eine Menge Interpretationsspielraum.
Übrigens hängt die Entscheidung ob eine neue Tabelle oder nicht nahezu ausschliesslich davon ab, ob eine 1:1 oder 1:n Beziehung vorliegt.

Viele Grüße asu Berlin
TomIRL

[Ilja]

yo,

Übrigens hängt die Entscheidung ob eine neue Tabelle oder nicht nahezu ausschliesslich davon ab, ob eine 1:1 oder 1:n Beziehung vorliegt.

das würde ich anders sehen. es gibt inzwischen viele möglichkeiten die daten und die beziehungen abzuspeichern. und dadurch ergeben sich für verschiedene situationen verschiedene umsetzungen. ohne eine zielvorgabe würde ich das so pauschal nicht sagen, jedesmal eine neue tabelle anzulegen, wenn eine 1:n beziehung vorliegt.

Ilja

[TomIRL]

yo,

Übrigens hängt die Entscheidung ob eine neue Tabelle oder nicht nahezu ausschliesslich davon ab, ob eine 1:1 oder 1:n Beziehung vorliegt.

das würde ich anders sehen. es gibt inzwischen viele möglichkeiten die daten und die beziehungen abzuspeichern. und dadurch ergeben sich für verschiedene situationen verschiedene umsetzungen. ohne eine zielvorgabe würde ich das so pauschal nicht sagen, jedesmal eine neue tabelle anzulegen, wenn eine 1:n beziehung vorliegt.

Na dann kläre mich mal auf RDBSM MySQL oder Alternativ auch PostGre.
Welche Möglichkeiten hätte ich?

TomIRL

[Ilja]

yo,

Na dann kläre mich mal auf RDBSM MySQL oder Alternativ auch PostGre.
Welche Möglichkeiten hätte ich?

datenredundanz ?

Ilja

[wahsaga]

hi,

Vorteil: hier kann man nun den Typ "int" verwenden, so dass die Tabelle kleiner wird, andererseits muss man mindestens zwei oder mehr Spalten in unterschiedlichen Tabellen miteinander vergleichen.

ich sehe an dieser stelle auch kein großes problem, zwei abfragen daraus zu machen.

zuerst die abfrage, welcher "int-wert" denn nun in der städte-tabelle zu "berlin" gehört.

und dann anschliessend eine abfrage auf die content-tabelle, in die diese zuvor ermittelte integer-ID der stadt dynamisch eingesetzt wird.

ob das performanter ist als deine lösung, hängt natürlich davon ab, wie gut MySQL so eine abfrage intern optimiert.
es ist auch durchaus denkbar, dass das intern in zwei solche einzel-abfragen gesplittet wird, wie ich sie getrennt an die DB absetzen wollte. wenn das der fall ist, wäre deine lösung sogar wieder die (minimal) performantere - und die mit weniger script-aufwand natürlich.

aber um diese frage zu beantworten, müsste man sich genauer im manual einlesen, wie MySql optimiert - dass ich dazu angesichts des wetters eher unlustig bin, sei mir bitte nachgesehen :-)

gruß,
wahsaga

[Andreas-Lindig]

Hallo,

Möglichkeit 2:

Die Ortsnamen werden in eine separate Tabelle geschrieben, während die Content-Tabelle jeweils einen entsprechender Index enthält.

kann ich so gar nicht nachvollziehen. Ein Index über die ID-Spalte und in den nicht-indizierten Ortsnamen willst Du suchen? *lol*
Etwas mehr Erklärung fände ich gut.

Gruß, Andreas