Welche Datenbank.

[holgerbremen]

Ich habe ein kleineres Projekt, wo ich diverse Daten speichern muss, ich gehe mal von 10-15 Tabellen aus. Max. Einträge pro Tabelle 50000 Datensätze (eine Tabelle), die restlichen Tabellen haben unter 1000 Einträge.
Das Problem ist, das auf den Zielrechnern keine Installation erlaubt ist und auch nicht erwünscht ist. Wie könnte man die Daten auf den Rechnern speichern. Aus dem Bauch fällt mir XML ein.
Was für Komponenten (auch Fremdanbieter) könnte man nehmen? Am liebsten wären mir Abfragen über SQL. Geht das auch mit XML?
Für kleinere oder größere Denkanstöße wäre ich dankbar.

Gruß

[Bernhard Geyer]

Jeder "popelige" Desktopdatenbank die es für Delphi gibt kommt ohne Installation aus.

Namen wären:

Absolute Database
TurboDB
ADS Local Server
...

[Morphie]

Soll es Multi-User fähig sein? wenn nicht, würde ich zu einer Embedded-Datenbank raten, wie z.B. Firebird Embedded.
Dann brauchst du auch keine Installation, sondern kannst dein Programm quasi als ZIP-Datei verteilen. Es muss auch kein großer Server im Hintergrund laufen. Nachteil ist eben, dass "normalerweise" nur ein Benutzer auf die Datenbank zugreifen kann.

Also keine Client/Server-Netzwerk-Lösung

[Angel4585]

Müssen mehrere Programme(*.exe) auf die Daten zugreifen oder nur eins?
Bei nur einem würde sich evtl. die Embedded Variante von Firbird empfehlen.
Da hast ne DLL und die Datenbank wird komplett in einer Datei untergebracht.
Installiert werden muss AFAIK nix zusätzlich.

Edit: Roter Kasten ist noch in den Weihnachtsferien??

[Bernhard Geyer]

Zitat:

Zitat von Morphie (Beitrag 1198489)

Soll es Multi-User fähig sein? wenn nicht, würde ich zu einer Embedded-Datenbank raten,

Viele Embedded-Datenbanken können auch Multi-User.

Zitat:

Zitat von Morphie (Beitrag 1198489)

... wie z.B. Firebird Embedded.

AFAIK hat man vor kurzen was in FB eingebaut das dies das mittlerweile auch kann.

[Angel4585]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1198491)

Zitat:

Zitat von Morphie (Beitrag 1198489)

Soll es Multi-User fähig sein? wenn nicht, würde ich zu einer Embedded-Datenbank raten,

Viele Embedded-Datenbanken können auch Multi-User.

Zitat:

Zitat von Morphie (Beitrag 1198489)

... wie z.B. Firebird Embedded.

AFAIK hat man vor kurzen was in FB eingebaut das dies das mittlerweile auch kann.

Hat man, dann geht aber auch nur Multi-User auf einem Rechner problemlos, aber mehrere Rechner im Netzwerk kann man vergessen.

[p80286]

Zitat:

Zitat von holgerbremen (Beitrag 1198487)

Das Problem ist, das auf den Zielrechnern keine Installation erlaubt ist und auch nicht erwünscht ist.

Was bedeutet das denn konkret?
Soll die Anwendung auf einem Netzlaufwerk liegen, oder hat jeder Anwender einen USB-Stik mit der Anwendung oder .....

Gruß
K-H

[holgerbremen]

Zitat:

Soll es Multi-User fähig sein?

So wie es aussieht nicht.

Das Programm und den Daten werden auf einem Server auf einem freigegebenen Verzeichnis liegen. Die User sollen dann mit dem Programm arbeiten, aber nicht parallel. Eventuel müsste ein Hinweis erscheinen, dass die Datenbank gerade bearbeitet wird. Aber das Problem kann man wohl anders lösen.

Welche Möglichkeiten hätte ich den, wenn mehrere User parallel arbeiten. Schlimmstenfalls würde der letzter User der speichert, gewinnen.

[Bernhard Geyer]

Zitat:

Zitat von holgerbremen (Beitrag 1198497)

Zitat:

Soll es Multi-User fähig sein?

So wie es aussieht nicht.

Lass dir das schriftlich geben!

Zitat:

Zitat von holgerbremen (Beitrag 1198497)

Schlimmstenfalls würde der letzter User der speichert, gewinnen.

Wenn das DBMS keine Multi-User unterstützt dann kannst du die Daten nicht mal lesen.

[holgerbremen]

Zitat:

Lass dir das schriftlich geben!

Falls es so ist, wird es im Pflichtenheft stehen.

Zitat:

Wenn das DBMS keine Multi-User unterstützt dann kannst du die Daten nicht mal lesen.

Na super, für den Fall wäre das Problem ja gelöst.

[Morphie]

Soweit ich weiß, dürfen Firebird Datenbanken nicht auf Netzlaufwerken / UNC-Pfaden liegen. Das fällt also dann schon mal raus.

