Welche Datenbank für anfänger

[Hansa]

Der Unwissende hat im Prinzip schon Recht, aber : solche Threads wie der hier, die verlaufen häufig nach folgendem Schema : kleine Datenbank ist gut für die Kleinen und große Datenbank für die Großen (es geht um Programme, Datenmengen, Benutzer usw.). Nach dem Motto "das reicht doch". Dabei wird aber häufig übersehen, daß sich die "Kleinen" von den "Großen" im Einarbeitungsaufwand kaum unterscheiden. Man kann also durchaus mit einer "großen" Datenbank kleinere Programme schreiben. Umgekehrt werden wohl Grenzen auftauchen und es heißt : "ne, das geht damit nicht". D.h.: Kompromiss suchen, wenn es denn überhaupt einen gibt, oder Programm komplett umbauen, neue DB lernen. Im Falle von Firebird kommt noch hinzu, daß es mittlerweile recht verbreitet ist und für auftauchende Problemchen wahrscheinlich schnell einer auftaucht, der weiß woran es liegt.

Zitat von Phoenix:

..Zumal man wenn man eine neue Software ganz professionell angeht eh guckt, dass man Support für mehrere Datenbanken anbietet, um keine potentiellen Kunden zu verprellen.

95 % der potentiellen Kunden interessiert aber wohl weder die verwendete Datenbank, geschweige denn die verwendete Programmiersprache. Aus dieser Sicht (und nur aus dieser !) gesehen ist die DB IMHO egal. Die Leute wollen eine bestmögliche Problemlösung. Wie die zustandekommt ist denen ziemlich egal. Wenn Du die frägst : Welche Datenbank wollen sie verwenden ? Das verwirrt mehr, als dass es was nützt. Da ich mich zum Rest zähle, würde ich mir als potentieller Kunde noch folgende Fragen stellen : Wie will der diese angeblich unterstützen verschiedenen Datenbanken unter einen Hut bringen ? Bei 10 EUR Programm wärs mir egal, aber wenn es richtig Kohle kostet und sehr wichtig ist, dann kämen weitere Bedenken : wie siehts mit Updates aus ? Muß ich die auch überspielen, weil es z.B. eine neue MySQL-Version gibt, ich aber Firebird ausgewählt habe ? Wie lange dauert es überhaupt, bis ein Update fertig ist und zwar für meine DB wegen Versionswechsel ? Zu guter letzt etwas, was die Leute dann doch interessiert : soll ich tatsächlich ein Programm kaufen, welches wohl kaum für meine Datenbank irgendwie optimiert ist ? Phoenix, wir kämen wohl nicht ins Geschäft. Klar, es gibt Ausnahmen. Z.B. ein vorhandener Datenbestand, der benötigt wird. Wäre nur eben dann dumm gelaufen, wenn trotz meiner 5 DBs ausgerechnet die benötigte nicht unterstützt wird. Vielleicht noch ein psychologischer Aspekt : wurden bereits zigtausend EUR in z.B. Oracle-Kauf, Updates, Schulung usw. investiert, dann wird kaum einer zugeben wollen, daß Dein Programm mit kostenloser DB anscheinend genauso leistungsfähig ist. 8)

[Phoenix]

Zitat von Hansa:

95 % der potentiellen Kunden interessiert aber wohl weder die verwendete Datenbank, geschweige den die verwendete Programmiersprache.

Kommt immer aufs Umfeld an. In meinem Kundenbereich ist SQL Server und Oracle weit verbreitet, und ein Kunde der voll auf SQL Server setzt wird sich nur wegen meiner Software keinen Oracle-Server ins Haus stellen und Vice Versa. Gleiches gilt übrigens für DB2, aber da fehlts noch ein wenig an den Optimierungen.

Zitat von Hansa:

Aus dieser Sicht (und nur aus dieser !) gesehen ist die DB IMHO egal. Die Leute wollen eine bestmögliche Problemlösung. Wie die zustandekommt ist denen ziemlich egal. Wenn Du die frägst : Welche Datenbank wollen sie verwenden ? Das verwirrt mehr, als dass es was nützt.

