Laden...

Entscheidungshilfe zu einer Datenbank: Welche verwenden?

Erstellt von Jesfreric vor 7 Jahren Letzter Beitrag vor 7 Jahren 3.549 Views
J
Jesfreric Themenstarter:in
40 Beiträge seit 2016
vor 7 Jahren
Entscheidungshilfe zu einer Datenbank: Welche verwenden?

Liebe Community

Ich hoffe ich liege mit meiner Frage hier in dem Bereich nicht völlig falsch. Bitte entschuldigt, falls ich völlig dumme Fragen stelle, aber Datenbanken sind noch ziemliches Neuland für mich…
Ich soll an meiner Arbeitsstelle eine Art „Middleware“ für bestimmte Laborbefunde schreiben. Die Ideen meiner Vorgesetzten lassen sich gut realisieren denke ich, allerdings bin ich etwas unsicher was die Verwendung der Datenbank betrifft.
Der Workflow sieht folgendermaßen aus:

  1. Am Messgerät werden von einem Mitarbeiter Proben vermessen und die Ergebnisse später (mit Hilfe einer Middleware) kontrolliert, eingegeben, etc….
  2. Die Daten werden von der Middleware aus an eine extra dafür installierte Datenbank übergeben
  3. Unsere Endvalidierer (zwischen 5-10 Personen) kontrollieren diese Werte
  4. Nach deren Freigabe werden die Ergebnisse in unsere Zentrale Labordatenbank übergeben

Der Workflow an sich ist sehr statisch, sodass wenig „Veränderungen“ möglich sind. Kopfzerbrechen bereitet mir die Datenbank. Es werden täglich (an Wochentagen) bis zu 300 neue Datensätze eingespielt.
Meine Fragen wären, bezogen auf die Datenmenge…

  1. Welche Datenbank sollte ich verwenden?
    • MySQL, Oracle SQL, etc.
  2. Welche Installation ist sinnvoll?
  • sollte die Datenbank lokal auf einem leistungsstarken Rechner (an dem das Messgerät angeschlossen ist) installiert werden und die Datenbankdateien in unserem Netzwerk freigegeben werden – immerhin wären es vielleicht gerade einmal 10 Rechner die parallel darauf zugreifen würden
  • oder sollte die Datenbank auf einem unserer zentralen Serversysteme laufen
  • falls ja, wie erfolgt hier eine Installation – ist diese äquivalent zu oben? (Aufspielen der Datenbank + Freigabe der Datenbankdateien?)

Viele Grüße
Jesfreric

16.827 Beiträge seit 2008
vor 7 Jahren

Die Frage ist so genau wie "Was soll ich heute Abend essen?" 😉

Ob eine DB wie Oracle infrage kommt, kommt auch auf euren Geldbeutel an.
300 simple Datensätze pro Tag verkraftet sogar eine XML Datei. Dazu alleine braucht man keine Datenbank 😃
Dazu braucht man auch keinen leistungsstarken Rechner. Das würde jeder RaspberryPI locker packen.
Lokale Datenbankdateien vermeidet man, da man auf diese nicht ohne Risiko parallel schreibend zugreifen kann.

Allgemein greift man bei einer Client Server Anwendung - nichts anderes hast Du - nicht mehr direkt auf eine Datenbank zu.
I.d.R. ist ein Zugriff über einen Service, der sich dazwischen befindet, in den aller meisten Fällen der bessere und einfachere Weg.

Dadurch kann dem Client herzlich egal sein, welche Datenbank dahinter sitzt.
Die Middleware stellt nur einen REST / OData API zur Verfügung.

Bei dem Szenario also zB.

  • MSSQL Server 2016 Express
  • Webservice mit OData API
  • Client, der auf die OData API zugreift

Wie die Installation erfolgt kannst Du dann den jeweils vorhandenen Anleitungen entnehmen.
Alle von mir hier genannten Dinge sind gut, offiziell dokumentiert.

J
Jesfreric Themenstarter:in
40 Beiträge seit 2016
vor 7 Jahren

Hallo Abt

Vielen Dank für deine Antwort. Bitte entschuldige die "Laienhafte" Fragestellung 😃

Wegen den 300 Datensätzen pro Tag...Also es kämen praktisch jeden Tag 300 Datensätze neu dazu. Das wären dann im Monat ungefähr 7000 Datensätze, im Jahr dementsprechend 80 k.
Sollte man bei so einer Zahl wirklich noch mit XML Dokumente arbeiten?
Die Daten sollten auch immer abrufbar sein...

Viele Grüße
Jesfreric

16.827 Beiträge seit 2008
vor 7 Jahren

Ich hab nirgends geschrieben "soll".
Der Inhalt dieses Kommentars ist, dass das keinerlei relevante Datenmenge für eine Datenbank ist - auch in 10 Jahren x 300 Einträge pro Tag ist das immer noch enorm wenig für eine Datenbank.

3.825 Beiträge seit 2006
vor 7 Jahren

Hallo Jesfreric,

Deine Aufgabenstellung kann von so ziemlich jeder Datenbank erledigt werden.

Ich empfehle Dir den Microsoft SQL Server 2016 Express Edition. Das SQL Management Studio gleich dazu installieren.

Die Datenbankdateien werden nicht im Netzwerk freigegeben, sondern ausschließlich vom SQL Server verwaltet. So verhindert man Datenverluste und erhöht Sicherheit und Geschwindigkeit.Der Client oder die Middleware kommuniziert dann mit dem SQL Server per TCP/IP, Named Pipes oder Shared Memory.

Der SQL Server sollte auf einem zentralem Server installiert werden, nicht auf einem Arbeitsplatz.

Hinweis zur Installation : Gemischte Authentifizierung = Ja, TCP/IP überall einschalten, SQL-Browserdienst Startart automatisch, Windows Firewall erstmal ausschalten.

Eine ausführliche Installationsanleitung zur Installation eines SQL Servers in einem Netzwerk stelle ich gerne zur Verfügung.

Grüße Bernd

Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3

J
Jesfreric Themenstarter:in
40 Beiträge seit 2016
vor 7 Jahren

Hallo

Danke für eure Antworten=)

Ich werde die Problematik noch einmal mit unserer örtlichen IT besprechen und mich dann nochmal bei euch melden=)

Viele Grüße und vielen dank
Jesfreric

C
1.214 Beiträge seit 2006
vor 7 Jahren

Ich würde hier von jeglichen komplexen Datenbanken abraten und eher Sql Server Compact oder Sqlite nehmen (im .NET Umfeld wohl eher den Sql Server Compact). Dann musst du auf dem Server auch nichts installieren.

Alles andere ist evtl. deutlich erhöhter Administrationsaufwand. Oracle würde ich hier gar nicht ins Spiel bringen, das wird die wahrscheinlich mittelfristig völlig grundlos Kopfzerbrechen bereiten. Der Sql Server ist deutlich überschaubarer, aber wenn dir eine Embedded Datenbank wie Sql Server Compact reicht, würde ich auf jeden Fall sowas nehmen.

16.827 Beiträge seit 2008
vor 7 Jahren

SqlCE wurde vor 3 Jahren abgekündigt. Es wird weder neue Versionen noch Updates geben.
Damit würde ich heute nichts mehr anfangen.

C
1.214 Beiträge seit 2006
vor 7 Jahren

Danke für die Info, hatte ich leider nicht mitbekommen.