Welche Datenbank.

[holgerbremen]

Zitat:

"Könnte" hat im Pflichtenheft nix zu suchen.

Genau, deswegen wird die Anwendung auch Multiuserfähig werden. Das lege ich fest.

Zitat:

Wenn du graue Haare oder Stellen mit Ausgerissenen Haaren magst kannst du gerne bei Access bleiben.
Willst du dagegen ohne (maximalen) frust auf das DBMS Abends nach Hause gehen nimm lieber keine Access

Ich will auch kein Access, geraden wegen der Probleme mit zerschossenen Datenbanken. Der Kunden hatte leider bisher diese im Einsatz und ich will ihn von anderen Systemen überzeugen.

Zitat:

Was spricht im Firmenumfeld gegen eine vernüftige Installion eines DB-Servers? Firebird ist auch für kommerziellen Einsatz frei und offenbar für normale Anbwendungsfälle auch ausreichend schnell und stabil.

Weil die IT-Abteilung des Kunden es nicht zuläßt, derartige Installationen zu machen. Dafür hat das Projekt eine zu niedrige Priotät beim Kunden.

[p80286]

Zitat:

Zitat von holgerbremen (Beitrag 1198541)

Weil die IT-Abteilung des Kunden es nicht zuläßt, derartige Installationen zu machen. Dafür hat das Projekt eine zu niedrige Priotät beim Kunden.

Kommt mir bekannt vor. Bei mir steht ein ganz normaler desktop-PC der eine kleine DB für die Abteilung hostet.
Wenn man mit möglichem Hardwareausfall von ca 1Woche leben kann geht das. Ist halt kein Server.

Gruß
K-H

[Bernhard Geyer]

Zitat:

Zitat von BUG (Beitrag 1198526)

Afaik sollte man Multiuserzugriff auf Netzwerklaufwerken mit Embedded Datenbanken vermeiden wo es geht. Da kann soviel schief gehen ... je nach Protokoll/Implementierung des Laufwerk können schon einfache Locking-Operationen leise scheitern.

Vermeiden stimme ich voll zu. Aber das ist nicht immer möglich.

Zitat:

Zitat von BUG (Beitrag 1198526)

Wenn es nur irgendwie geht, setze eine richtige Datenbank ein.

Hier heißt es aber oft: Wir haben Oracle/MS SQL-Server im Einsatz. Darauf könnten wir eine DB anlegen. Aber jetzt einer weiteres DBMS einführen. Das sagen die IT-Abteilungen verständlicherweise erst mal nein. Gut wenn dann die eigene SW unterschiedliche DBMS unterstützt.

[Medium]

Zwei der vorgenannten Vorgehen wären auch meine Favoriten (Reihenfolge bewusst):

1) Nutzung eines ggf. bereits bestehenden DBMS. Der Kunde könnte/müsste seine IT dann ggf. einen entsprechenden Userzweig mit Zugriff auf nur deine Kataloge, sowie den Katalog selbst erstellen lassen. Beides von jemandem der schon nur einigermaßen weiss was er tut schnell machbar.

2) Aufstellen eines eigenen Servers mit deinem Wunsch-DBMS. Voraussetzung ist hier allerdings, dass die Kunden-IT das Einbringen externer Rechner zulässt. (Dieser ließe sich aber auch recht einfach so weit beschneiden, dass er nur DB Zugriffe erlaubt, und ggf. eine Form von Fernwartung.)


Letzteres machen wir bei einem Kunden in der Industrie für die einzelnen Produktionsbetriebe, die eine abgeschlossene Einheit sind. Jeder Betrieb hat seinen eigenen kleinen Server mit DBMS und eigenem kleinen Netzwerk für die Prozesskommunikation. Zusätzlich hängt der Server im Kundennetz, so dass wir über einen Zugangsserver an alle zur Fernwartung auch vom Büro aus dran kommen. Seit >10 Jahren läuft das Wasserdicht und ohne Zwischenfälle im Kundennetz.
Als Rechner empfehlen sich hier statt einfachen PCs jedoch eher Micro-Server mit entsprechend robuster Hardware und vor allem vernünftigem Spiegel-RAID. (Die gibt's auch schon um ca. 600€ EK aufwärts, was zum dedizierten Bedienen eines DMBS mit so wenigen Usern locker ausreicht.)

Gerade wenn die Anforderungen derart schwammig daher gelullt kommen sollte man sich möglichst offen für alles rüsten. (Oder im Zweifel den Auftrag ablehnen. Wenn etwas zu unwichtig ist, sich ein paar zumindest so grundlegende Gedanken zu machen, dann wird es eh nicht gebraucht. Aber Telefonnummer da lassen, für wenn sie dann auf die Nase gefallen sind ;))