Und bevor du auf dumme Ideen kommst: Access als Desktop-DB fällt immer raus ;-)

[holgerbremen]

So, laut Kundenaussage "könnte" die Datenbank Multiuserfähig sein. Soll heißen, nicht zwingend, könnte aber die Multiuserfähigkeit könnte drohen.
Was nun? Welche Datenbank bzw. welches System kommt noch in Frage?

Zitat:

Und bevor du auf dumme Ideen kommst: Access als Desktop-DB fällt immer raus

Hmmm, der Kunde hatte bisher eine Access-Anwendung, die auch auf einem Serverlaufwerk lag.

[Morphie]

Zitat:

Zitat von holgerbremen (Beitrag 1198504)

Hmmm, der Kunde hatte bisher eine Access-Anwendung, die auch auf einem Serverlaufwerk lag.

Ja, das war mal irgendwann gängige Praxis... Aus eigener Erfahrung kann ich dir aber sagen, dass du damit nicht glücklich wirst.
Wir haben das bei einem Produkt bei uns auch mal so gemacht und müssen seitdem täglich diverse Datenbankdateien beim Kunden reparieren. :-( und wenn man Google fragt, sind wir da kein Einzelfall

[rweinzierl]

Hallo


Ich würde die embeded Firebird Datenbank nehmen ==> Braucht man wirklich Mulituser dann einfach irgendwo einen Server (Firebird ist ja Kostenlos) installieren .

Alles was man braucht ist irgend ein Rechner der immer läuft

mfg

Reinhold

[Bernhard Geyer]

Zitat:

Zitat von holgerbremen (Beitrag 1198504)

So, laut Kundenaussage "könnte" die Datenbank Multiuserfähig sein. Soll heißen, nicht zwingend, könnte aber die Multiuserfähigkeit könnte drohen.

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

Zitat:

Zitat von holgerbremen (Beitrag 1198504)

Was nun? Welche Datenbank bzw. welches System kommt noch in Frage?

Wie ob: Absolute Database, ADS Local Server, ...

Zitat:

Hmmm, der Kunde hatte bisher eine Access-Anwendung, die auch auf einem Serverlaufwerk lag.

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 :-)

[stahli]

DB sind nicht so mein Thema.

Wenn die DB im Netzwerk liegen soll kommst Du m.E. ohne irgendeine Installation nicht hin. Schon gar nicht bei MultiUser-Zugriffen.

Die Datenbankdatei ist bei Firebird und Firebird embedded identisch.
Du kannst also ein Projekt für den lokalen Einsatz mit Firebird embedded bauen und das Ganze später dann doch noch in´s Netzwerk verlagern.

Wenn keine gemeinsamen Zugriffe möglich sein sollen könnte man ggf. die DB-Datei aus dem Netzwerk auf den lokalen Rechner kopieren, dort öffnen und danach ggf. wieder zurück kopieren. Aber elegant ist das sicher nicht.

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.

[p80286]

Alles in allem eine etwas seltsame Beschreibung.
Es kommt mir so vor, als ob Dein Auftraggeber des öfteren mal das Titelblatt einer Computerzeitung mit C (und p am Ende) gelesen hat.

a) hör auf Bernhard, laß es Dir schriftlich geben, sonst gibt es hinterher Streit über eine "klitzekleine" Änderung, die Dich 5 Jahre Deines Lebens kostet.

b) Schau Dir mal Firebird an, da hast Du beide Optionen (Server und embedded) und die Ausgaben sind minimal.

Gruß
K-H

[RWarnecke]

Zitat:

Zitat von stahli (Beitrag 1198508)

Wenn die DB im Netzwerk liegen soll kommst Du m.E. ohne irgendeine Installation nicht hin. Schon gar nicht bei MultiUser-Zugriffen.

Stimmt so nicht zu 100%. Bei Firebird brauchst Du auch für einen Serverzugriff keine Installation. Auch hier reicht es, wenn man die gleichen DLL's ins Programmverzeichnis kopiert. Bei einem Serverzurgiff musst Du dazu nur lediglich die fbembed.dll in fbclient.dll umbenennen. Bei den anderen DBMS-Systemen kommt es auf die Komponente an, die Du im Delphi-Programm verwendest. Verwendest Du zum Beispiel UniDAC von DevArt, dann brauchst Du auch keinen Client für einen MySQL-Zugriff installieren.

[Bernhard Geyer]

Zitat:

Zitat von stahli (Beitrag 1198508)

Wenn die DB im Netzwerk liegen soll kommst Du m.E. ohne irgendeine Installation nicht hin. Schon gar nicht bei MultiUser-Zugriffen.

Komisch nur das wir das seit über 10 Jahren im Angebot haben. Ist zwar nicht Solid-Rock wie bei einer richtigen DB, aber halbwegs stabil bekommen das TurboDB und Co. schon hin. Kein Vergleich mit instabiler BDE und Paradox/dBase.

Zitat:

Zitat von stahli (Beitrag 1198508)

