[DB] Welche Datenbank benutzen?

[cyberwulf]

Hi
Wir müssen uns theoretisch (momentan) ein paar Gedanken über eine Netzwerkdatenbank machen.
Es stehen Datei-Datenbanken wie TXT/CSV/XML und richtige Datenbanken wie MySQL/MSSQL (Express)/ ACCESS zur Auswahl.

Welche Variante würdet ihr empfehlen?

Vorgaben:
- Visual Basic Programmiersprache
- Mehrplatzfähig
- Server/Client Version
- Mobile Version für Einzelplatz

Ich tendiere ja zur MSSql-Variante, was natürlich immer einen Server bzw ODBC-Schnittstelle voraussetzt. Nur da weiß ich dann noch nicht wie ich die mobile Station anbinden kann?!? Eventuell müsste dort ja auch ein MSSql mit installiert werden oder gibt es dort andere Wege?

Thx

Grüsse

CW
(*kopfzerbrechent*)

 

[ice-breaker]

Vllt solltest du das mit deinem Team (wegen wir) besprechen, da wir rein gar nichts über deine Software wissen, werden wir da auch keinerlei guten Tipps geben können, bis auf einen: Eine "Datenbank" auf Txt-Dateien-Basis ist Mist.

 

[theHacker]

Auch wenn ich von diesem Thema nicht wirklich so viel Ahnung habe, möchte ich dir die Textdatenbanken schon mal ausreden, wenn es um größere Datenmengen geht.

Es macht nämlich einen Unterschied, ob ich jetzt eine CSV-Datei hab, wo 10.000 Städtenamen und daneben die Postzeitzahl steht und ich eben mal nachgucken muss, in welcher Stadt die 88888 als PLZ is oder ein

