ER Diagramm SQL Abfrage erstellen im Vergleich zu Access Beziehungen

[v2afrank]

Hallo vorweg erst einmal ich kenne mich mit Datenbank Design überhaupt nicht mehr aus. (Ich werde alt)

Bisher hatte ich ganz einfache Datenbanken die ich in Access angelegt habe. Dort habe ich dann im Prinzip meine ER Diagramme mit Hilfe der Beziehungen realisiert. Der große Vorteil war für mich dass bei der Erstellung der Abfrage die Beziehungen der Tabellen untereinander bereits vorgegeben waren. Ich brauchte also die Joins nicht selber schreiben.
Jetzt haben wir ein anderes Projekt in dem falls es Lizenztechnisch möglich ist (wird gerade noch geklärt) MySql einsetzen werden. Ich bin also in der MySQL Workbench hingegangen und habe ein ER-Diagramm modeliert mit dem ich auch zufrieden bin. Jetzt fange ich an einzelene Abfragen zu erstellen die wir später benötigen werden. Dabei stelle ich fest dass die Beziehungen der Tabellen untereinander hier gar nicht vorhanden sind. Ist dies so richtig ? Hat also das ER Diagramm hier wirklich nur den Zweck der Dokumentation und Planung ? (Klar hilft mir hier das ER Diagramm auch bei der Realisierung) Aber es unterstützt mich nicht automatisch wie Access

[Perlsau]

Zitat:

Zitat von v2afrank (Beitrag 1283708)

Jetzt haben wir ein anderes Projekt in dem falls es Lizenztechnisch möglich ist (wird gerade noch geklärt) MySql einsetzen werden.

Zu deiner eigentlichen Frage vermag ich nichts zu sagen, doch hinsichtlich der bekannten Lizenzfalle bei MySQL schon: Die Verwendung von MySQL ist kostenlos, das Weitergeben der Libmysql.dll erfordert eine kostenpflichtige Lizenz. Bei Verwendung z.B. der Devart-DB-Komponenten wird diese DLL jedoch nicht benötigt, ebenso bei Einsatz von MariaDB, für die es inzwischen eine kostenlose DLL gibt. Ich würde übrigens Firebird empfehlen ...

Nachzulesen z.B. hier, da, dort und auch noch woanders ...

[Dejan Vu]

Access ist für Dummies. Deine Abfragen musst Du schon selbst schreiben. Es gibt für andere RDBMS (SQL-Server z.B.) Query-Designer, die die FK-Beziehungen bei der Auswahl mit berücksichtigen. Ich kenne auch ein Codecompletion-Tool für SSMS, das beim schreiben eines 'JOIN' die Kandidaten auflistet und beim Schreiben des 'ON' Schlüsselwortes die entsprechenden Verknüpfungen gleich mit, aber eine Query viel mehr ist, als nur ein schnödes JOIN auf FK-Beziehungen, ist es besser, man tippt die paar Zeichen selbst.

[jobo]

Zitat:

Zitat von v2afrank (Beitrag 1283708)

Ich bin also in der MySQL Workbench hingegangen und habe ein ER-Diagramm modeliert mit dem ich auch zufrieden bin. Jetzt fange ich an einzelene Abfragen zu erstellen die wir später benötigen werden. Dabei stelle ich fest dass die Beziehungen der Tabellen untereinander hier gar nicht vorhanden sind. Ist dies so richtig ? Hat also das ER Diagramm hier wirklich nur den Zweck der Dokumentation und Planung ? (Klar hilft mir hier das ER Diagramm auch bei der Realisierung) Aber es unterstützt mich nicht automatisch wie Access

Ich kenne die Workbench nicht, aber Deine Frage ist auch etwas unklar.
Was fehlt Dir?
- foreign key constraints (als Ergebnis der Modellierung)
- die komplette Spalte für den Fremdschlüssel?
- der access Komfort bei der Verknüpfung von Tabellen im Query tool

Wo erstellst Du nun die Abfragen?
Immernoch unter Access?
Das wäre
1. möglich, nachdem Du Tabellen oder Views als ODBC (oder so) -Verknüpfungen angelegt hast.
2. könnte ich mir denken, dass Du auch hier Access wieder den gewohnten "Komfort" erlangst, wenn Du unter Access die Beziehungen neu malst.
3. tut es auch nicht weh, einen Join selbst in eine Abfrage einzutragen (weder unter Access noch mit anderen Werkzeugen).

[v2afrank]

Danke erst einmal für Eure Antworten.
Was mir fehlt ist der Access Komfort bei der Verknüpfung von Tabellen im Query tool.
Wobei ich mir da jetzt schon mit dem Visual Studio beholfen habe. Der Query Editor macht es ähnlich wie Access. Allerdings werden die Beziehungen nicht aus der MySql Datenbank übernommen.
Vielleicht gibt es ja speziell für MySQL auch noch was besseres.

Zu der Lizenzfrage. Erst mal sehr interessant. Das ist für mich und die Libmysql.dll von Bedeutung. Allerdings läuft der Server auf einem embedded Linux und dafür müssen wir auch noch die Lizenzbedingungen klären. MariaDB ist sicherlich auch noch eine alternative allerdings haben wir die noch nicht im Buildroot

[Dejan Vu]

Wenn ihr euch bereits auf mysql eingeschossen habt, dann prüfe doch, ob es nicht bessere IDE für mysql gibt.
Auf der anderen Seite: Das geht so schnell mit dem 'per hand tippen', da lohnt es kaum, andere Klimmzüge zu machen.

Allerdings ist es nicht leicht, auf gewohnten Komfort zu verzichten, wer will das schon?

[v2afrank]

