[RalphS]

Naja, ob man da jetzt die MySQL-Systemtabellen nutzt, oder eigene, macht da jetzt nicht soo den Unterschied - außer natürlich von der Sicherheit her. Das DBMS wird kaum irgendwelche Zugriffsrechte erzwingen können, wenn es diese nicht kennt, oder keinen Benutzer kennt, oder die entsprechenden Relationen nicht kennt.

So oder so sind es Datensätze. Datenbanken kennen nicht viel anderes.

Trotzdem: Vorsicht mit MySQL. Das hat viele Fallstricke und die Implementierung der Transaktionssicherheit ist vermutlich der gravierendste (wenn man das überhaupt so nennen kann). GROUP BY ist ein anderer, insbesondere, wenn das verschachtelte Abfragen sind, die das verwenden.

Der einzige Vorteil, den ich sehe, ist der, daß MySQL weit verbreitet ist. Produktiv würde ich aber DRINGEND davon abraten und dann lieber PgSQL oder ein kommerzielles DMBS verwenden.

---

Fast übersehen. Die Datenbank kommt IMMER zuerst. Immer. Ein Frontend ist immer nur für eine TEILmenge der Datenbank da - daher ZUERST das Backend, DANN ein Frontend, und dann vielleicht noch zwanzig ANDERE Frontends.

Das Konzept liegt in den Daten, nicht bei den Benutzern.

Wenn Du Unterstützung beim Datenbankentwurf benötigst, Sturmi, laß es mich ggf. wissen.

Dieser Beitrag wurde von RalphS bearbeitet: 10. Juni 2014 - 19:11

[Sturmovik]

So tiefgehend hab ich mich noch nicht damit auseinandergesetzt. mySQL ist halt aufgrund der Verbreitung und des relativ einfachen Einstiegs die Basis, um erstmal den Umgang mit RDB zu lernen. Das gilt es dann auf andere DBMS zu übertragen, irgendwie sind die sich ja alle ähnlich, auch wenn die Feinheiten und die Syntax der Statements andere sind. (Besonders nervt mich TransactSQL mit dem ständigen "GO")

Deine Probleme, die du bei mySQL siehst, kann ich bisher nicht nachvollziehen. Ich kenn da einige Einsatzfälle im Produktivbetrieb, die bisher ohne Macken, Inkonsistenzen und dergleichen durchlaufen.

---

Danke für dein Angebot. Bei dieser Aktion steht die DB wie gesagt schon, ist mit Daten gefüllt und die Abfragen liegen in Notepad++ bereit
Fehlt nur der Web-Part.

Aber falls mich mal wieder so ein Projekt plagt, komm ich drauf zurück

Dieser Beitrag wurde von Sturmovik bearbeitet: 10. Juni 2014 - 19:18

[RalphS]

Naja, sie haben sich ja gebessert, aber...

Was ist denn

SELECT strasse, hausnummer FROM stadt GROUP BY strasse

? Laut MySQL ist das gültig, aber semantisch ist es Blödsinn und soll(te) eigentlich von einem DBMS nicht zugelassen werden.

Transaktionen gehen ja inzwischen... mit InnoDB. Aber schau einfach mal bei deren Homepage nach, wie das Featureset von InnoDB (transaction-safe) im Vergleich mit MyISAM (non-safe) dasteht. In einem Wort: man gibt mit InnoDB eine ganze Menge auf, wenn man das einsetzt. Soweit ich weiß, wird sich das auch auf absehbare Zeit nicht ändern. (Nach dem Sinn oder Unsinn, eine Engine per-TABELLE wählen zu können bzw. müssen - statt per-Datenbank --- fragen wir lieber gleich gar nicht).

Weiß gar nicht, ob die inzwischen CHECKs können.

---

Wenn der Entwurf schon steht, isses ja gut. Nur soviel, mit dem Entwurf steht und fällt die Integrität und auch die Performance der Datenbank. Und ganz wichtig: ein DBMS ist KEIN EXCEL. Einfach eine extra Spalte aufmachen wie in Excel ist da ganz schlechter Stil, wenn man sich das nicht gut überlegt hat. Redundanz = absolutes nogo in der Datenbank.

