Welche Technik für eine neue Applikation verwenden?

[Joachim Rohde]

Vorneweg entschuldige ich mich noch kurz, für den etwas lang geratenen Beitrag. (Die eigentlichen Fragen sind im letzten Absatz ;-)


Ich habe folgendes Problem (oder besser gesagt: Möglichkeit): Ich wurde von jemandem gefragt, ob ich nicht Interesse eine Applikation zu entwickeln. Dabei handelt es sich um eine Software, die bei Sport-Wettkämpfen zur Verwaltung der Startlisten, Bewertungen, etc. dienen soll. Es existiert zwar bereits ein solches Programm für diesen Sport, allerdings wurde das Programm seit knapp 3 Jahren nicht mehr wirklich weiterentwickelt und der jetzige Entwickler scheint auch kein Interesse mehr an dem Programm zu haben. Da es fraglich ist, ob er mir den Quellcode überlassen wird, wird es wohl auf eine Neuentwicklung hinauslaufen. Darüber hinaus, sind wohl alle Werte hart verdrahtet, so dass es wohl kaum noch wartbar ist.

Da mir jetzt alle Möglichkeiten offen stehen, stellt sich bei mir die Frage, welche Technik ich am besten verwenden sollte. Mein Problem besteht jetzt mehr oder weniger darin, dass ich die letzten 2 Jahre eigentlich nur mit Java (hauptsächlich J2EE) zu tun hatte und somit nicht wirklich auf dem Laufenden bin. Deshalb würde ich gerne ein paar Meinungen hören. Meine bisherigen Gedanken was ich brauche, vorraussetzen kann etc. sind folgende gewesen:

- Benutzer werden grundsätzlich Otto-Normalanwender sein. Sprich: Programm per Doppelklick starten und loslegen.
- Daraus ergibt sich, dass das Programm nicht Plattformunabhängig sein muss. Sprich: Windows wird Zielplattform sein. (Dazu sei vielleicht noch angemerkt, dass das existierende Programm in Visual Basic (16-Bit) geschrieben wurde).
- Dadurch, dass das alte Programm 16-bittig ist, ist die Systemanforderung an das alte Programm natürlich nicht so hoch. Ich weiß zwar, dass relativ viele Nutzer die Software auf alten Laptops laufen lassen (Pentium 1, o.ä.), allerdings wäre es vermessen, noch 16-Bit-Windows zu unterstützen. Mindestvorraussetzung wäre also Windows 95 (ggf. Win98). Da mir leider keine Daten über die verwendeten Betriebssysteme bei jetzigen Usern vorliegen, weiß ich nicht, ob ich Windows 2000 vorraussetzen kann.

Zur Programmiersprache habe ich mir folgendes gedacht:
- Bei Java gefällt mir die Programmierung der GUI nicht.
- Bei C/C++ habe ich die (vielleicht unberechtigte?) Befürchtung, dass die Entwicklung etwas länger dauern würde.
- Visual Basic fällt aus Präferenzgründen raus.
- Bleiben noch Delphi und C# bei meinen Überlegungen übrig. Auf C# hätte ich schon Lust, allerdings ist hier das Problem, dass das .NET Framework benötigt wird (->min. Win2000). Außerdem kann ich den Benutzern kaum zumuten, mal eben .NET zu installieren. Die meisten werden gar nicht wissen, was das ist.
- Und zack - bin ich bei Delphi. Nun habe ich mir die 2005 PE geholt und habe gesehen, dass ich die Wahl zwischen VCL, VCL for .NET und .NET habe. Habe ich das richtig verstanden, dass VCL for .NET eigentlich nur für existierende Projekte gedacht ist, um die Migration zu .NET erleichtern? Und gibt es eigentlich ein offizielles Statement, wie die Zukunft von VCL aussieht? Oder wäre es unklug ein neues Projekt mit VCL zu realisieren?

Als letztes stellt sich bei mir die Frage zur Datenbank. Ich bräuchte ja eine Embedded-DB. Was könntet ihr mir da empfehlen? Die Ansprüche an die DB sind nicht allzu hoch. Es werden im Maximalfall wohl nur 500 Datensätze gespeichert. Und ich müsste mit einem zweiten, externen Tool auf die Daten zugreifen können, aber das sollte ja nicht das Problem sein. Nur sollte sie recht Ressourcen sparend sein (s.o., wegen der alten Hardware). Derzeit habe ich MySql und Firebird im Auge.

Zusammenfassend möchte ich also gerne ein paar Meinungen hören, ob es sinnvoll wäre, VCL zu verwenden (oder sollte ich doch auf .NET setzen) und welche embedded DB ihr mir empfehlen könnt. Oder habe ich sogar eine Alternative übersehen? Bin für jeden Beitrag / Idee / etc. dankbar.

Joachim

[DGL-luke]

