PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Wie viele Tabellen kann man miteinander verknüpfen


Sertl
15.01.2004, 12:31:40
Hi,

ich müsste 8 Tabellen miteinander verknüpfen. In Access funktioniert es. Allerdings, wenn ich die Abfrage 1zu1 in MySQL übernehme, gibt er mir nur aus "SQL-Befehl wurde erfolgreich ausgeführt...". Anzeigen tut er mir aber kein Recordset.


Hier ich poste einfach mal, den SQL-Befehl:


SELECT f.bez AS fbez, d.bez AS dbez, sfest, mfest, afd.id AS afd_id
FROM art, form AS f, dekor AS d, art_form_dekor AS afd, dekorkriterium AS dk, dekor_artikel AS da, artikel AS a, artikelbezeichnung AS ab
WHERE art.id = afd.artnr and afd.fnr = f.id and afd.dnr = d.id and afd.id = dk.afdnr and
afd.id = da.afdnr and da.anr = a.id and a.beznr = ab.id and dk.knr = 3 and (f.bez like '*Mer*' or d.bez like '*Mer*' or ab.bez like '*Mer*')
GROUP BY f.bez, d.bez, sfest, mfest, afd.id, f.nummer, d.nummer
ORDER BY f.nummer, d.nummer;


In einer etwas abgespeckten Form funktioniert er ja.

mfg

Andreas

feuervogel
15.01.2004, 12:35:02
ich weiß, nicht das was du wissen willst, aber wie wäre es, alles in eine tabelle zu packen?

Sertl
15.01.2004, 12:48:54
Ich möchte wissen, wieso dieser SELECT unter Access funktioniert und mir eine Lösungsmenge ausgibt.
Unter MySQL aber nicht.
Schafft es MySQL vielleicht nicht 8 Tabellen miteinander zu verknüpfen?

Und wie meinst du das mit alles in eine Tabelle packen?

diver-network
15.01.2004, 13:57:10
Hi,

Access und MySQL haben z.T. unterschiedliche SQL Syntax. Dies merkst Du z.B. auch bei generischen Zeichen (= *).
Lösungsvorschlag zu Deinem Problem, aber ungetestet:

SELECT ... s.sfest,s.mfest,...
FROM art INNER JOIN art_form_dekor AS afd ON art.id = afd.artnr INNER JOIN ...
WHERE f.bez like '*Mer*'...

Sprich: Tabellen mit INNER JOIN verknüpfen und dabei darauf achten, daß Du nach jedem INNER JOIN gleich die richtigen Bedingungen mit ON anführst. Im Moment ist z.B. "art" zuerst mit "form" verbunden, in der WHERE Klausel ist "art" aber mit "afd" verbungen. Das kann eventuell der Fehlergrund sein.

HTH,

Andy

Sertl
15.01.2004, 14:23:22
Habe jetzt die "=" in INNER JOIN geändert.
Nutzt auch nichts, es kommt immer noch die Meldung
"Ihr SQL-Befehl wurde...". Eine Lösungsmenge findet er immer noch nicht.

Ich dachte schon ich hätte die Testdaten aus Access falsch übernommen, aber dem ist nicht so.


SELECT f.bez AS fbez, d.bez AS dbez, d.sfest, d.mfest, afd.id AS afd_id
FROM art INNER JOIN art_form_dekor as afd ON art.id = afd.artnr
INNER JOIN form as f ON afd.fnr = f.id
INNER JOIN dekor as d ON afd.dnr = d.id
INNER JOIN dekorkriterium as dk ON afd.id = dk.afdnr
INNER JOIN dekor_artikel as da ON afd.id = da.afdnr
INNER JOIN artikel as a ON da.anr = a.id
INNER JOIN artikelbezeichnung as ab ON a.beznr = ab.id
WHERE dk.knr = 3 and (f.bez like '*Mer*' or d.bez like '*Mer*' or ab.bez like '*Mer*')
GROUP BY f.bez, d.bez, sfest, mfest, afd.id, f.nummer, d.nummer
ORDER BY f.nummer, d.nummer;

feuervogel
15.01.2004, 14:35:34
ich meine, dass es möglich ist, alle daten (auch wenn ich deinen speziellen fall nicht kenne) in einer tabelle zu speichern...dann fällt das ewige verknüpfen weg.

diver-network
15.01.2004, 14:49:34
Hi,

versuch mal, das *- Zeichen bei like '*Mer*' in %- Zeichen zu ändern.
Also:

... LIKE '%Mer%'

Das hat bei mir auch immer wieder zu Problemen geführt, da ich an Deiner SQL Syntax auf die Schnelle keine Fehler sehen kann.

HTH,

Andy

P.S.: @feuervogel: Klar kann man alle Daten in einer Tabelle speichern. Sinnvoll ist das aber in den meisten Fällen nicht. Such mal im Google unter dem Stichwort "Normalisierung" nach.