Dieser Beitrag wurde von RalphS bearbeitet: 10. Juni 2014 - 20:31

[Sturmovik]

Klar ist diese Gruppierung Blödsinn, ist aber auch nicht schädlich, wenn man mal vom Rechenzeit absieht.

Zu dem anderen sage ich vorerst, mangels Ahnung, nix.

[RalphS]

Na ich sag mal so, man stellt ja Fragen an das DBMS weil man was wissen will. Und wenn man so eine Abfrage wie die oben im Beispiel stellt und sich dann das Ergebnis aus ˋhausnummerˋ anschaut... kommt frei nach GIGO nichts dabei raus. Die Abfrage als solches ist ganz einfach falsch - da wurde die Hausnummer im GROUP BY vergessen, oder sie ist im SELECT zuviel, je nachdem was man haben wollte. Verwendet man aber die hausnummer aus dem Beispiel weiter, hat man sofort einen Fehler im System - und wenn man das sonst sauber macht, hat man diesen Fehler im Backend, wo ihn sämtliche Frontends aufgedrückt bekommen.

Aber zugegeben, ich bin da ein wenig voreingenommen.

Dieser Beitrag wurde von RalphS bearbeitet: 10. Juni 2014 - 20:45

[Sturmovik]

Zitat (RalphS: 10. Juni 2014 - 20:27)

Wenn der Entwurf schon steht, isses ja gut. Nur soviel, mit dem Entwurf steht und fällt die Integrität und auch die Performance der Datenbank. Und ganz wichtig: ein DBMS ist KEIN EXCEL. Einfach eine extra Spalte aufmachen wie in Excel ist da ganz schlechter Stil, wenn man sich das nicht gut überlegt hat. Redundanz = absolutes nogo in der Datenbank.

Volle Zustimmung. ®DB's haben mit Excel nur eins gemein, beide haben Tabellen. Das Vermeiden von Redundanzen hab ich ja schon damals auf die Spitze getrieben, als ich in Excel mal mit VBA mal ne Vereinsverwaltung gebaut habe (ja, damals war ich so masochistisch, heute weiß ichs besser )

Das kam mir in dem Kurs zugute, ich normalisier nen Datenbestand in einem Rutsch in die 3.NF durch, die ersten beiden kann ich kaum benennen.

Und eben der Vergleich mit Excel motiviert mich, mich zum Datenbankier weiterzuentwickeln. Wenn ich manche Excel-Dokumente in der Firma so sehe, bekomm ich das Grausen. Da werden 50MB und mehr duch halb Deutschland geschoben, um sie auf der Citrixfarm zu bearbeiten, weil der lokale Rechner nicht mehr die Power dafür hat
Richtige, bzw. geeignete Tools dafür einzusetzen traut sich keiner.

[Holger_N]

Zitat (RalphS: 10. Juni 2014 - 20:27)

Naja, sie haben sich ja gebessert, aber...

Was ist denn

SELECT strasse, hausnummer FROM stadt GROUP BY strasse

? Laut MySQL ist das gültig, aber semantisch ist es Blödsinn und soll(te) eigentlich von einem DBMS nicht zugelassen werden.

Wäre doch aber sinnvoll, wenn man aus der Stadt eine Liste aller vorkommenden Straßen braucht, inklusive einer gültigen Hausnummer aus der Straße.

[RalphS]

Blöderweise ist das dann buchstäblich irgendeine, sodaß wenn zwei Clients das anfragen, kriegen zwei Clients je nach Laune und Tageszeit unterschiedliche Antworten. Sowas darf da eigentlich nicht passieren.

Klar erleichtert es unter Umständen die Abfrage. Aber dann muß man halt wissen, was man tut... und hat natürlich immer noch das Problem, daß das Ergebnis insgesamt unbestimmt ist.

Für Dein Beispiel wäre es - meines Erachtens - sauberer, mit JOINs zu arbeiten.

(Mit DISTINCT sollte es auch gehen, bin aber grad überfragt ob und inwieweit man sich da mit DISTINCT auf nur EINE Spalte (statt alle) festlegen kann. Oder natürlich so, daß DISTINCT auf (strasse, hausnummer) angewendet wird - UNIQUE sozusagen. Kann das aber grad nicht testen. Daher halt den JOIN.)