Jo, da hast Du im Allgemeinen recht. Wobei hier auch wieder der Kundenkreis der bestimmende Faktor ist. Wenn ich eine Out-of-Box-Finanzbuchhaltung anbiete (wie z.B. Lexware) - dann ist nahezu JEDER Nutzer mit der DB überfordert. Deswegen sollte die dann am besten embedded (also für den User komplett unsichtbar) laufen. Voller Punkt für Dich. Im Bereich der Produktionsplanung und -steuerung, wo direkt mit der SPS (Anlagensteuerung) und dem MFR (Materialflussrechner) kommuniziert werden muss sieht das wieder ganz anders auch. Und nu steht's wieder 1:1

Zitat von Hansa:

Da ich mich zum Rest zähle, würde ich mir als potentieller Kunde noch folgende Fragen stellen : Wie will der diese angeblich unterstützen verschiedenen Datenbanken unter einen Hut bringen ? Bei 10 EUR Programm wärs mir egal, aber wenn es richtig Kohle kostet und sehr wichtig ist, dann kämen weitere Bedenken : wie siehts mit Updates aus ? Muß ich die auch überspielen, weil es z.B. eine neue MySQL-Version gibt, ich aber Firebird ausgewählt habe ? Wie lange dauert es überhaupt, bis ein Update fertig ist und zwar für meine DB wegen Versionswechsel ? Zu guter letzt etwas, was die Leute dann doch interessiert : soll ich tatsächlich ein Programm kaufen, welches wohl kaum für meine Datenbank irgendwie optimiert ist ? Phoenix, wir kämen wohl nicht ins Geschäft.

Hrm. Dafür gibts für jede Datenbankengine einen eigenen Treiber der die Statement-Optimierungsregeln implementiert. Aber genau an der Stelle sind wir an einem Punkt, wo die Software die hinten raus niemals 10 € kosten wird, sondern eher mal das mehrfache hundertfache.

Und dort darf der Kunde dann aber auch eine individuelle Betreuung erwarten und die Updates die speziell er benötigt bekommt er dann auch im Rahmen des Wartungsvertrages immer zugeschoben.

Wie schon gesagt: Die Out-of-the-Box Anwendung wird allein durch den nötigen Aufwand sicher nicht Datenbankspezifisch optimiert werden und nur mit einer DB ausgeliefert werden. z.B. Firebird embedded.

Letzlich bestimmt bei mir der Kunde / die Kunden den Funktionsumfang meiner Software und der verwendeten Datenbank. Manche Kunden brauchen z.B. zwingend Oracle, anderen ist es komplett egal, die würden sich mit einer Datenhaltung in XML-Files zufrieden geben, hauptsache es funktioniert wie gewünscht.

Zum einlernen in die Grundlagen der Datebankprogrammierung ist es letzlich aber tatsächlich egal, welche DB man verwendet. SQL können sie alle, und an die verschiedenen Dialekte die zum Teil abweichen kann man sich als Entwickler wie an eine andere Sprachsyntax auch sehr schnell gewöhnen wenn man erstmal weiss wie der Hase nun wirklich lang läuft.

Ich z.B. empfehle vom Einstieg gerne den SQL Server Express, weil er supereasy zu installieren ist und ADO auch eine relativ elegante Zugriffsmöglichkeit ist. Aber das ist wiederum persönlicher Geschmack. Ich würde heutzutage ja eh keine neue Win/32 - Applikation mehr beginnen sondern gleich mit .NET anfangen.

[Hansa]

Ich sehe, wir sind uns ja ziemlich einig. Nur eins noch : handelt es sich um ein Individual-Programm, dann macht es noch weniger Sinn, mehrere Datenbanken zu unterstützen. Konkreter Fall : Kollege schreibt für Firma kleinere SAP-Tools. Denen ist SAP schlichtweg zu teuer. Oder wars doch Oracle ? Der kann natürlich nicht anders und muß das wohl oder übel so hinnehmen. Ist jetzt kein Witz : jedesmal, wenn der mich sieht, dann fängt er an über seine DB zu fluchen.