Interbase, MS-SQL oder... Was ist für mich am besten?

[Jürgen Thomas]

Hallo an alle,

durch eine andere Diskussion [dp]SQL Server 2005 Express: Forum gesucht[/dp] bin ich ziemlich verunsichert. Ich möchte dieses Thema unter anderer Überschrift neu beginnen.

Welche Kombination von Compiler, SQL-DB und Zugriffsverfahren ist für meine Situation (Vorkenntnisse, Zielgruppe, Programmierumgebung, Lernaufwand...) möglichst gut geeignet?

Dazu will ich zunächst meine Vorüberlegungen erklären:

* In der Vergangenheit hatte ich Delphi (bis D5 Pro), dazu die BDE verwendet.
* Zur Weiterentwicklung habe ich Interbase 'studiert'. Die von mir benötigten Datenbanken (Intern 5 MB, Postdaten u.ä. 100 MB, Anwenderdaten 10..100 MB) sind inzwischen fertig.
* Ich bin Einzelkämpfer und habe - abgesehen von den Foren - keinen Kontakt mit anderen Programmierern.
* Aus dem gleichen Grund kann ich mich nicht gleichzeitig mit NET, einer neuen Programmiersprache, einer neuen IDE, mehreren DBMS und SQL-Dialekten befassen, sondern muss rationell vorgehen und sollte auch getroffene Entscheidungen nur umstoßen, wenn es wirklich notwendig ist.
* Meine Englisch-Kenntnisse sind mangels praktischer Erfahrung beschränkt. Ich kann es zwar mehr als ausreichend lesen, aber es geht deutlich langsamer, und bei vielen Satzkonstruktionen und Begriffen habe ich Verständnisprobleme. Deshalb bevorzuge ich Programme und Literatur in Deutsch.
* Ich lebe wesentlich von Hartz IV und habe nur selten Geld für Investitionen.
* Meine (noch vorhandenen und potenziellen) Kunden arbeiten professionell mit meinem Programm (bisher noch unter DOS), haben aber ebenfalls wenig Geld. Außerdem verfügen sie ausschließlich über Anwenderkenntnisse.
* Meine Zielgruppe benutzt zwischen 1 und 10 PCs, mit und ohne Server. Theoretisch genügt für deren Bedürfnisse die BDE, aber natürlich muss ich auf SQL-Datenbanken wechseln.

Auslöser für Gedanken zum Wechsel waren die Probleme mit Delphi 2005, die Zukunft von Borland/DevCo usw., die Zusammenarbeit zwischen Delphi und NET und dergleichen. Dadurch entwickelten sich folgende Entscheidungen:

* Zu einem Borland-Compiler passt eine Borland-Datenbank. Also: Interbase.
* NET scheint zukunftssicher zu sein (zumindest wegen der Vorrangstellung von MS) und erleichtert vieles. Also: NET.
* In der Vergangenheit hatte ich Infopower (Woll2Woll) und Rx-Tools verwendet (ich weiß, dass Jedi der Nachfolger ist). Aber bei jeder neuen Delphi-Version neue Tools kaufen bzw. installieren, anpassen und umstellen ist zumindest lästig; und wie sieht es in der Zukunft aus? Deshalb vorzugsweise mit Bordmitteln arbeiten.
* Ein neues Programm unter NET? Dann nicht VCL, sondern FCL.
* Ein neues Programm jetzt? Dann am besten gleich NET 2.0 (also entfällt Delphi).
* Borland-Zukunft? Also nicht mit Delphi programmieren, sondern mit C#. Dann kann ich vorerst dieselbe IDE benutzen und habe später (fast) keine Umstellungsprobleme, wenn ich einen anderen Compiler verwende. (#D scheint eine sinnvolle Alternative zu sein, aber alles gleichzeitig prüfen...)
* Unter Borland-C# habe ich Borland Data Provider als Datenbankzugriff für Interbase. Also was verwenden?
* Meiner Zielgruppe (s.o.) muss ich eine Datenbank vorschlagen (vorerst: vorschreiben). Dazu brauche ich eine sichere DB, die (möglichst preiswert) problemlos zu installieren ist und bei Bedarf ausgeweitet werden kann.
* Bei MSSQL kann ich aus einer DB (Anwenderdaten) auf eine andere (Postdaten) zugreifen, bei IB nicht. (Diese Funktion ist für mein Programm sehr hilfreich.)

Die drei letzten Punkte brachten mich zu meiner Bevorzugung von MSSQL. Open Source (Firebird) gefällt mir zwar gut, aber ich traue der Entwicklung für kommerzielle Bedürfnisse nicht so ganz. Außerdem läuft die Zusammenarbeit zwischen C#, NET und Datenbank über System.Data.SqlClient vermutlich am besten.

