MS-Access oder MS-SQL?

[freimatz]

Hallo,
ich habe eine Anwendung, die unterstützt MS-Access oder MS-SQL. Für automatische Tests gibt es Testdatenbanken.
Ich frage mich welches der beiden Formate ich für Test-Datenbanken verwenden soll. Lokal habe ich mal MS-SQL Express installiert und kann mit dem Management Studio die DB auch anschauen.
Als erster kleiner Nachteil für MS-SQL ist bei uns, dass man das erst mal installieren muss. Dann habe ich den Platzbedarf angeschaut. Eine "leere" Datenbank bei unserer Anwendung benötigt schon mal 500 KByte. Das finde ich viel. Eine analoge *.mdf benötigt jedoch 8192 KByte. Das ist schon mal deutlich mehr. Wenn ich die DB dann als SQL exportiere, dann hat die Datei nur noch 75KByte. Wenn ich also bei den Tests die DB aus dem SQL-Code erstelle, wäre der Platzbedarf kleiner. (Mein Plan wäre die DB oder den SQL-Code in git zu speichern)
Eine weitere Frage ist welchen Ressourcenbedarf das SM-SQL hat. Die Tests laufen auf VMs die nicht so üppig bestückt sind wie mein lokaler PC.
Ich wäre dankbar für Meinungen und RTFMs dazu.

[Uwe Raabe]

Zitat:

Zitat von freimatz (Beitrag 1436979)

Lokal habe ich mal MS-SQL Express installiert

Eventuell kannst du auch mal auf SQL Express LocalDB schauen.

Den Ansatz mit den SQL-Scripts würde ich auch empfehlen. Das macht sich auch besser in der Versionsverwaltung.

[mkinzler]

Grundsätzlich würde ich aber immer ein "richtiges" DBMS, also den SQL-Server, bevorzugen. Auch die "Datenbankengine" von Access muss installiert werden (ist aber oft schon der Fall).

[hoika]

Hallo,
500 kB passen ja gerade so auf eine Festplatte ...
Deine Problem möchte ich haben ;)

Nein, im Ernst.
Der Platz darf keine Rolle spielen.

Zum Test.
Du musst natürlich 2 Datenbanken testen,
wenn du 2 Datenbanken beim Kunden anbietest.

[freimatz]

Danke für die Antworten.

@Uwe:
SQL Express LocalDB habe ich gesehen. Soweit ich das verstehe müsste ich dazu die Anwendung ändert, zumindest das Setup. Das will (oder darf) ich gerade nicht.
Nebenbei schau ich mir gerade ein Kurs "DevOps for databases" an. Die committen auch immer nur SQL-Scrips. Von daher denke ich kann die Zielrichtung nicht falsch sein.

@mkinzler: die access ist schon drauf. Bei der MS-SQL muss ich aber zum Verantwortlichen für die virtuellen Maschinen der automatischen Tests laufen und betteln, dass ich nun auch noch MS-SQL Express drauf haben will. :wink:
Da möchte ich zuvor erst mal alle Argumente sammeln.

@hoika: Da habe ich mich wohl missverständlich ausgedrückt. Die 500 kB sind für eine leere Datenbankdatei. Da es aber tausende an Testes gibt, die idealerweise jede ihre eigene Datenbank hat werden es schon mehr. Ausserdem werden alle Änderungen dann im Versionscontrolsystem eingecheckt und dann finden sich irgendwann auf zigs PC alle Datenbanken in allen möglichen Versionen wieder.

[hoika]

Hallo,

Zitat:

dann finden sich irgendwann auf zigs PC alle Datenbanken in allen möglichen Versionen

Hm, na und.
Das hat mit den Tests doch nichts zu tun.
Die Testdatenbanken sind doch zentral.
Das Management kann nervig sein, ja.

Ich hatte in meiner alten Firma knapp 300 FB-Datenbanken mit unterschiedlichen Tests.
(Viele Konfigurationsparameter waren auch in der Datenbank
und viele Routinen haben die Parameter benutzt).

Also habe ich eine leere DB genommen,
Mit dem Programm selbst rumkonfiguriert, TestDaten eingegeben.
die DB auf den Testserver gepackt und die entsprechenden Tests dazu geschrieben.

[freimatz]

Nein, die Testdatenbanken sind nicht zentral.
Diese sollen zum jeweiligen Test gehörig gespeichert und mit dem Test versioniert werden.

[hoika]

Hallo,
also habt ihr keine zentrale Stelle, wo die Tests abgelegt sind?
Finde ich nicht soo gut, ich hoffe, ihr macht auf allen Rechnern Backups.

[freimatz]

Wir verwenden git, das ist ein DVCS (siehe https://de.wikipedia.org/wiki/Versionsverwaltung). Da ist alles verteilt, auch die Testdatenbanken. Wir haben schon auch irgendwo ein clon der auch gesichert wird.

Allgemein: Danke für alle Anregungen. Ich werde als nächstes mal mit dem Konvertieren der DB von und zu SQL-Scripts beschäftigen.

[Schokohase]

Die eigentliche Frage ist doch was du eigentlich testen willst.

Wenn du mit echten Datenbanken herumhantierst, dann ist es auf jeden Fall schon mal kein Unit-Test sondern ein Integration-Test.

Wenn du diesen mit der Access-Datenbank durchführst, dann kannst du nachher auch nur sagen, dass es mit der Access-Datenbank funktioniert hat. Mehr nicht. Einen Rückschluss auf die Funktionalität mit dem SQL-Server lässt das nicht zu.

Also, was genau soll dieser Test an Erkenntnis bringen, bzw. was genau willst du damit testen?

Dann können wir die Frage auch sinnvoll beantworten.