[FONT=Courier New][B][COLOR=#9932cc]SELECT[/COLOR][/B] kunde.name, kunde.vorname, [B][COLOR=#9932cc]COUNT[/COLOR][/B][COLOR=#9932cc]([/COLOR]*[COLOR=#9932cc])[/COLOR] [B][COLOR=#9932cc]AS[/COLOR][/B] artikelanzahl, [B][COLOR=#9932cc]SUM[/COLOR][/B][COLOR=#9932cc]([/COLOR]artikel.einkaufspreis[COLOR=#9932cc])[/COLOR] [B][COLOR=#9932cc]AS[/COLOR][/B] epreis, [B][COLOR=#9932cc]SUM[/COLOR][/B][COLOR=#9932cc]([/COLOR]artikel.preis[COLOR=#9932cc])[/COLOR] [B][COLOR=#9932cc]AS[/COLOR][/B] umsatz
[B][COLOR=#9932cc]FROM[/COLOR][/B] artikelbestand
[B][COLOR=#9932cc]JOIN[/COLOR][/B] artikel [B][COLOR=#9932cc]ON[/COLOR][/B] artikel.aid = artikelbestand.abid
[B][COLOR=#9932cc]JOIN[/COLOR][/B] bestellung [B][COLOR=#9932cc]ON[/COLOR][/B] bestellung.artikel = artikel.aid
[B][COLOR=#9932cc]JOIN[/COLOR][/B] kundenbestellung [B][COLOR=#9932cc]ON[/COLOR][/B] kundenbestellung.kbid = bestellung.bid
[B][COLOR=#9932cc]JOIN[/COLOR][/B] kunde [B][COLOR=#9932cc]ON[/COLOR][/B] kunde.kid = bestellung.kunde
[B][COLOR=#9932cc]GROUP[/COLOR][/B] [B][COLOR=#9932cc]BY[/COLOR][/B] kunde.tarif, kunde.name, kunde.vorname
[B][COLOR=#9932cc]HAVING[/COLOR][/B] kunde.tarif [B][COLOR=#9932cc]BETWEEN[/COLOR][/B] 2 [B][COLOR=#9932cc]AND[/COLOR][/B] 5
[B][COLOR=#9932cc]WHERE[/COLOR][/B] umsatz > epreis * 0.32
[B][COLOR=#9932cc]ORDER[/COLOR][/B] [B][COLOR=#9932cc]BY[/COLOR][/B] kunde.name [B][COLOR=#9932cc]ASC[/COLOR][/B], kunde.vorname [B][COLOR=#9932cc]DESC[/COLOR][/B];[/FONT]

auf eine Datenbank mit 10.000.000 Einträgen

edit:
Ich war zuerst da!

 

[cyberwulf]

Wir / bzw jeder einzelne (15 Mann) sollten uns halt darüber Gedanken machen und es soll ein Datenbankbasiertes Erfassungssystem für Schülerdaten (Name, Klasse, Stundenplan, Dozent usw.) werden.

Ja die TXT-Dateien bzw CSV/XML habe ich eigentlich schon abgehakt, aber mir fehlen halt die Gedanken wie man eine Einzel-Mobil-Lösung noch dazu anbinden kann.

Meine Gedanken belaufen sich dahin das man die daten die man mobil braucht auf dem server sperrt, exportiert, einspielt auf notebook und beim rückspielen diese dann wieder auf dem server freigibt, damit keine revisionsänderungen verloren gehen.

Meine Unwissenheit ist halt ob man das ganze auch mit ACCESS-Datenbanken machen kann oder lieber gleich die MSSQL-Express-Version nimmt (Performance, Netzwerksicherheit usw.)?!?

THX für Ideen / Grüsse

 

[theHacker]

Meine Gedanken belaufen sich dahin das man die daten die man mobil braucht auf dem server sperrt, exportiert, einspielt auf notebook und beim rückspielen diese dann wieder auf dem server freigibt, damit keine revisionsänderungen verloren gehen.

Kommt schon mal grundsätzlich an, was du haben willst:

• online
  Keine Probleme. Wer Daten lesen oder schreiben will, verbindet auf die Datenbank und arbeitet auf ihr. Die Mobilgeräte müssen halt geeignet über Netzwerkverbindung (WLAN, WAN, LAN, PAN) verfügen.

• offline
  Würd ich mit Synchronisation rangehen. Das Mobilgerät holt sich die Daten (die es braucht). Solange jemand nur lesend zugreift, hat er maximal das Problem, dass er eine Änderung, die ein anderer gemacht hat, nicht mitkriegt. Bei einem Schreibzugriff ändert er lokal auf dem Gerät die Daten. Sobald wieder am Server, synchronisiert er seine Änderungen, d.h. sendet sie an die Datenbank. Haben mehrere Leute geändert, so muss der Konflikt aufgelöst werden, d.h. Änderungsdatum speichern, anzeigen und dann je nach Anforderungsspezifikation vorgehen (entweder der neueste setzt sich durch oder Konfliktbehebung von Hand oder wer die schlechtere Note gibt, setzt sich durch, ....).

 

[cyberwulf]

so wie ich das Einschätze sollen beide Ansätze (online/offline) funktionieren, was ja durchaus mit einem Konfigurationsaufruf machbar wäre.

Jetzt nur noch die Frage ob man die SLQ-variante auf der mobilen station benutzt oder dort dann mit einer anderen datenhaltung arbeitet?

 

[ice-breaker]

Ich verstehe ehrlich gesagt nicht warum man offline Daten ändern können muss, die Synchronisation kann von der Komplexität sowas von schlimm werden, wenn mehrere die gleichen Daten ändern, da wäre es deutlich einfacher alles nur online machen zu können.

 

[mister_nu]

Also falls man tatsächlich auf den mobilen Clients unbedingt eine Datenbank braucht, würde ich da SQLite nehmen. Dafür sollte es auch Visual-Basic-Bindings geben.

Trotzdem würde ich tatsächlich empfehlen, Schreibzugriffe nur bei einer Verbindung zum Server zu zulassen. Den Server würde ich SQL-basiert gestalten -- ob man da MySQL, MSSQL, PostgreSQL oder noch was anderes nimmt ist eine Geschmacks- und Preisfrage und kommt auch sehr auf den Einsatzzweck an.

 

[cyberwulf]

Ok Danke schon mal.

weitere Gedanken:
der Lehrer möchte gerne Zuhause die Noten / Fehlstunden usw eingeben.

Also geht er hin und "exportiert" die Klasse und sperrt die somit zur Bearbeitung auf der Server-DB. Dann importiert er diese auf seinem Notebook nimmt das mit nach hause, bearbeitet diese und spielt das ganze am nächsten Tag wieder zurück. Falls er das vergißt(oder krank wird) und jemand anderes braucht die Daten dann könnte ein ADMIN hingehen und die Daten freischalten. Dann könnte der Lehrer halt die Daten nicht zurückspielen und muss sie dann "ONLINE" neu eingeben (EINZELSCHICKSAL).

Wenn jetzt noch Dokumente abgespeichert werden sollen (Krankmeldungen der Schüler oder sonstige Entschuldigungen), kann man diese dann irgendwie in eine ACCESS-DB einbinden (BLOB) oder lieber ein Dateisystem-LINK machen?
Ich denke wenn dann nachher etliche Dateien da rein kommen sollen wäre dann von vornerein ein SQL-Datenbank-Server besser.

Ich wäre ja für die Dateistruktur, worauf dann nur die ACCESS-DB Zugriff hätte bzw die Dateiennamen dann umbennnen und in einer Ordnerstruktur ablegen.

THX

CW

 

[ice-breaker]

Also geht er hin und "exportiert" die Klasse und sperrt die somit zur Bearbeitung auf der Server-DB. Dann importiert er diese auf seinem Notebook nimmt das mit nach hause, bearbeitet diese und spielt das ganze am nächsten Tag wieder zurück. Falls er das vergißt(oder krank wird) und jemand anderes braucht die Daten dann könnte ein ADMIN hingehen und die Daten freischalten. Dann könnte der Lehrer halt die Daten nicht zurückspielen und muss sie dann "ONLINE" neu eingeben (EINZELSCHICKSAL).

also gerade das Locking ist doch fehleranfällig.
Wenn das Feature wirklich sein muss (ich würde ja sagen gibts nicht, oder er muss sich von zuhause online mit der Anwendung verbinden) würde ich sagen, der Lehrer legt zuhause "Jobs" an, also "Schüler X bekommt Note 5 in Fach Y unter der Vorraussetzung, dass die Note den Status Z hat".
Sollte ein Job dann so nicht funktionieren, weil der Status zB nicht mehr stimmt, bekommt der Lehrer das gesagt und muss eben dann am Live-System nochmal manuell die Note ändern.
Aber direkt Online sowas zu machen wäre eine deutlich bessere Lösung.

ACCESS-DB

ich dachte du sprachst von einer richtigen Datenbank