Dieser Beitrag wurde von RalphS bearbeitet: 11. Juni 2014 - 12:09

[Holger_N]

Mit JOIN verknüpft man doch Tabellen, hier gibts ja nur die eine Tabelle "Stadt". Bei mir müßte im Zweifel nur noch ein ORDER BY rein, damit das Ergebnis eindeutig wird.

[RalphS]

Stichwort SELF JOIN.

Und ein ORDER BY funktioniert so nicht bei GROUP BY. Das ist eine Aggregatfunktion - die faßt die angegebenen(!) Spalten zusammen und zwar so, daß das Ergebnis bezogen auf die angegeben Spalten gruppiert wird (daher ja der Name).

Um das mal zu verdeutlichen: ein SELECT über straße, hausnummer und count(hausnummer) mit GROUP BY straße, hausnummer gibt sowas wie
straße - hausnummer - count(hausnummer)
wf-platz - 1 - 1
wf-platz - 2 - 1
wf-platz - 3 - 1
holgertor - 1 - 1
holgertor - 2 - 2
etc.

Was bedeutet das? Es bedeutet, daß es die straße namens X mit der Hausnummer Y genau Z mal in der Datenbank vorhanden ist - daher die 1 dahinten. Und beim Holgertor 2, wo da hinten auch eine 2 steht, deutet das darauf hin, daß es eben ZWEI "Holgertor 2"s gibt - vielleicht in einer anderen Stadt, das läßt sich mit dieser konkreten Abfrage nicht mehr herauslesen.

Ein "ORDER BY" an dieser Stelle würde entweder nach der Straße sortieren (no-op, weil für GROUP BY ein SORT bereits implizit ist) oder nach der Hausnummer (dasselbe, nur der sekundäre Sortierschlüssel) oder aber nach count(hausnummer) - und das bringt nix, weil es count(hausnummer) für jedes Paar (straße, hausnummer) nur genau einmal gibt. Und wenn wir die beiden Einträge für Holgertor 2 getrennt haben wollen, müssen wir die GROUP BY-Klausel anders gestalten (oder ganz weglassen).

Was mir grad so einfällt: es ist natürlich überhaupt kein Problem, "irgendeine gültige Hausnummer" statt über ein JOIN einfach über eine andere Aggregatfunktion zu ermitteln - sagen wir MIN() oder MAX() oder sonst eine Funktion, die aus der Spalte mit den Hausnummern genau einen Wert zurückgibt. Bin wohl etwas aus der Übung.

[Holger_N]

Jo, jo ich kenne den Unterschied zwischen ORDER und GROUP. Aber weil du schriebst, dass nach Lust und Laune unterschiedliche Ergebnisse zustande kämen und dann müßte man eben sortieren, damit immer das Gleiche Ergebnis kommt.

Ich habe eine Tabelle mit Adressen einer Stadt und ich möchte alle enthaltenen Straßen auflisten.

Dann macht die Abfrage:

SELECT strasse, hausnummer FROM stadt GROUP BY strasse

doch durchaus Sinn.

Ich will ja im Prinzip nur eine Abfrage machen "Welche Straßen gibt es?"
und diese Abfrage lediglich sortieren, damit die Abfrage von jedem "Abfrager" zum gleichen Ergebnis führt.

Dann sortiere ich nach beispielsweise Hausnummern:

SELECT strasse, hausnummer FROM stadt GROUP BY strasse ORDER BY hausnummer 

und schwupp müßte überall das Gleiche rauskommen.

Ging mir ja auch nur darum, dass die Abfrage an sich nicht sooo unsinnig ist. Heißt ja nicht, dass es für die Abfrage keine Alternativen gäbe. Das wäre ja sonst so, als schriebe jemand, dass 2 + 2 eine unsinnige Aufgabe ist und ein Anderer sagt - Wieso kann man doch schön rechnen und 4 rauskriegen und dann sagt der Übernächste - Nee 4 kann man mit 2 x 2 ja viel besser ausrechnen.