Sertl
15.01.2004, 15:01:56
Danke,

jetzt gibt er mir endlich das aus, was er ausgeben soll.

Noch mal gibthx.

mfg

Andreas

feuervogel
15.01.2004, 18:27:45
@diver-network: klaro, über die verschiedenen normalformen hatte ich schon mal was gelesen... aber ich arbeite grade (und in zukunft) an einem projekt, bei dem etwa 50-80 db abfragen pro script-aufruf stattfinden würden und das mit insgesamt etwa 20-40 tabellen...da hab ich lieber eine tabelle und sortiere dann etwas rum...außerdem geben dir die 8 tabellen schon mal eine gewisse struktur vor, nach der du dich in zukunft richten musst...

meikel
15.01.2004, 19:30:45
Original geschrieben von diver-network
P.S.: @feuervogel: Klar kann man alle Daten in einer Tabelle speichern. Sinnvoll ist das aber in den meisten Fällen nicht. Such mal im Google unter dem Stichwort "Normalisierung" nach.
Klar, unter dem Stichwort findet man einiges, wie man die Antwortzeit seiner Webapplikation in Richtung unendlich steigern kann.

Oberste Prämisse bei der Webprogrammierung ist die Zeit, die LAMP oder WAMP benötigen, um das letzte Byte auszuliefern. Selbst ich, der ich relativ gemütlich bin, verkneife mir den Besuch von Webseiten, die länger als 1 sec. brauchen, um den Schotter zusammenzusuchen.

DB Zugriffe kosten Zeit und sind demzufolge zu minimieren. Was auf einem DBMS wie Oracle oder MSSQL Sinn macht, weil die neben Standard-SQL noch eine Menge mehr können, ist, wird es 1:1 auf MySQL-3 und MySQL 4.0 übertragen, tw. haaresträubender Unfug, mit dem man ggf. auch an der Funktionstüchtigkeit seines Systems kratzt.

Ein WBB Forum zB. kann ganz fix die komplette Blechkiste lahmlegen, wenn pconnect erlaubt wird, ein paar unwichtige Hacks (mit vielen JOINs) eingebaut werden und sich zeitgleich 100-150 schreibwütige User auf der Kiste tummeln. Soviel RAM paßt da nicht rein, um die Monster-Joins im RAM abzuhandeln, damit die Kiste nicht swappt.

Bei Windows ist sowas allerdings Wurscht - man ist ja eh daran gewohnt, daß das alles etwas länger dauert...

diver-network
16.01.2004, 10:48:34
Hi zusammen,

klar, JOINS kosten auch Zeit und Rechenpower.
Allerdings kosten redundante Daten Speicherplatz (ok, kostet nicht viel), ebenfalls Performance, da die Abfrage mehr Daten durchforsten muß (ok, gute Indizes helfen da auch, diese kosten beim INSERT und UPDATE aber auch Performance) und, was ganz ganz wichtig ist: Sobald man mal etwas ändern muß (z.B. Stadt 1 beschließt, in Zukunft Stadt 2 zu heißen), muß man ziemlich viele Daten ändern, was dann im schlimmsten Fall die Kiste lahm legt und, noch schlimmer, eventuell zu Inkonsistenzen im Datenbestand führen, da man eine Ecke vergessen hat, wo man die Änderung ebenfalls durchführen muß.

Aber, lassen wir das "streiten", eine Normalisierung auf Teufel komm raus ist auch nicht sinnvoll. Vor allem bei kleinen Datenmengen. Ich habe z.B. bei meiner Webseite und der dortigen Datenbank die Postleitzahlen und Orte auch nicht in eine extra Tabelle genommen, wie es eigentlich sein sollte. Sprich: Der Ort A kommt halt in der Tabelle mit den Tauchschulen mehrfach vor. Aber, sollte der Speicherbedarf mal steigen (träum), werde ich die Orte und Postleitzahlen auslagern und muß dann halt einen JOIN mehr machen.

Gruß,

Andy

meikel
16.01.2004, 16:33:39
Original geschrieben von diver-network
Aber, lassen wir das "streiten", eine Normalisierung auf Teufel komm raus ist auch nicht sinnvoll.
Das wollte ich damit darlegen.

Ein kleines Beispiel:
nehmen wir mal an, es gibt eine Tabelle namens content, die viele mehr oder weniger interessante Texte beinhaltet, und eine Tabelle namens visits, in der die Zugriffe auf die Texte gezählt werden. Faule Hunde (wie ich zB.) würden die Tabelle contents mit einer Spalte visits erweitern, die Tabelle visits killen und die Scripte anpassen.

Bei der darauf folgenden Diskussion mußte ich mich mehrfach gegen das Schlagwort "Normalisierung" wehren.

btw: es gibt noch schlimmere Beispiele...