Wie bereits gesagt - für .Net wäre das .Net Framework vonnöten.

Und es spricht absolut nichts gegen Win32-Programme. So schnell wird diese Technik nicht auslaufen.

[Robert_G]

Sicher ist das .Net Framework vonnöten...
Und sicher ist .Net auf Win98 en wenig pain in the butt.
Aber
a) es sind nur 23MB (und nichtmal ein Neustart), wenn du dein Programm auf eine CD packst hast du dafür sicher Platz.
b) viele OEM Versionen von Windows[1] haben es bereits drauf
c) Wenn du von Java kommst, fühlst du dich mit C# doch sowieso gleich zuhause. [2]
d) Ist Win98 wirklich ein Thema? ( *Geschichtsbücher umschreibt...*)

Letztendlich interessiert nur, wo du dich am wohlsten fühlst und womit _DU_ glaubst das bessere Ergebnis zu erzielen.
Embedded DBs gibt es viele von NexusDB, über FireBird und AbsoluteDB zu SqlLite...
Dier ersten beiden sind die interessantesten, wobei Nexus nicht kostenlos ist, dafür kannst du darin Trigger, Stored procedures,... in Delphi32 oder .Net schreiben. (Ich habe aber nicht viel Ahnung von Nexus )
Firebird ist dir sicher ein Begriff...

[1]ich meine die vorinstallierten, nicht die supportfreien Versionen
[2]Es gibt auch J#, bnötigt aber, zusätzlich zur .Net redist, die J# redist

[Thanatos81]

Zitat von Joachim Rohde:

Es werden im Maximalfall wohl nur 500 Datensätze gespeichert. Und ich müsste mit einem zweiten, externen Tool auf die Daten zugreifen können, aber das sollte ja nicht das Problem sein.

Wenn ich dich richtig verstehe, wirds ja ne Einzelplatzanwendung. Dann wäre ein Blick auf die TDataSet-Kompnente gar nicht mal so abwegig.

Der große Vorteil, den ich für dich sehe, ist dass du die einzelnen Tabellen direkt als XML-Dateien nutzen kannst.

Damit sollte man kein Problem haben, dass andere Progs drauf zu greifen können. und ein Konvertieren von XML nach CSV ist auch kaum Code.

Und auch wenn die Daten im Speicher gehalten werden, ist die Speicherauslatung durchaus erträglich. Ich habe hier ein Prog in dem ich momentan 152 Datensätze mit folgender Struktur habe:

Code:

<FIELDS>
  <FIELD attrname="LfdNr" fieldtype="i4" SUBTYPE="Autoinc" /> 
  <FIELD attrname="KartenNr" fieldtype="string" WIDTH="255" /> 
  <FIELD attrname="Kennzeichen" fieldtype="string" WIDTH="55" /> 
  <FIELD attrname="Datum" fieldtype="date" /> 
  <FIELD attrname="Uhrzeit" fieldtype="time" /> 
  <FIELD attrname="Sorte" fieldtype="string" WIDTH="5" /> 
  <FIELD attrname="KM" fieldtype="i4" /> 
  <FIELD attrname="Menge" fieldtype="r8" /> 
  <FIELD attrname="Betrag" fieldtype="r8" SUBTYPE="Money" /> 
  <FIELD attrname="OK" fieldtype="boolean" /> 
</FIELDS>

Das macht folgende Speichernutzung, wenn man es mit einfachen Variablen nutzen würde:

• LfdNr 4 Byte
• KartenNr 255 Byte
• Kennzeichen 55 Byte
• Datum 8Byte
• Uhrzeit 8Byte
• Sorte 5Byte
• KM 4Byte
• Menge 8Byte
• Betrag 8Byte
• OK 1Byte

Das macht zusammen 356Byte*152 DatenSätze = 54.112 Byte ≈ 0,05MB.

Mein Programm belegt außerhalb der IDE ≈ 6,5MB. Ein leeres D7-Projekt liegt allein schon bei ≈ 2MB, Dazu kommen dann Kompos, etc.

QED: Ein TClientDataSet sollte auch mit älteren Rechnern nicht allzuviele Probleme machen. Zusätzlich ist es ziemlich fix, da es die Daten im Speicher hält und dadurch kaum Plattenzugriffe hat.

So, und der lange Text, war die Rache für deinen langen Text

[Joachim Rohde]