Da hast Du Recht. Wer will das schon.
Auf MySQL haben wir uns noch nicht eingeschossen, aber momentan geht die Tendenz stark dahin. Hauptsächlich wegen dem embedded Linux. Zuerst wollten wir Postgresql nehmen. Da haben wir aber festgestellt dass selbst bei Memorytabellen in der Datenbank der WAL ins Dateisystem geschrieben wird. Bei zwei bis drei Schreibvorgängen in der Sekunde ist es absehbar wann unser Flashspeicher kaputt ist.
Als nächstes haben wir uns SQLite angeschautDas war erstaunlicherweise nicht perfomant genung. (Abgesehen von nicht ausreichenden Lockmechanismen)
Jetzt kam als nächstes MySQL. Das hatten wir ursprünglich wegen der Lizenz ausgeschlossen. Aber wir können dort Tabellen in der Datenbankanlegen die nur im Speicher sind während andere Tabellen die extrem selten beschrieben werden im Dateisystem sind. Außerdem ist es mit Abstand die schnellste Datenbank für unseren Anwendungsfall.
Wir sind parallel auch noch dabei die MariaDB auf dem Linux zu installieren, oder eine Key-Value Datenbank zu nehmen, wo wir aber auf einiges an Komfort verzichten müssten

[p80286]

Zitat:

Zitat von v2afrank (Beitrag 1283714)

Danke erst einmal für Eure Antworten.
Was mir fehlt ist der Access Komfort bei der Verknüpfung von Tabellen im Query tool.
Wobei ich mir da jetzt schon mit dem Visual Studio beholfen habe. Der Query Editor macht es ähnlich wie Access. Allerdings werden die Beziehungen nicht aus der MySql Datenbank übernommen.
Vielleicht gibt es ja speziell für MySQL auch noch was besseres.

Für Quick'nDirty Abfragen setze ich manchmal Access als Frontend für Oracle und MSSQL-Datenbanken ein, da hatte ich bisher eigentlich immer die Beziehungen zur Verfügung aber sobald man seine DB einigermaßen kennt, ist selber tippen immer effizenter, insbesonders bei Tabellen, die beinahe nur aus schlüsseln bestehen.

Gruß
K-H

P.S.
Alter ist keine Hinderungsgrund, macht es nur ein wenig langwieriger, weil man (ich) so bequem geworden ist(bin)

[Dejan Vu]

Bei 'mysql ist sauschnell' prüft doch bitte, ob die storage engine immer noch diese Freie nicht Sichere engine ist ist. Das war für mich damals das k.o. Kriterium (Rechnerabsturz => Daten futsch). Ich will hier aber keine Diskussion darüber anfangen, da eure select procedure offenbar recht zielführend ist.

Bezüglich der Queries... denk mal drüber nach, wie oft Du Queries schreibst. Ich schreibe täglich so 0-200 und ich nehme nie irgend einen Query-Designer. Das dauert einfach viel zu lange. Die Code Completion reicht mir völlig, aber selbst die nervt, wenn man die Tabellen genau kennt.

[mkinzler]

Zitat:

Bei zwei bis drei Schreibvorgängen in der Sekunde ist es absehbar wann unser Flashspeicher kaputt ist.

Dann würde ich den durch besseren ersetzen.

[v2afrank]

Die Storage Engine die wir da benutzen ist Memory. Die Daten in dieser Tabelle selber sind nicht sicherungswürdig. Es sind reine Messwerte die ständig durch unser System aktualisiert werden. Sie sollen halt nur möglichst schnell zur Anzeige kommen. Nach einem Neustart interessieren die alten messwerte auch nicht mehr.Darum können wir dort super mit der Memorytablle leben. Bei anderen Daten ist es etwas anderes. Dort setzen wir dann auch MyISAM als storage engine ein.
Mit dem schreiben glaub ich Dir gerne. Nur bisher habe ich nicht viele geschrieben, darum geht es mir noch nicht so leicht von der Hand. Ich glaube aber auch dass es später sehr gut von Hand geht

[v2afrank]

Zitat:

Zitat von mkinzler (Beitrag 1283744)

Dann würde ich den durch besseren ersetzen.

Warum. Wenn wir mit dem Austausch der Datenbank das gleiche erreichen können ?

[Sir Rufo]

Zitat:

Zitat von Perlsau (Beitrag 1283709)

Zitat:

Zitat von v2afrank (Beitrag 1283708)

Jetzt haben wir ein anderes Projekt in dem falls es Lizenztechnisch möglich ist (wird gerade noch geklärt) MySql einsetzen werden.

Zu deiner eigentlichen Frage vermag ich nichts zu sagen, doch hinsichtlich der bekannten Lizenzfalle bei MySQL schon: Die Verwendung von MySQL ist kostenlos, das Weitergeben der Libmysql.dll erfordert eine kostenpflichtige Lizenz. Bei Verwendung z.B. der Devart-DB-Komponenten wird diese DLL jedoch nicht benötigt, ebenso bei Einsatz von MariaDB, für die es inzwischen eine kostenlose DLL gibt. Ich würde übrigens Firebird empfehlen ...

Nachzulesen z.B. hier, da, dort und auch noch woanders ...

Wenn der Zugriff über PHP erfolgt auf einem Linux-System, ist da nicht die Frage nach der libmysql.dll obsolet?

[v2afrank]

Momentan ist die Frage nach der libmysql.dll sicherlich obsolet. Ich bin mir aber noch nicht sicher ob später nicht auch noch ein direkter Zugriff ermöglicht werden soll. Dann spielt das noch eine Rolle. Momentan ist aber die Frage was MySQL auf dem embedded Linux kosten wird.

<Edit>
Ich seh gerade der Hint bei MySQl zeigt kostenlose/kostengünstige Datenbank an. Dann sollte das ja kein Problem sein.
</Edit>