Was spricht im Firmenumfeld gegen eine vernüftige Installion eines DB-Servers?

Und wer Betreut das? Und wenn die IT-Abteilung sagt: "Is nicht" bzw. "Nur unter unserer Kontrolle. Macht x€/Jahr Betreuungskosten"

[BUG]

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.

Eine Datenbank sollte die stabilste Komponente im System sein, denn Nutzer-Daten sind das einzige Unersätzliche in einer Anwendung.
Wenn es nur irgendwie geht, setze eine richtige Datenbank ein.

[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.

[BUG]

Zitat:

Zitat von OrNEC (Beitrag 1198617)

Ich hab dafür SQLite verwendet.

So gern ich SQLite mag, auf Netzwerklaufwerten ist das nicht zu empfehlen:

Zitat:

Zitat von SQLite FAQ

But use caution: this locking mechanism might not work correctly if the database file is kept on an NFS filesystem. This is because fcntl() file locking is broken on many NFS implementations. You should avoid putting SQLite database files on NFS if multiple processes might try to access the file at the same time.

[stahli]

Zitat:

Zitat von QuickAndDirty (Beitrag 1198599)

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.

Man könnte Excel empfehlen, da funktioniert das perfekt ;-)

[Klaus01]

Zitat:

Zitat von BUG (Beitrag 1198622)

Zitat:

Zitat von OrNEC (Beitrag 1198617)

Ich hab dafür SQLite verwendet.

So gern ich SQLite mag, auf Netzwerklaufwerten ist das nicht zu empfehlen:

Zitat:

Zitat von SQLite FAQ

But use caution: this locking mechanism might not work correctly if the database file is kept on an NFS filesystem. This is because fcntl() file locking is broken on many NFS implementations. You should avoid putting SQLite database files on NFS if multiple processes might try to access the file at the same time.

.. wenn man Zeit hat könnte man ja einen Service davor setzen.
Dieser Verbindet sich als einziger mit der Datenbank.
Die Clients verbinden sich mit dem Service und der Service führt die Clientrequests aus.

Grüße
Klaus

[holgerbremen]

So, ich den Ball zum Kunden zurückgespielt. Eine Anfrage an die IT des Kunden läuft.
Es kommt wohl nur ein vernünftiges DBMS in Frage. Ich weiss, dass der Kunde MS-SQL-Server im Einsatz hat. Sollen sie mir dort eine Instanz zur Verfügung stellen, damit ich dort meine DB aufbauen kann.
Ich habe keine Lust mir mit halbseidenen Lösungen die Karten zu legen und mir hinterher das Gemecker anhören zu müssen. Wollen wir mal schauen, wie der Kunde sich entscheidet.

[jobo]

Zitat:

Zitat von stahli (Beitrag 1198623)

Man könnte Excel empfehlen, da funktioniert das perfekt ;-)

:thumb:
OT:
Wenn schon Excel, dann bitte per Email weiterschicken. Dann hat man sogar historisierte Backups. ;)

[Sir Rufo]

Zitat:

Zitat von holgerbremen (Beitrag 1198625)

Ich weiss, dass der Kunde MS-SQL-Server im Einsatz hat. Sollen sie mir dort eine Instanz zur Verfügung stellen, damit ich dort meine DB aufbauen kann.

Das wurde hier ja auch schon erwähnt. Es ist immer besser auf ein vorhandenes DB-System zu setzen, denn dafür sollte es schon einen vernünftigen Support geben.

Ob es auf der gleichen Hardware/Instanz läuft ist dabei unerheblich und kann manchmal auch nicht gewünscht sein (Performance, Trennung, Lizenz).

[p80286]

Zitat:

Zitat von jobo (Beitrag 1198627)

Zitat:

Zitat von stahli (Beitrag 1198623)

Man könnte Excel empfehlen, da funktioniert das perfekt ;-)

:thumb:
OT:
Wenn schon Excel, dann bitte per Email weiterschicken. Dann hat man sogar historisierte Backups. ;)

:shock:Bist DU der Typ, der das meinen Kollegen empfohlen hat? (LN+Excel):shock:

Gruß
K-H

[Sir Rufo]

Zitat:

Zitat von Klaus01 (Beitrag 1198624)

Zitat:

Zitat von BUG (Beitrag 1198622)

Zitat:

Zitat von OrNEC (Beitrag 1198617)

Ich hab dafür SQLite verwendet.

So gern ich SQLite mag, auf Netzwerklaufwerten ist das nicht zu empfehlen:

Zitat:

Zitat von SQLite FAQ

But use caution: this locking mechanism might not work correctly if the database file is kept on an NFS filesystem. This is because fcntl() file locking is broken on many NFS implementations. You should avoid putting SQLite database files on NFS if multiple processes might try to access the file at the same time.

.. wenn man Zeit hat könnte man ja einen Service davor setzen.
Dieser Verbindet sich als einziger mit der Datenbank.
Die Clients verbinden sich mit dem Service und der Service führt die Clientrequests aus.

Grüße
Klaus

also sowas wie mORMot ;)