[Bernhard Geyer]

Zitat:

Zitat von Medium (Beitrag 1198553)

2) Aufstellen eines eigenen Servers mit deinem Wunsch-DBMS. Voraussetzung ist hier allerdings, dass die Kunden-IT das Einbringen externer Rechner zulässt. (Dieser ließe sich aber auch recht einfach so weit beschneiden, dass er nur DB Zugriffe erlaubt, und ggf. eine Form von Fernwartung.)

Das wird aber noch weniger möglich sein. Mittlerweile dürfte aber eine Lösung auf VM-Basis aber eine alternative sein. Man gibt den Kunden ein VM für VM-Ware/Hyper-V/... und dieser spielt sie dann auf einem VM-Server ein. Da bei einigen Kunden die Serverräume "Heiliges Land" sind ist eine reale HW ein absolutes No-Go.

[Sir Rufo]

Wenn die Datenbank Multiuser, remote und robust sein soll - dadurch haben sich alle dateibasierende Lösungen erledigt - dann bleiben nur Systeme, die eine eigene Trasportschicht anbieten.

Das machen alle Server-Datenbanksysteme so.

Werden alle Server-Datenbanksysteme ausgeschlossen, dann bleibt - nichts?

Als eine mögliche Alternative - sozusagen durch die Hintertür - wäre evtl. mORMot = SQLite mit Transportschicht = Datenbankserver

Wenn man also dem Kunden das so verkauft, dass man für MultiUser ein laufendes Programm auf einem Server habe muss :stupid:

[mkinzler]

Dann könnte man dann einfach den Datenbankserver anders bezeichnen :mrgreen:

[Sir Rufo]

Zitat:

Zitat von mkinzler (Beitrag 1198590)

Dann könnte man dann einfach den Datenbankserver anders bezeichnen :mrgreen:

Datenverbindungsbereitsteller :mrgreen:

[QuickAndDirty]

Zitat:

Zitat von Sir Rufo (Beitrag 1198591)

Zitat:

Zitat von mkinzler (Beitrag 1198590)

Dann könnte man dann einfach den Datenbankserver anders bezeichnen :mrgreen:

Datenverbindungsbereitsteller :mrgreen:

Oder Application-Server
Und dann könnte man auch gleich ne ordentliche Trennung zwischen Geschäftlogik und Oberfläche hinbekommen, wenn die Logik da läuft wo die embeded Datenbank auch liegt...

@OP:
Mal ne frage : Kann es sein, dass des Kunden IT in ein Rechenzentrum ausgelagert wurde ? Ich habe vermehrt fest gestellt das Rechenzentren die ihren Kunden rein virtuelle Arbeitsplätze aufschwatzen, mit Server installationen schonmal so ihre Probleme haben (vor allem wenn man mal "schnell" Fernwarten muss). Deswegen kann ich den Ansatz verstehen, wenn man vermeiden will das man die IT eines Rechenzentrums involviert.

Allerdings sollte eine MultiUser zugriff auf die Daten für derartige Projekte ausgeschlossen werden. Es gibt keine Methode bei filebasierten Datenbanken über SMB oder SMB2 einen zuverlässigen Mehrbenutzerzugriff zu gewährleisten. Deine Anwendung müsste diesen Zugriff schlicht sperren.

Ich würde keinem Kunden versprechen das er mit einer datei basierten Datenbank Multiuserzugriffe bekommt. Bzw.das ich mich irgendwie für das Sichern, Wiederherstellen oder Reparieren von derlei Daten verantwortlich fühle.

[OrNEC]

Ich hab dafür SQLite verwendet. Braucht nirgendwo eine Installation oder irgendwelche Komponenten. Wie du damit arbeitest steht hier -> http://www.delphi-treff.de/downloads/e-book/

Diese DB erlaubt aber keine mehrere Zugriffe. Also Server-Client Lösung geht damit kaum oder sehr schwer.