Grundsatzfrage zu Datenbankprojekt

[bernhard_LA]

unter dem Link von oben findet dann man
..... Summa Summarum sollte man heute neue Entwicklungen den ADO.NET Sql Client
oder den SQL Server Native Client ODBC Treiber einsetzen.
Altanwendungen haben durch den längeren Horizont (7 Jahre) eine größere Gnadenfrist....



soll ich dann heute nicht mehr mit dbgo / ADO entwickeln weil dieses Thema mittelfristig nicht mehr unterstützt wird

[mkinzler]

Ja. Obwohl. man hat ja versucht mit ADO von ODBC wegzukommen und rät nun wieder zur Ur-Alt Technik ODBC. Vielleicht sieht man es in Redmond in 2 Jahren wieder anders und setzt wieder auf ADO oder was ganz neues.

[Bernhard Geyer]

Zitat von mkinzler:

Ja. Obwohl. man hat ja versucht mit ADO von ODBC wegzukommen und rät nun wieder zur Ur-Alt Technik ODBC. Vielleicht sieht man es in Redmond in 2 Jahren wieder anders und setzt wieder auf ADO oder was ganz neues.

Mit entsprechender Kapslung dürfte der Technologiewechsel implementierungstechnisch wenige Aufwand verursachen.
Unser ADO-MSSQL-Interface ist ca. 2500 Zeilen lang. Dürfte sich also in Grenzen halten das zu wechseln.

ich würde die üblichen 3th-Party-Komponenten Verdächtigen (DevArt und Co.) fragen was sie da anbieten werden. Wenn diese den technologiewechsel im Hintegrund transparent gestalten wären die Kosten der Kompos mehr als Kostenneutral diese zu verwenden.

[bernhard_LA]

dann wird mein Code ja noch Schrottiger

Delphi-Quellcode:

{$IF DEFINED(ZEOS)}
{$DEFINE USEDATABASE}

{$ELSEIF DEFINED(BDE)}
{$DEFINE USEDATABASENOSERVER}
{$DEFINE USEDATABASE}

{$ELSEIF DEFINED(ADO)}
{$DEFINE USEDATABASESQL}
{$DEFINE USEDATABASE}

{$ELSEIF DEFINED(DBEXPRESS)}
{$DEFINE USEDATABASESQL}
{$DEFINE USEDATABASE}

{$ELSE}
{$DEFINE NODATABASE}    // Flag for Code without need for DB Interface 
{$IFEND}

mit jedem Windows Wechsel gibt es dann ein paar $ELSEIF mehr im Code und jede Menge neue Probleme und Bugs

[Lemmy]

Was für einen Sinn macht es eine Umstellung auf ein Produkt zu machen, das abgekündigt ist? Außer das Projekt würde in 6-7 Jahren eh eingestellt.... ansonsten würde das jetzt noch stoppen so lange nicht viel Arbeit rein geflossen ist....

@Stahli: Nutze ORM wenn Du darin schon Erfahrung hast, oder wenn Du die Zeit bekommst dich damit zu befassen (und lern bitte nicht gleich an dem Projekt, sondern setz erst mal einen Prototyp um, mit dem du ein paar wenige zentrale Funktionen die deine Anwender zwingend brauchen, testen kannst wie man das mit dem ORM umsetzt.

Firebird reicht für diese Menge an Daten und Anwendern locker aus. Somit stellst Du dir bei dir in der Abteilung einen kleinen Server incl. USV hin, dann brauchst Du die IT-Abteilung nicht einzubinden (wenn Du diese Freiheit hast).

Wenn es sehr schnell gehen soll: Schau dir mal die IBDAC an, die bieten einen BDE-WIzard an, mit dem kannst Du die Anwendung sehr schnell umstellen, allerdings musst Du diese dann noch optimieren (was Zeit kostet).

Weiterhin solltest Du dir Gedanken machen, wenn Du schon umstellst ob dein Datenbankmodell noch zur Aufgabenstellung passt. Wenn nicht - nutze die Chance einer gründlichen Überarbeitung....

Grüße