Grundsatzfrage zu Datenbankprojekt

[mkinzler]

Jedem Admin rollen sich jetzt die Zehennägel hoch, wenn sie an die Installationund Wartung von Oracle denken.

[p80286]

Was MSSQL und ORACLE angeht, kann ich JoBo nur zustimmen.
Mir ist allerdings im letzten jahr ein Browserfrontend "aufgedrückt" worden. Wenn es läuft, ist nichts dagegen zu sagen, wenn es allerdings irgendwo hakt, ist immer der andere Server schuld, oder das Betriebssystem oder ....
Übrigens haben wir auch einen Feuervogel im Einsatz, der vor allem durch Unauffälligkeit und Stabilität auffällt. (ca. 40 Benutzer)

Gruß
K-H

[Bernhard Geyer]

Zitat von mkinzler:

Jedem Admin rollen sich jetzt die Zehennägel hoch, wenn sie an die Installationund Wartung von Oracle denken.

und nicht nur denen.
Mussten vor kurzen erst unsere App auf einem Citrix-Server zum laufen bringen bei dem der (DB?)-Admin keinen plan hatte was jetzt für ein NET-Client installiert ist und welche TNS-Datei nur wirklich gezogen wird

[bernhard_LA]

ist ADO abgekündigt ??? wo steht das denn ?? wir potieren gerade von ZEOS nach ADO

[Bernhard Geyer]

Zitat von bernhard_LA:

ist ADO abgekündigt ??? wo steht das denn ?? wir potieren gerade von ZEOS nach ADO

z.B. hier: http://social.msdn.microsoft.com/For...2-34044d5ef396

[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.

[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

[jobo]

OT

Zitat von Bernhard Geyer:

keinen plan hatte was jetzt für ein NET-Client installiert ist und welche TNS-Datei nur wirklich gezogen wird

Nebenbei
Man kann das als Stärke oder Schwäche sehen, Oracle bietet allein dutzende Entwicklertools, alle können autark, nebeneinander auf einem System installiert sein. Das gleiche gilt für Datenbanken und andere Serverprodukte. Das ist natürlich nicht unbedingt übersichtlich.
Komfortable und robuste UI, gerade bei Installation, sind aber wirklich nicht Oracles Stärke. Da könnten sie sich mal ne Scheibe von MS abschneiden. M.E. merkt man bei Oracle Produkten sofort, wenn sie "ihre" Unix/Solaris Welt verlassen und das fängt ja schon auf der x86 Client Installation an.

Zu TNS
Dazu kann ich Entwickler und Admins nur empfehlen, TNSPING zu verwenden, seit Version 9 oder so, zeigt es nicht nur an, dass es irgendwo auf der DB ankommt, sondern auch welche Config Datei es dazu verwendet. Damit kostet es eine Sekunde rauszufinden, wo der Hase läuft.

Wem das zu anstrengend ist, der kann seit Version 10 Easy Connect nehmen. Hier wird der komplette Zugang im Connection String definiert, ähnlich wie bei JDBC URL, keine Konfigdateien.