Idee um Datenbankprogrammierung zu erlernen

[yankee]

http://dev.mysql.com/tech-resources/crash-me.php
Den Link schreibe ich mal nach ganz oben, damit ihr ihn nicht überseht. Das ist natürlich von der Quelle MySQL und daher mit Vorsicht zu betrachten. Und wenn ich da Interbase 7 mit MySQL Vergleich, dann kommt da auch wieder was unrealisitisches raus. Demnach kann Interbase 7 nichtmal BigInt usw. Im ganzen könnte man demnach da garnichts mit anfangen. Und Interbase 7 und Firebird sollte doch ungefähr gleich sein...

Aber egal, ich verlinke hier nochmal zu einem Thread mit realistischereren Diskussionsteilnehmern:

http://www.issociate.de/board/post/1...ener_DBMS.html

[jensw_2000]

Ich liebe diese Diskussionen ....

Suche dir einfach ein RDBMS:
- das du auch fur kommerzielle Projekte kostenlos nutzen darfst.
- bei dem die der SQL-Dialekt gefällt.
- auf das du möglichst ohne kostepflichtige Komponenten aus Delpi zugreifen kannst.
- bei dem es nicht 2-3 mal im Jahr einen Releasewechsel gibt, wobei sich der
Funktions- / Befehlsumfang jedesmal drastisch verändert


Jetzt aber mal ein paar andere Ratschläge.

Wenn man mit der Datenbankprogrammiereung anfängt macht idR viele taktische Fehler, die sich im späteren Projektverlauf nur mühsam korrigieren lassen. Dehlalb hier mal ein paar kleine Hinweise, die sich aus meiner Sicht als sinnvoll herausgestellt haben:

Dein RDBMS ist schlau, schnell und will was zu tun haben. Deshalb versuche möglichst viel Datenbanklogik auf den Server auszulagern.

Falls dein RDBMS Stored Procedures unterstützt, dann baue die mit den SP's "Schnittstellen" zwischen der DB und deinen Applikationen. Dann bleibt dein Projekt wartungsfreundlicher, weil du nicht nach jedem kleinen DB-Update eine neue Programmversion herausbringen musst. Zudem lässt sich der SQL-Code in der DB zentral, und im laufenden Betrieb, über SQL-Script-Importe warten.

Vermeide möglichst die Verwendung von "hart verbundenen" DB-Komponenten (Querys, Tabellen, SPs ...) in deinen Applikationen. Erstelle die Verbindungskomponenten zur Laufzeit.

Finger weg von Query-Buildern ...
Es ist zwar am Anfang leichter seine Abfragen in einer GUI zusammenzuklicken, aber es hat auch seine Nachteile.
Der generierte SQL-Code meist schlecht optimiert. Zudem lernt man sehr wenig dabei und man sucht sich den Wolf, wenn größere Abfragen oder SP's spontal falsche Ausgaben bringen.

Versuche generell, die Rückgabe-Datenmengen deiner Abfragen so klein wie möglich zu halten. Das sichert eine hohe Perfornamce.

Vermeide die Verwendung von Views in der deinen SQL-Scripten.
Verjoine lieber in jedem einzelnen SQL-Script die benötigten Tabellen nach Bedarf.
Views sind langsam, nicht immer sofort aktuell, sie fördern einen schlechten Programmierstil und sind zudem noch unflexibel.

Schöne Grüße,
Jens

[Bernhard Geyer]

Zitat von alzaimar:

Mit anderen Worten: MySQL ist die Schippe in einem Buddelkasten, FB, PostGreSQL und die MSDE dagegen ein Bulldozer!

MSDE und Bolldozer? Schon mal mit großen Datenbanken gearbeitet. Da stößt du mit der MSDE auf bewußte Grenzen. Und das der MS-SQL-Server bis zur 2000er-Version nicht mal das Multi-Versions-Konzept kann führt auch zu einigen Beschränkungen.

Zitat von alzaimar:

@Tubos: Der Performancegewinn bei ordendlichen DBMS ggü MySQL liegt bei ca. 100x. Nicht 100%, sondern 100 mal schneller. Das ist kein Witz. Der o.g. Student benötigte für eine Operation à la MySQL ca. 5 minuten, jetzt sind es 0,3 Sekunden. Check doch mal www.tpc.org.

Dann hat dein Student etwas falsch gemacht. Wir selbst verwenden MySQL, Oracle und MS-SQL-Server und jede der Datenbanken hat Stärken und Schwächen. Bei kleineren DB's (die ich Testen konnte) nehmen sich die Datenbanken bezüglich Geschwindigkeit nicht viel. Vor allem für Einsteiger und "normale" Datenbank-Größen ist ein Verweis auf TPC sinnlos, da hier Tests gefahren werden wo allein schon aufgrund der HW/SW-Ausstattung 5-6-Stellige €-Kosten auftreten.


Aber nochmal zum Thema:
- Du kannst mit vielen DBMS wie MySQL, Firebird, MSDE oder ähnlichen arbeiten. Als Einsteiger wirst Du bei keiner auf unüberwindbare Einschränkungen treffen
- Die für deine Zwecke eine geeignete Lizenz hat bzw. verfügbar ist. Willst Du Zugriff über Internet erlauben und einen Webhoster einsetzen willst so wird vermutlich MySQL am Häufigsten Anzutreffen sein. Aber achtung: Der Remote-Zugriff muß freigeschaltet sein
- Falls Du irgendwann mal Geld damit verdienens willst schau dir auf jedenfall auch kommerzielle Komponenten an. Bei MySQL schlagen z.B. die CoreLab-Komponenten jede andere Implementierung (auch ZEOS) bezüglich Performance um Längen.
- Der Datenbank-Zugriff gekapselt wird. (Für den Einstieg wird das erst mal zu viel sein, aber für eine spätere Version welche mehrere DBMS unterstützen soll ist eine Kapslung (z.B. mit dem Bridge-Pattern) sehr sinnvoll). DB-Gebundene Controls sind für den Anfang/Einstieg sinnvoll (auch für Prototypen), jedoch solltest Du diese später vermeiden (auch wegen Kapslungs-Aspekten). Beschränke dich auf Basis-Datentypen, so daß ein unterstützen einer weiteren DBMS nicht unmögich ist.
- Auch SP's würde ich fürs erste vermeiden (man kann auch mit Prepared-Statements eine hohe Geschwindigkeit erreichen).

[Jasocul]

@jensw_2000:
Bei den meisten deiner Aussagen stimme ich dir voll zu. Bei zwei Dingen kann ich dir nicht folgen.

Zitat von jensw_2000:

Vermeide möglichst die Verwendung von "hart verbundenen" DB-Komponenten (Querys, Tabellen, SPs ...) in deinen Applikationen. Erstelle die Verbindungskomponenten zur Laufzeit.

Bei allen DB-Verbindungen, die visualisiert werden, macht das keinen Sinn. Bei allen DB-Verbindungen, bei denen es um Datenmanipulation geht (insert, update, delete) gebe ich dir aber Recht.

Zitat von jensw_2000:

Vermeide die Verwendung von Views in der deinen SQL-Scripten.
Verjoine lieber in jedem einzelnen SQL-Script die benötigten Tabellen nach Bedarf.
Views sind langsam, nicht immer sofort aktuell, sie fördern einen schlechten Programmierstil und sind zudem noch unflexibel.

Sorry, aber das ist Blödsinn.

[RavenIV]

Zitat von Bernhard Geyer:

...
- Falls Du irgendwann mal Geld damit verdienens willst schau dir auf jedenfall auch kommerzielle Komponenten an. Bei MySQL schlagen z.B. die CoreLab-Komponenten jede andere Implementierung (auch ZEOS) bezüglich Performance um Längen.
...

gibt es einen Link zu den CoreLab-Komponenten?
was für eine Lizenz benötigen diese Kompos?

[Bernhard Geyer]