Ich hoffe, ich habe meine Beweggründe ausreichend dargestellt.

Ich habe hier in der DP in den letzten sechs Wochen eine ganze Menge Hinweise auf sinnvolle Alternativen und Ergänzungen gelesen. Natürlich können Tools, andere DBMS usw. besser geeignet sein. Aber irgendwann einmal muss ich doch entwickeln und nicht nur nachdenken, was es sonst noch alles gibt. Zusätzlich kämen mir Hinweise auf entsprechende Foren für die weitere Arbeit sehr gelegen.

Könnt Ihr mir unter diesen Umständen bei meinen Entscheidungen helfen? Danke! Jürgen

[Lemmy]

Guten Morgen,

Du siehst an den "überwältigten" Reaktionen, dass es gar nicht so einfach ist. Da ich bei meinem Arbeitgeber in den letzten Monaten dasselbe mitgemacht habe, ein paar Kriterien, die wir angelegt haben:

Da Zeit=Geld, Geld immer knapp und Zeit noch knapper ist, haben wir uns entschieden weiterhin mit Delphi 7 zu produzieren. Delphi 2007 werden wir uns wieder genau anschauen und evtl. darauf umsteigen, aber immer noch Win32. Sollten wir irgend wann zu dem Ergebnis kommen, dass .NET für unsere Arbeit geeignet ist, dann werden wir umsteigen. Allerdings bedeutet das, einige Anwendungen, die seit ca. 6 Jahren entwickelt werden, mit der Zeit umzustellen. Unsere Kunden interessiert das in keinster Weise, wie die Anwendung gemacht wurde, wichtig ist nur dass sie stabil läuft! Somit müsste der Vorteil für die Entwicklung schon immens sein!

