[linux-l] S: Literatur Datenbanken f. Einsteiger

Volker Grabsch vog at notjusthosting.com
Di Jul 4 22:17:35 CEST 2006


On Mon, Jul 03, 2006 at 05:24:12PM +0200, Boris Kirkorowicz wrote:
> > Grundsätzlich empfehlenswert sind MySQL und PostgreSQL.
> 
> Das hat sich mittlerweile auch für mich herauskristallisiert. Wobei ich
> insgesamt den Eindruck gewonnen habe, dass PostgreS etwas reifer oder
> weiter ist, MySQL dafür lebendiger. Trifft das so zu?

Ich glaube nicht, dass MySQL "lebendiger" ist, sondern dass man beiden
DBs derzeitig ordentlich geschraubt und entwickelt wird.

Der wesentliche Unterschied ist IMHO, dass MySQL früher
leichtgewichtiger war, das ist alles.

Beide DBs fingen unterschiedlich an und bewegten sich seither
in Sachen Geschwindigkeit und Feature-Zahl aufeinander zu.

Schau dir beide mal an, entwickle für beide DBs, und du wirst mit
einem tieferen Verständnis für Datenbanken und einer flexibleren
Applikation belohnt.

Die Wahl der DB ist IMHO eine administrative Entscheidung, die
sich mit der Zeit ändern kann. Eine Applikation sollte da so weit
wie möglich keine Einschränkungen vorgeben. Nur wirklich große
Systeme können es sich IMHO *wirklich* leisten, mit nur einer einzigen
DB zu funktionieren.

> Noch ein Unterschied ist mir aufgefallen, und zwar der der Lizenz.
> PostgreS steht wohl unter der BSD, was wohl bedeutet, dass ich damit tun
> und lassen kann, was ich will. MySQL hat wohl eine bedingte oder
> gesplittete Lizenz: für den Eigen- und Privatbedarf steht sie unter der
> GPL 2, will man sie jedoch kommerziell einsetzen, muss man eine Lizenz
> gegen Bares kaufen. Habe ich das so richtig verstanden?

Kommt drauf an, was du unter "einsetzen" verstehst.

Grundsätzlich hast du bei *allen* freien Lizenzen die Freiheit, das
Programm für jeden Zweck zu benutzen. Der Einsatz von MySQL und der
Aufruf der MySQL-Kommandos ist also niemals ein Problem. Die GPL ist
eine sehr strenge Lizenz, aber solange du das Programm als
eigenständiges Programm, quasi eine "Blackbox", benutzt, kannst du
dies kommerziell und privat tun, das ist sogar erwünscht.

Problematisch wird es erst, wenn du an MySQL herum-hackst, oder wenn
deine Applikation etwas "tiefer" mit MySQL verbunden ist. Genau kenne
ich die Lizenzierungen von MySQL aber nicht. Was am kritischen Punkt
passiert, wenn du dein Programm gegen die "libmysql" linkst, weiß ich
leider nicht.

> >>und passende Literatur dazu.
> > Willst du in Python arbeiten,
> 
> Etwas grundlegender brauche ich es erst mal schon, also Installation
> (dürfte mit den gängigen Linux-Distris nix aufregendes sein) und
> Administration, wie bediene ich das Ding zu Fuß und/oder mit passenden
> Frontends wie z.B. OOo. Das will ich erst einmal ein wenig ausprobieren,

Eine Datenbank "probiert" man nicht mit OOo aus, sondern durch einen
Prompt, in den man SQL-Befehle eintippt. :-)

Nee, OOo ist sicher ganz nett, aber du solltest rechtzeitig auch mit
Code anfangen, denn nur für dein privates Adressbuch ist eine DB
IMHO absoluter Overkill.
(Es sei denn, du hast eigene Scripte, die damit irgendwas bestimmtes
anstellen)

> und wenn ich dann noch verstanden habe, wie man die DB sicher macht,
> Daten sichert, repliziert usw., will ich mit der eigentlichen Arbeit
> anfangen und mir ein Datenmodell überlegen, danach erst mit der
> Programmierung beginnen. Wäre das eine sinnvolle Herangehensweise?

Ohne Programmier-Erfahrung, sei es direkt per SQL oder über einen ORM
in einer Programmiersprache, glaube ich nicht, dass man das Konzept
der relationalen Datenbanken *wirklich* verstehen kann.

Vielleicht helfen einem Tools wie OOo, phpMyAdmin oder irgendwelche
anderen GUIs dabei, aber IMHO solltest du zuerst kleinere Programme
haben, die mit 1-3 Tabellen herumspielen. Danach erst solltest du
ernsthaftere Sachen designen. Außerdem ist das Design der "internen"
Schnittstelle, also der API in deinem Programm, meistens wichtiger
als das SQL-Datenmodell. Letzteres kann (und soll!) sich über die
Zeit häufiger ändern. Dies ist ganz natürlich, da sich Anforderungen
mit der Zeit ändern, und man beim Benutzen der ersten Programm-
Versionen öfters Denk- und Design-Fehler aufspürt. Eine saubere Trennung
auf Ebene der Programmierung, die sich am *Problem* und nicht am DB-Modell
orientiert, wird dir helfen, dass bei Änderungen im DB-Design nicht
gleich deine ganze Applikation umgeschrieben wird.

Diesen Gedanken kann man noch weiter ins Extrem verfolgen, aber das
ist ein persönliches "Forschungsgebiet" von mir, über die ich hier
schon einiges angedeutet habe, aber ohne Resultate keine zu großen
Töne spucken möchte.

Das ganze Vorgehen, also kleinere Programme schreiben, desginen, größere
Programme schreiben, designen, ... nennt man "Prototyp"-basierte
Programmierung. Du versuchst erstmal dein Design an einem kleinen
Programm aus, das von allem nur das nötigste beherrscht, also einen
Prototyp. Bei der Entwicklung werden sich wahrscheinlich Fehler im
Design und auch Fehler im Verständnis von SQL (oder des ORM) herausstellen,
sodass du in einem zweiten Anlauf zum Ziel kommst. Der Prototyp ist
zum Erfahrungen sammeln, Design überprüfen, und wegwerfen gedacht.

Ohne Erfahrung in allen Bereichen (auf Programmierung) mit realtionalen
Datenbanken sollte man kein ER-Modell entwerfen. Genauso sollte man
keine LDAP-Struktur entworfen haben, ohne wenigstens ein primitives
Tool zum Bearbeiten der Daten im LDAP geschrieben zu haben.

Und man sollte keine Wohnungsverwaltungs-Software designen, wenn man
nicht schonmal eine geschrieben hat. (Deshalb: Vorher Prototypen
schreiben)

Meine Meinung, YMMV.


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR



Mehr Informationen über die Mailingliste linux-l