Ersteinmal ein Dankeschön für die Antworten.
Vielleicht hätte ich bei meinem ersten Beitrag noch erwähnen sollen, dass ich vor meinem Java-Projekt etliche Zeit in Delphi programmiert habe, und somit auch 'dort' zuhause wäre.
Win98 deshalb, weil ich von etlichen Anwendern weiß, dass sie sich extra Laptops für Wettkämpfe angeschafft haben (billig bei ebay geschossen), damit sie nicht ihre 'richtigen' Rechner mit zur Wettkampfstätte nehmen müssen (hups, da stand eine Kaffeetasse?!) und das sind halt keine aktuellen Rechner. .NET hatte ich eigentlich schon abgeschrieben, weil ich dachte, dass mindestens Win2000 Vorraussetzung sei (hatte nur die Anforderungen für's SDK mir angeschaut).

Bei der DB werde ich mir dann wohl Firebird anschauen. Ich brauche nämlich lediglich die 'Basic'-SQL-Statements (Insert, Update, Delete, Select). Trigger u.ä. werde ich aller Wahrscheinlichkeit nicht brauchen.

XML-Dateien hatte ich auch angedacht, aber ganz schnell wieder verworfen, weil ich die Datensätze verschieden sortiert abfragen können muss und außerdem soll die Möglichkeit bestehen, dass eine andere Anwendung auf einem anderen Rechner, auf die Daten zugreifen können soll. Und da scheint mir eine DB das geeigneteste zu sein.

Wer noch mehr Ideen oder Meinungen hat, immer her damit. Ansonsten denke ich mal, dass ich sowohl in C# als auch in Delphi VCL mal einen kleinen Prototypen bastel und dann schaue, was mir mehr liegt.

[Thanatos81]

Zitat von Joachim Rohde:

XML-Dateien hatte ich auch angedacht, aber ganz schnell wieder verworfen, weil ich die Datensätze verschieden sortiert abfragen können muss ...

Das wäre kein Problem, dafür hat das TClientDataSet die Eigenschaft IndexFields. Einfach die Felder angeben, und fertig

Zitat von Joachim Rohde:

...und außerdem soll die Möglichkeit bestehen, dass eine andere Anwendung auf einem anderen Rechner, auf die Daten zugreifen können soll. Und da scheint mir eine DB das geeigneteste zu sein.

DAS wiederum ist das K.O. fürs TClientDataSet Das lässt AFAIK nur Einzelverbindungen zu

Falls du aber später Daten nach XMl exportieren musst/willst, schau dir mal die Jedis an, da gibts ne Komponente JvDBGridXMLExport, könnte dann praktisch sein

[mschaefer]

Moin, moin

Zitat von Joachim Rohde:

Bei der DB werde ich mir dann wohl Firebird anschauen. Ich brauche nämlich lediglich die 'Basic'-SQL-Statements (Insert, Update, Delete, Select). Trigger u.ä. werde ich aller Wahrscheinlichkeit nicht brauchen.

Also ohne Generatoren und Trigger geht keine vernünftige Firebird-Datenbank. Das ist durchaus mit einiger Einarbeitung verbunden. Die Embedded-Version ist allerdings ohne Probleme auch auf Win98 zum laufen zu bringen.

Wenn Du diese Einarbeitungsphase nicht möchtest, dann schaue Dir die "Absolute-Database" an. Für die dargestelle Aufgabe reicht die weithin aus.

Grüße // Martin

[Bernhard Geyer]

Zitat von Robert_G:

a) es sind nur 23MB (und nichtmal ein Neustart), wenn du dein Programm auf eine CD packst hast du dafür sicher Platz.

Aber auf der Platte nimmt es schon einiges ein. Bei mir ca. 1/4 GB. Und .NET 2.0 wird noch größer.
Und das mit dem neustart stimmt nur wenn schon das Betriebssystem halbwegs aktuell ist. Unter einem blanken 98 sind z.B 2-3 Reboots nötig und gesonderte Installation eines IE's.

Zitat von Robert_G:

d) Ist Win98 wirklich ein Thema? ( *Geschichtsbücher umschreibt...*)

Noch kann man 98 nicht komplett vergessen. Ich selbst habe bin auch an einer CD-Startbaren Anwendung beteiligt und da kommt auch in 2005 ab und zu noch Win98 unter (jedoch eher aus Osteuropa oder Afrika als aus Westeuropa).


VCL.NET ist wirklich nur für portierungen von Win32 auf .NET gedacht auch wenn diverse Borland-Postings (VCL.NET auf PocketPC's) dies suggerieren. Man hat nunmal gegenüber einem reinrassigen FCL-Projekt mit VCL einige Nachteile. Aktuell keine PocketPC-Unterstützung. Mehr Rechte nötig (Problematischer bei Firmeninstallationen). In manchen Bereichen um einiges langsamer.

Wenn man in 2005 ein Programm neu entwickelt ist .NET eine Alternative zur Win32-Entwicklung. Du mußt dir jedoch die Vor- und Nachteile von Win32 <-> .NET gegenüberstellen und selbst entscheiden.

[Joachim Rohde]

Danke nochmal für die Beiträge. Da ich keinen Zeitrahmen habe, werde ich vorher etwas herumprobieren, bevor ich mich entscheide. Aber mit diesen Beiträgen ist mir schonmal geholfen.