MS-Access oder MS-SQL?

[hoika]

Hallo,

Zitat:

Ja so stelle ich mir das ungefähr vor. Als die DB aus einem versionierten Script erzeugen und nicht eine vorhandene DB benutzen.

Du solltest du aufpassen.
Beim Kunden ist ja nie eine neue DB, sondern immer eine alte mit einem DB-Update.
Aber genau das ist ja wahrscheinlich in Euren Tests auch mit drin.

PS:
Wir hatten auch schon Kunden mit einer 5 Jahre alten DB-Struktur, wo unser DB-Update fehlgeschlagen ist, weil wir nur 4.9 Jahre ( ) zurückgeschaut hatten.

[mkinzler]

Zitat:

Für eine dritte Variante (SQLite war mal mein Favorit) ist derzeit kein Bedarf. Den Anwendern ist das Format egal (ausser ganz wenigen die die Daten auf Ihrem zentralen MS-SQL-Server haben wollen)

Vorteil von FireBird wäre aber, dass eine Lösung sowohl embedded wie auch mit einem zentralen Server funktioniert.
Es werden nicht 2 verschiedene Varianten benötigt.

[freimatz]

Für DB-Updates haben m.W. unit tests.
Überdies bin ich der Meinung dass das den jeweiligen Tests egal sein muss (https://de.wikipedia.org/wiki/Single...bility-Prinzip).
Natürlich muss man neben den konkreten syntetischen Test auch allgemeine Tests möglichst nahe am Kunden haben.

[jobo]

Zitat von freimatz:

Überdies bin ich der Meinung dass das den jeweiligen Tests egal sein muss

Ja, bei einem GUI Test sieht es vielleicht anders aus, vielleicht.
Es soll ja immer das gleiche abgespult/getestet werden. Irgendwo in der Anwendung ist aber das Mapping auf eine spezifische DB, das kann halt mal schief gehen.

[freejay]

Also ich habe früher (vor 20 Jahren...) sehr viel mit Access gemacht, fand es - für damalige Verhältnisse - ein tolles System, inklusive Oberflächenentwicklung und so. Auch die Performance war erstaunlich gut: Wie ich später die Daten auf MySQL umgezogen habe, musste ich viele Abfragen umgestallten, weil MySQL in machen Fällen - bei gleicher Datenmenge, Tabellen- und Query-Definition - wesentlich langsamer als Access war!

Damals war - in meinem Arbeitsumfeld - eine "echte" Datenbank meist noch ein Großrechnerthema, also waren die Alternativen dünn gesäht...

Aber heutzutage käme ich im Bereich Anwendugsentwicklung nie mehr auf die Idee, statt einer "richtigen" Datenbank Access zu benutzen. Die Zeiten von Access sind einfach vorbei.