Idee um Datenbankprogrammierung zu erlernen

[whiteshark]

Moin Leute,

ich habe mir überlegt ein kleines Programm zu schreiben, mit dem ich die Anwendung der Datenbankkomponenten erlernen kann. Meine Idee war ein kleines Programm für eine Internetverwaltung zu schreiben. Ich dachte mir ich schreibe ein Programm für den Server und ein Programm für jeden Client. Die Clients sollen dann auf dem Server sich mit Benutzernamen und Passwort anmelden können. Auf dem Serverprogramm kann man dann die Benutzer sehen, die online sind. Außerdem kann man auf dem Server neue Benutzer hinzufügen können, Rechte der Benutzer verwalten können. Alle Rechte und Daten der Benutzer wollte ich auf einer SQL-Datenbank abspeichern. Als zweites soll man seine Rechter per Internetseite abrufen können, d.h. auf der Internetseite kann man sich auch mit Benutzernamen und Passwort anmelden können und dann sein Kontostatus erkennen können.

Was haltet ihr von der Idee? Was sollte ich beachten, gerade auf dem Gebiet der Sicherheit? Ist es sinnvoll mit einer SQL-Datenbank zu arbeiten?

[Tubos]

Zitat:

Ist es sinnvoll mit einer SQL-Datenbank zu arbeiten?

Welche Datenbank? SQL ist nur die Datenbank-Sprache, es gibt viele DBs die mit SQL angesprochen werden.

Zitat:

Was sollte ich beachten, gerade auf dem Gebiet der Sicherheit?

SQL Injections verhindern.

[whiteshark]

Zitat:

Welche Datenbank?

Ich dachte da an eine MySQL-Datenbank.

Gibt es sonst noch etwas zu beachten?

[MagicAndre1981]

Zitat:

Zitat von whiteshark

Ich dachte da an eine MySQL-Datenbank.

Ich würde dir zu dem FireBird raten. Von MySQL halte ich nicht viel.

[Tubos]

Zitat:

Von MySQL halte ich nicht viel.

Wenn du noch eine Begründung dafür lieferst, ist das sicher hilfreicher für whiteshark.

Ich halte MySQL für eine gute und einsteigerfreundliche Datenbank.
Dazu muss ich aber sagen dass ich noch keine andere Datenbank kennengelernt habe.

[MagicAndre1981]

Zitat:

Zitat von Tubos

Zitat:

Von MySQL halte ich nicht viel.

Wenn du noch eine Begründung dafür lieferst, ist das sicher hilfreicher für whiteshark.

Also, MySQL kann nicht so viel wie der FireBird. Erst ab Version 5 kommen Trigger, StoredProcedures etc. hinzu. Transaktionen werden imho auch nur von der kostenpflichtigen Version unterstützt. Somit sind wir bei dem Theater mit der Lizenz. Da blickt doch keiner durch :wall: . Beim FB ist das anders. Den kannst du frei für jedes Programm, ob kommerziell oder privat nutzen. Für den Einstieg ist das Ding super :thumb: .

Zitat:

Zitat von Tubos

Ich halte MySQL für eine gute und einsteigerfreundliche Datenbank.
Dazu muss ich aber sagen dass ich noch keine andere Datenbank kennengelernt habe.

Dann wird es Zeit ;-) Hol dir den Fb und leg los. Du wirst merken, dass bei MySQL einiges fehlt :zwinker:

[Tubos]

Zitat:

Dann wird es Zeit Hol dir den Fb und leg los.

Ich hatte keine andere Wahl, das Projekt läuft mit PHP und MySQL auf kostenlosem Webspace.

Zitat:

Du wirst merken, dass bei MySQL einiges fehlt

Hab bis jetzt nichts vermisst, aber ich weiß dass man mit Dingen wie Triggern und Stored Procedures mehr geile Sachen einfacher und mit besserer Performance machen kann ;)

[alzaimar]

MySenf:
Ich habe gerade einen sehr fähigen Studenten, der mir eine Mittelsicht für die MSDE (MS-SQL Server 2000) programmiert. Er hat vorher nur MySQL gekannt und hat zuerst gemeckert. Nun ist im irgendwann (leider zu spät) aufgefallen, was man mit einem richtigen DBMS (dazu gehört auch FB und PostgreSQL), den Stored Procedures, Triggern, Transaktionen, Updatable Views usw. so Alles anfangen kann.

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

@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.

MySQL ist Kinderkagge.

[yankee]

Zitat:

Zitat von alzaimar

MySenf:
Ich habe gerade einen sehr fähigen Studenten, der mir eine Mittelsicht für die MSDE (MS-SQL Server 2000) programmiert. Er hat vorher nur MySQL gekannt und hat zuerst gemeckert. Nun ist im irgendwann (leider zu spät) aufgefallen, was man mit einem richtigen DBMS (dazu gehört auch FB und PostgreSQL), den Stored Procedures, Triggern, Transaktionen, Updatable Views usw. so Alles anfangen kann.

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

@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.

MySQL ist Kinderkagge.

ähm, ja also dein Student proggt daran mit. Ist doch kein Wunder, dass der sowas erzählt.
Schiebt ich bloß keinen Flash auf "welche DB ist besser?". Ich bin mir 100% sicher, das es keine DB gibt, die 200mal schneller ist als MySQL. Transaktionen sind nebenbei in MySQL implementiert. Musst nur InnoDB und nicht MyISAM verwenden. Es gibt auch keinen Unterschied bei MySQL zwischen der freien und nicht freien Version. Die freie Version ist GNU und du darfst die nicht kommerziell verwenden. Wenn du MySQL kommerzielle verwenden willst, gibt es da aber noch eine andere Lizenz, die vergelichsweise günstig ist, mit der du alles machen kannst. Das ist aber DAS GLEICHE Programm, nur eine andere Lizenz!!
Und ihr findet auch maßenhaft Leute im Netz, die genau das Gegenteil behaupten. Und das stimmt auch, wenn man den Blickwinkel etwas dreht. Man muss sich nur die Testbedingungen und alles ins feinste durchlesen oder mla genau betrachten, was irgendein Student für einen Müll baut, damit der für einen Query, der mit MS Software 0,3 Sekiunden 5 Minuten braucht. Da hat der Typ mit MySQL einfach was falsch gemacht. Das ist genauso, wie viele Leute sagen Linux oder Windows ist abslut doof und nur das Gegenteil ist zuwas zu gebrauchen. (Ach, da fällt mir gerade nochwas ein: Win und Linux verwenden ein unterschiedliches Threadingkonzept und MySQL ist auf das von Linux optimiert und daher läuft MySQL unter Linux schneller als unter Windows). Das ist einfach nicht fair betrachtet. Jeder, den ich persönlich (persönlich! Ihr seid nicht gemeint) kenne, der findet, das Linux grundsätzlich besser ist. Ich bin auch grundsätzlich ein Linuxbefürworter und trotzdem benutze ich mehr Windows (vorallem wegen der Spiele).

Macht euch einfach frei von irgendwelchen Aussagen, die euch versuchen zu sagen die eine Datenbank ist 100x schneller. Das ist BLÖDSINN

Und wenn du eine Datenbank kannst, dann wirst du keine Probleme haben, dich in eine andere einzufinden. Denn die wichtigen Sachen von Datenbankprogrammiererei kannst du theoretisch auch ohne Computer (=ohne Datenbank, also Tafel) lernen.

Grundsätzlich halte ich MySQL aber für eine gute Wahl. Die Datenbank hat einen hohen Bekanntheitsgrad und wird häufig angewendet. Nicht umsonst haben die meisten Webspaceangebote MySQL-implementiert. Also bestimmt nicht, weil MySQL so ein Müll ist und man umsonst auch eine 100x schneller Datenbank haben kann *kopfschüttel*

[Hansa]

Zitat:

Zitat von yankee

..Macht euch einfach frei von irgendwelchen Aussagen, die euch versuchen zu sagen die eine Datenbank ist 100x schneller. Das ist BLÖDSINN

Grundsätzlich halte ich MySQL aber für eine gute Wahl. Die Datenbank hat einen hohen Bekanntheitsgrad und wird häufig angewendet. Nicht umsonst haben die meisten Webspaceangebote MySQL-implementiert. ... *kopfschüttel*

Die grundsätzliche Frage ist, wo der Blödsinn anfängt. :mrgreen: Webspace muß umsonst sein, deshalb wird MySql in Kauf genommen. Durch FB ist das allerdings längst überholt.

[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 .... :mrgreen:

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

:hi:

[Bernhard Geyer]

Zitat:

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:

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:

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:

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:

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:

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 ? :mrgreen:

Zitat:

Zitat von Jasocul

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

Zitat:

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:

Zitat von Jasocul

Zitat:

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 ... :oops:

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
:hi:

[Jasocul]

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

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.