Zitat von RavenIV:

gibt es einen Link zu den CoreLab-Komponenten?
was für eine Lizenz benötigen diese Kompos?

Core Lab
Lizenzen sind Entwickler-Basierend.
Selbst haben wir für MySQL eine Site-License gekauft um alle Entwickler abzudecken.

[jensw_2000]

@Jasocul
Darf ich meine Aussagen kurz verteidigen ?

Zitat von Jasocul:

@jensw_2000:
Bei den meisten deiner Aussagen stimme ich dir voll zu. Bei zwei Dingen kann ich dir nicht folgen.

Zitat von jensw_2000:

Vermeide möglichst die Verwendung von "hart verbundenen" DB-Komponenten (Querys, Tabellen, SPs ...) in deinen Applikationen. Erstelle die Verbindungskomponenten zur Laufzeit.

Bei allen DB-Verbindungen, die visualisiert werden, macht das keinen Sinn. Bei allen DB-Verbindungen, bei denen es um Datenmanipulation geht (insert, update, delete) gebe ich dir aber Recht..

Es macht imho generell Sinn, die Verbindungskomponenten zur Laufzeit zu erstellen.

Hier mal die aus meiner Sicht wichtigsten Gründe:
Verbinde ich z.B. eine TxxTable mit meiner TxxConnection, und setze die TxxTable zur Entwurfszeit auf Acitve:=true (um z.B. die Spaltenbreiten meines DBGrids anzupassen oder so ..) und trenne diese Verbindung vor dem Compilieren nicht, dann habe ich ein mächtiges Problem wenn ich mit meiner schönen neuen EXE zum Kunden fahre. Die TxxConnection versucht sofort, wenn sie erzeugt wird, eine Verbindung zu meiner "Entwicklungs-DB" herzustellen anstatt zum DB-Server des Kunden ... Das bedeutet Abreise und ein neuer Termin ...

Viele "Anfänger" weisen der Verbindungskomponente die Felder aus der zugrundeliegenden Datenmenge fest zu.
Wenn sie dann mal einen Feldnamen / Feldtyp ändern müssen, verzweifeln sie bei der Fehlersuche ...

Es gibt Anwendungem mit sehr vielen datenvisualisierenden Komponenten. Bei meinen ersten DB-Anwendungen habe ich auch für jede in der DB-existierende Tabelle/Abfrage eine Komponente in mein TDatamodul gezogen. Das was zum einen unübersichtlich und zum Anderen hatte es folgende Nachteile:

Beispiel:
An der TTable "tabelle1" in meinen TDatamodul hängen TDatasources in 2 oder 3 Formularen. Wenn ich jetzt in einem dieser Formulare z.B. im tabelle1.AfterScroll eine Statuszeile aktualisiere, dann kostst mich das auch Zeit, wenn das besagte Formular garnicht angezeigt wird. Erstelle ich die Formulare zur Laufzeit dann muss man sogar noch Exceptions umgehen bzw. abfangen ...
Zusätzlich verursacht es nur Probleme, wenn ich in den Formularen individuelle Ereignisbehandlungsroutinen für die DB-sinsitiven Komponenten verwenden muss. Die Ereignisbahandlungen greifen durch die harte DB Verbindung letztlich auch in den Formularen, die garnicht aktiv sind.

Bei Client/Server DB-Programmiereung machen datensensitive Komponenten nur in sehr begrentem Umfang Sinn.
Wenn man die Daten ohnehin zur Laufzeit händisch in "Nicht-datensensitive Komponenten" einliest, warum sollte man dann nicht vor den Einlesen einen passenden TDataset-Nachfahren erzeugen und nach den Einlesen wieder freigeben ?
Das dauert nur wenige Minuten länger, hat aber viele Vorteile. Man muss sich nicht um das DisableConrols/EnalbeControls kümmern, hat keine Zeitverluste durch "unötig" angebundene datensensitive Komponenten und hat zudem noch mit deutlich weniger Fehlerquellen.

