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.