Für mich privat gibt es auch noch keinen Grund auf .NET zu wechseln, von der Tatsache mal abgesehen, dass es mehr freie Stellen als .NET (C#/VB#) Entwickler gibt als Delphi-Stellen. Insofern muss ich, wenn ich irgend wann mal nicht arbeitslos sein will, mich mit .NET beschäftigen.

Zur Datenbank: Du hast kein Geld, deine Kunden haben kein Geld (wollen keines ausgeben) - also für mich sieht das stark nach einer, in der Anschaffung kostenlosen Datenbank aus.... Da ich Firebird kenne und sehr gern damit arbeite, sehe ich das vielleicht auch etwas einseitig. Nur kann man meiner Meinung nach bei Firebird nur wenige Fehler machen, damit FB zu einem Sicherheitsrisiko für einen Server wird. Bei MSSQL ist es nach meinem Gefühl eher anders rum. Firebird läuft sogar auf alten Maschinen selbst als Server, da hast Du mit MSSQL vermutlich schon eher mal ein Problem.

Für den Zugriff auf Firebird gibt es meiner Meinung nach 3 Alternativen: UIB (kostenlos), FIBPlus (kostet was) oder Zeos (kostenlos) [in genau der Reihenfolge]. Wegen Deiner Angst bzgl. Fremdkomponenten: Klar solltest Du Wildwuchs vermeiden und nicht zig verschiedene Bibliothekten einbinden. Aber warum auf etwas verzichten, dass dir die Arbeit wesentlich vereinfacht und eine entsprechende Performance bieten?

Beispiel TTreeView. Das Ding von Borland ist bei einer entsprechenden Datenmenge so stinke langsam, dass es schon fast einem Verbrechen gleichkommt das Ding zu nutzen. Als Alternative setze ich VirtualStingView ein, das ich teilweise sogar als Grid "missbrauche", eben weil es so schnell ist.

Wichtig bei der Komponenten ist eher, dass Du den Zugriff auf den Source erhälst. Somit kannst Du auch selbst Änderungen vornehmen bzw. von anderen vornehmen lassen.

Desweiteren kannst Du die Abhängigkeit von den Komponenten auflösen, indem Du deine Anwendung entsprechend aufbaust und eine Mehrschicht-Architektur verwendest. Somit kannst Du im Notfall die komplette VCL-Oberfläche wegwerfen und eine ASP.NET Oberfläche dran basteln, ohne Änderungen an der GEschäftslogig vornehmen zu müssen, weil diese in entsprechende Klassen gekapselt ist und nichts mit der Oberfläche zu tun hat.

Lemmy

[alzaimar]

Ich sehe das genauso, allerdings aus der Sicht von MSSQL. Ich arbeite damit seit 10 Jahren und bin einfach begeistert. Nicht weil ich ein MS-Jünger bin, denn der Rest aus diesem Hause ist Müll. Aber MSSQL ist ein wirkliches Spitzenprodukt.

Ob es Besser oder Schlechter als FB ist, weiss ich nicht. Ich kenne auch nur positive Stimmen über Firebird. Persönlich würde ich aber annehmen, das MSSQL hinsichtlich Performance noch einen Tick besser ist, als FB. Aber das ist eine unbewiesene Annahme aus der Überlegung heraus, das MS hier einfach die besseren (weil mehr) Programmierer hat.

Wenn es aber nicht um 1000tel Sekunden oder um Webanwendungen geht, würde ich mittlerweile auch zu FB tendieren. Wieso? Weil FB ein echtes OpenSource-Produkt ist und nicht eine 'abgespeckte' Version eines kommerziellen DBMS.

[Jelly]

Ich möchte nicht über Performanceunterschiede zwischen FB und MSSQL diskutieren. Ein ordentliches DB Design vorausgesetzt, sollten beide keine Probleme mit grossen Datenmengen haben... Aber der MSSQL Server ist weit mehr als einfach nur eine Datenschleuder... Hier mal nur kurz, was mir gerade einfällt:

• Reporting
• .NET Integration, d.h. Stored Procedures können in einer .NET Sprache geschrieben werden
• Replikation
• imho bessere Userverwaltung
• Direkte XML Unterstützung für Import/Export und auch als eigener Datentyp
• Direkte Erstellung von Webdiensten
• DTS (Data Transformation Services), ein Tool zum Importieren von fremden Datenformten in die eigene DB Struktur. Hab ich zwar nur davon gelesen, soll aber sehr mächtig sein

Zugegeben, ich hab noch nicht alle Features ausgereizt, und zugegeben, es sind auch bei weitem nicht alle Features in der Express vorhanden. Aber einem Upgrade steht ja nix im Wege, sofern der Kunde das zahlen will, zu einer Vollversion des Servers.

Das sind imho auch Überlegungen, die man bei der Wahl des DBMS in Betracht ziehen muss.

Tipp: Kauf Dir die aktuelle Ausgabe von "Der Entwickler 5/2006", da ist auf der DVD die komplettee Ausgabe im PDF Format der Sonderausgabe "SQL Server 2005" drauf. Sehr empfehlenswert zu lesen. Die gibts auch getrennt zu kaufen..

[alzaimar]

Reporting ist nicht in der 0 Euronen-Express-Version enthalten. Bei DTS weiss nicht es nicht.

Wenn die Vorgabe lautet: Kein Geld für DBMS, würde ich würfeln.
Wenn man (also der Kunde) dagegen Geld ausgeben will (bzw. das Budget hat), würde ich auch den MSSQL nehmen.

[Jelly]

Es gibt eine Feature Matrix bei Microsoft...

Klar die Express Version begrenzt. Aber für den Kunden gilt auch, dass ein Upgrade problemlos möglich ist, ohne dass der ganze Datenbestand ummodeliert werden muss. Die Entscheidung liegt da beim Kunden. Als Entwickler darf man ihm das nicht vorenthalten. Was Firebird zu leisten vermag ist sicherlich auch allein schon mit der Express Version des SQL Servers möglich. Und sollte die Datenbankgrösse mal über 4 GB wachsen (denn das ist ja die Limitierung der Expressversion, neben der Prozessoranzahlbergenzung), wird es womöglich eh Zeit, über eine Standard oder Wordgroup Version nachzudenken, denn da bewegt man sich dann so langsam in anderen Dimensionen.

Letztendlich muss jeder für sich selbst entscheiden. Ich neige ja, ich gebs zu, zum MSSQL. Aber nun gut. Ich kann die anderen Argumente auch erstehen und akzeptieren.

[mkinzler]

Interessant wäre es auch, beim Kunden in Erfahrung zu bringen, welche andere DBMS schon vorhanden sind und welches OS auf dem Server läuft. Wenn keine speziellen Features eines DBMS benötigt werden, könnte man auch eine davon unabhängige Lösung wählen.

[Jürgen Thomas]

Danke für die Informationen!

Leider wird die Sache dadurch für mich nicht einfacher, weil ich meine Vorkenntnisse und 'gedanklichen' Vorleistungen zu wenig berücksichtigt sehe.

@Jelly #4
Dies gehört zu den Gründen, warum ich eine Tendenz zu MSSQL entwickle.

@mehrere
Das Geld ist zz. fast kein Gesichtspunkt: Für mich stehen MSSQL-Express oder für ca. 60 € die Entwicklerversion zur Verfügung; die IB-Developer-Version habe ich über D2005 sowieso. Die Kunden können entweder (bei 1-Platz-System) auf Dauer mit einer 'einfachen' Version arbeiten oder bei Bedarf aufrüsten; diesen Punkt sollte ich nur als Perspektive nicht aus dem Auge verlieren.

@mkinzler #7
In der Regel haben die potenziellen Kunden noch keine SQL-DB (deshalb ist es denkbar, dass ich eine 'vorschreiben' kann). Ich muss aber damit rechnen, dass doch eine zur Verfügung steht; und es ist wahrscheinlich, dass es sich um MSSQL handelt (in welcher Version auch immer).

Nach allem, was ich bisher gelesen habe (nicht nur jetzt bei Euch), spielt es für mich DB-technisch keine Rolle, ob ich IB/FB/MSSQL verwende. Umso wichtiger ist aber die Programmier-Konstellation insgesamt.

Meine Gedanken in #1 scheinen also sinnvoll zu sein: NET 2.0, C# oder #D, MSSQL (und dazu evtl. geeignete Tools aus Sourceforge o.ä., damit ich von manchen Fremdarbeiten profitieren kann). Das einzige wesentliche Argument dagegen kam von Bernhard Geyer, dass damit wiederum der Monopolist gestärkt würde.

Ist das ein korrektes (Zwischen-) Ergebnis? Jürgen

[Alfalge]

Lemmy schrieb dazu:

Zitat:

Desweiteren kannst Du die Abhängigkeit von den Komponenten auflösen, indem Du deine Anwendung entsprechend aufbaust und eine Mehrschicht-Architektur verwendest. Somit kannst Du im Notfall die komplette VCL-Oberfläche wegwerfen und eine ASP.NET Oberfläche dran basteln, ohne Änderungen an der GEschäftslogig vornehmen zu müssen, weil diese in entsprechende Klassen gekapselt ist und nichts mit der Oberfläche zu tun hat.

Diese Aussage entspricht voll und ganz meiner Meinung. Ich möchte sie an dieser Stelle nur noch etwas erweitern: Gliederst Du Deine Anwendung wirklich konsequent in mehrere Schichten oder Ebenen, dann bist Du frei in fast allen Belangen: Frontend ist Frontend, die Geschäftslogik ist in einer Ebene gekapselt und darunter liegt eine Schicht, die wie auch immer, die benötigten Daten bereit stellt.
Ich ertappe mich immer wieder dabei, nicht konsequent mehrschichtig zu programmieren, bei mir wirds meist aus Bequemlichkeit ein Monolith oder ein 2Tier. Das ist aber auch nur so, weil die Anforderungen an meine Programme diese Vorgehensweise implizierten (keine Skalierbarkeit benötigt, Single-User-Anwendungen, maximale Performance durch Weglassen von Overhead). Interessant wäre meiner Meinung nach noch die Frage: Soll das Ganze auch noch ins Internet? (Nur so ein Gedanke). Dann solltest Du in jedem Fall auch noch MYSQL in Deinen Katalog aufnehmen. Auf die Gefahr hin, dass ich über das Ziel hinausschiesse: Wenn Du den SQL-Server zu reinen Datenhaltung nutzt, ohne darin groß mit Stored Procedures rumzumachen, ist fast jeder der Server eine gangbare Alternative. Wenn man sich dann noch an Ansi-SQL hält, ist man fast auf der sicheren Seite. Zum Entwickeln würde ich IB oder FB empfehlen. Da Du mit nicht unbedingt großen Daten arbeiten willst und ich davon ausgehe, daß die meisten Datenbankzugriffe eher lesend sind und ich weiterhin davon ausgehe, dass nicht mehr als 2-5 Benutzer auf der DB rumhacken, bleibt es dabei: IB oder Firebird. Wenn Internet dazu kommt, sollte man an MySQL denken.

[Phoenix]

Es ging ihm ja eher um die Wahl der IDE / Sprache, die Datenbank ist erstmal raus.

Wenn Du in Delphi gut bist spricht nichts gegen eine Delphi.NET - Anwendung. Du kannst sogar ggf. Geschäftslogik Deiner alten Applikation in Delphi.NET weiterverwenden.

Der größte Unterschied zwischen .NET 1.1 und 2.0 ist eher im Bereich ASP.NET anzusiedeln und im Bereich Winforms und auch ADO.NET nicht so dramatisch. Den Hub auf 2.0 kannst Du mit dem neuen BDS 2007 auch später noch packen. Ich denke Dir wird .NET 1.1 vollkommen ausreichen.

Was mich zur IDE bringt: Die Turbos sind kostenlos - und für Deine Zwecke wahrscheinlich ausreichend ausgestattet. Also hier Turbo-Delphi.NET.

Das wäre nach Deinen Angaben im ersten Post für mich die effizienteste Wahl.