Zitat von Jasocul:

Zitat von jensw_2000:

Vermeide die Verwendung von Views in der deinen SQL-Scripten.
Verjoine lieber in jedem einzelnen SQL-Script die benötigten Tabellen nach Bedarf.
Views sind langsam, nicht immer sofort aktuell, sie fördern einen schlechten Programmierstil und sind zudem noch unflexibel.

Sorry, aber das ist Blödsinn

Das ist definitiv kein Blödsinn.

Imho unterstützt nur der MSSQL/MSDE eine Möglichkeit Views zu indizieren. Dazu müssen diese View jedoch Schema-gebunden sein (bis MSSQL-2000) was bei 99,5% aller Views nicht der Fall ist.
Indizierte Views sind je nach Komplexität und Abfragehäufigkeit bis zu 1000% schneller. (Technet Artikel).
Verjoint man jetzt noch Views miteinander, hat man die Performancevorteile eines RDBMS komplett vernichtet. Der SQL-Server wird schneller an seine Leistungsgrenzen getrieben und wird sich beim Anwender mit DeadLocks u.Ä. dafür bedanken.

Views sind wirklich nicht immer sofort aktuell. Ich wollte das auch nicht glauben.

Ich hatte bei der Final-Release meiner Callcenter Software eine relativ komplexe SP verbaut, die den Agenten einen freien Kontakt zum Anrufen liefert. In der SP habe ich u.A. geprüft ob der Agent berechtigt ist diesen Kontakt anzurufen, ob der Kunde schon einmal angerufen wurde und was dabei herausgekommen ist, ob der Kontakt bei jenamden in der Wiedervorlage steht usw ...
Am Ende wurde die ID des Kontaktes dann in eine Sperrtabelle eingetragen und dann der entsprechende Datensatz aus der Kunden-Tabelle abgerufen und an den Agenten zugestellt.

Alles über Views, weil das so schön einfach war ...

Sobald viele Agenten im Callcenter waren (also entsprechend hohe Serverauslastung) kam es ein paar mal am Tag spontan vor, das ein und der selbe Kunde in kurzen Zeitabständen mehrfach hintereinander angerufen wurde. Bei der Fehlersuche in der DB war nie etwas zu finden. Alle Staties (bereits angerufen, kein Interesse, Wiedervorlage usw.) waren sauber gesetzt.
Ich habe mir über Wochen den Wolf gesucht und keinen Fehler gefunden.

Letztlich hat mich Leuselator dazu überredet die SP umzustellen und alle Views daraus zu verbannen.
Ich habe die Joins 1:1 aus den Views übernommen und diese direkt aus der SP aufgerufen.
Seither ist der Fehler verschwunden und die SP wird mehr als 10 mal so schnell abgearbeitet ...
Die CPU Auslastung auf dem SQL-Server ist (bei vollem Callcenter) von rund 40% auf etwa 15% gesunken.

Daher mein Ratschlag an alle, die SQL Datenbanken entwickeln:
Views sind langsam und nicht immer sofort aktuell.
Verwendet Views nie in SP's, Funktionen und veschachtelten Abfragen, sondern verjoint die zugrundeliegenden Tabellen direkt.

Schöne Grüße,
Jens

[Jasocul]

@Jensw_2000:
Klar darfst du dich verteidigen. Wir lernen doch alle von verschiedenen Sichtweisen. Ein bisschen habe ich das auch provoziert.

Zunächst die Views:
Ich wäre nie auf die Idee gekommen in SP Views zu ziehen. Daher hatt ich das Problem wohl auch noch nicht. Allerdings arbeite ich mit Oracle (und Provit mit Firebird) und nicht mit MS-SQL. Könnte also auch was spezifisches sein.
Views zu joinen macht imho sowieso wenig Sinn. Dann ist der View schon falsch definiert.

Dynamische Komponenten:
Das ist offensichtlich eine koneptionelle Frage, die jeder für sich beantworten muss. Das zu diskutieren würde hier wohl den Rahmen sprengen.