Welche Datenbank - zum 1256sten mal

[Garby]

Hallihallo,

Ich bin auf der Suche nach einem deuen Datenbanksystem.
Wie sich herausgestellt hat ist die Sache schwerer als ich dachte.
Ich habe noch keine DB gefunden, die alle meine Anforderungen entspricht:
Diese wären:

• Unicode
• Embedded Version
• einfaches Upsizing auf Client/Server
• Zugriff über .Net
• Server lauffähig unter Windows + Linux (Nicht zwingend)

Der Knackpunkt ist, dass die meisten unserer Kunden keinen zusätzlichen Server installieren/betreuen wollen/können/dürfen.
Deshalb ist es nötig, dass in der Embedded Version ca. 10 - 15 User gleichzeitig auf die DB zugreifen können.

Folgendes habe ich bisher rausgefunden (bitte berichtigt mich bitte wenn etwas falsch sein sollte).

• Firebird: Embedded Version nur für 1 User gleichzeitig.
• ADS: kein Unicode, Embedded Server nur 5 User gleichzeitig.
• NexusDB: Unicode???, Embedded Server mehrere User??? (ehrlich gesagt bin ich bei diesem System noch nicht ganz durchgestiegen ;) )
• AbsoluteDB: kein C/S, kein .NET
• SQLite: kein C/S, kein .NET???, Unicode???

Weiss Jemand eine Alternative?
Der Preis spielt erstmal kein Rolle.

Danke

[mschaefer]

Moin: Kurz zu Firebird:

Es ist kein Problem die Server-Version auf einem Anwenderrechner laufen zu lassen. Die Geschwindigkeit ist bei heutigen Rechnern kein wirkliches Argument. Damit hast Du den Mehrbenutzerzugriff. Normalerweise nimmt man den Rechner, der im Nichtkundenbereich dauernd läuft.

Grüße // Martin

[Bernhard Geyer]

MySQL (Kann ab V4.1 Unicode als UCS2 oder UTF8)
MS-SQL (MSDE bzw. SQLExpress als "kleine" Version)


Aber jeder DB kann man Unicode "teilweise" beibringen indem man alle Daten UTF8-Codiert speichert.

[Garby]

Zitat:

Zitat von Bernhard Geyer

MySQL (Kann ab V4.1 Unicode als UCS2 oder UTF8)

Können mehrere MySQL Embedded auf eine Datenbasis zugreifen?

Zitat:

Zitat von Bernhard Geyer

MS-SQL (MSDE bzw. SQLExpress als "kleine" Version)

Braucht MSDE keine Installation?
Wenn nicht, können mehrere MSDE....?

Zitat:

Zitat von Bernhard Geyer

Aber jeder DB kann man Unicode "teilweise" beibringen indem man alle Daten UTF8-Codiert speichert.

Wie meinst du das? .Net Strings sind doch Unicode(UTF16) codiert, oder nicht?
Steh ich vielleicht aufm Schlauch? ;)

[Hansa]

Zitat:

Zitat von Garby

Der Knackpunkt ist, dass die meisten unserer Kunden keinen zusätzlichen Server installieren/betreuen wollen/können/dürfen.

Was verstehst Du unter einem Server ? Vor allem einem "zusätzlichen" ? Etwa einen zusätzlichen Rechner, den man dann bräuchte ? Den braucht man nicht !

[Garby]

Zitat:

Zitat von Hansa

Was verstehst Du unter einem Server ? Vor allem einem "zusätzlichen" ? Etwa einen zusätzlichen Rechner, den man dann bräuchte ? Den braucht man nicht !

Ein Server ist für mich ein Serverprogramm, das man installieren und administrierem muss.
Hauptsächlich bei Ämtern, und auch bei manchen Firmen wo die EDV "outgesourct" ist stellt das ein Problem dar.

Angenommen in einer Firma werden nur Notebooks verwendet, die nie an ihrem Arbeitsplatz bleiben.
In diesem Fall würde ich auch einen eigenen Rechner brauchen.

[Der_Unwissende]

Hi,
ich hab hier mal einen weiteren Vorschlag, allerdings bin ich mir bei der direkten .net Unterstützung nicht ganz sicher. Aber solltest eigentlich über ODBC-Bridges an so ziemlich jede DB rankommen (womit .net Java ein Stückchen näher käme).
Schau einfach mal bei H2 Databases vorbei (ich finde klingt viel versprechend).

Gruß Der Unwissende

[alzaimar]

Manchmal muss man Kunden aber zu ihrem Glück zwingen. Du kannst ja nicht in ein Autohaus gehen und sagen:"Ich will ein Auto, aber auf Tanken hab ich kein Bock". Geht nun mal nicht.
oder auch "Ich will keine Wartungsintervalle einhalten"... "Klar, aber wundern Sie sich nicht, wenn das Auto nicht lange hält"

So ist es auch hier: Ein normaler Anwender-PC, auf dem sich die DB befindet, mag ja auf den ersten Blick kostengünstig und bequem sein, aber lass doch einfach mal eins der user-GAUe passieren:
-Virus
-Festplatte im Eimer
-Aus Versehen Neustart
etc.

Ich würde zumindest *einen* PC etwas robuster ausstatten (also nicht die billig-HD nehmen, sondern vielleicht SCSI), das Software-Raid von Windows aktivieren (oder gleich ne kleine Raid-Karte) und den ohne Grafikschnickschnack in die Ecke stellen. Das muss nun wirklich kein Server sein, nur stabil muss er nun mal sein. Darauf einen wartungsarmen MSSQL (mein Favorit, aber FB und PostgreSQL sind wohl gleichwertig) draufpacken und fertig. Und wenn die DB mal hängt (was immer mal vorkommen kann), dann wird der Resetknopf gedrückt und gut ist: Bei richtigen DB (also *nicht* mysql) ist es nämlich so, das die DB garantiert nicht zerballert ist, bloss weil man den Resetknopf gedrückt hat. Beim Neustart wird die DB ganz brav geladen und der Zustand vor dem Rest wieder hergestellt. Dann noch ein paar Maintenance-Jobs per Timer (checkpoint setzen, backup etc.) und schon haben die ihre Ruhe. Du musst dann nur gelegentlich per Admintool nachschauen, ob alles ok ist.

Soweit ich das weiss (bitte korrigieren) ist ein sichere Transaktionskapselung mit 'Embedded Servern' doch gar nicht möglich, weil eben viele Server auf eine Datei zugreifen. Das geht nie 100% gut.

Du *musst* irgendwo eine zentrale Serverinstanz installieren, die sich auf die DB setzt und sie 100% wasserdicht abschottet und eine zentrale Transaktionskapselung vornimmt. Imho geht das nicht mit clientseitigen DBs (siehe Access).

Ich sage meinen Kunden: Kaufen Sie sich einen zusätzlichen PC, zur Not packen wir den ins Budget, wenn der Financial Controller mauert (was die gerne tun). Der Wert (max 1000 Euronen) entspricht 1-2 Tagessätzen, und die verbringt man allemal damit, eine DB-Havarie aus o.g. Gründen wieder zu korrigieren.

[Surrounder]

hast Du mal die NexusDB angeschaut?

http://www.nexusdb.com/showpage.asp?Id=125



Edit: Zum Thema Server, ich arbeite mit der NexusDB und man hat 2 möglichkeiten, entweder einen Server laufen lassen ( was du ja nicht möchtest ) oder eben den Pfad angeben wo die DB liegt. Das sollte meines Wissens nach auch mit der Trial gehen.

[Garby]

Zitat:

Zitat von alzaimar

Manchmal muss man Kunden aber zu ihrem Glück zwingen. Du kannst ja nicht in ein Autohaus gehen und sagen:"Ich will ein Auto, aber auf Tanken hab ich kein Bock". Geht nun mal nicht.
oder auch "Ich will keine Wartungsintervalle einhalten"... "Klar, aber wundern Sie sich nicht, wenn das Auto nicht lange hält"

Deine Ausführungen sind alle Verständlich und Logisch.
Das Problem ist, dass unsere bestehende Software auf Foxpro aufsetzt, wo die DB-Dateien eben auf einem Fileserver liegen.
Lt. Erfahrungen unseres Helpdesks würden die Meisten unserer Kunden kein Update mehr kaufen wollen/dürfen, wenn ein eigener Server benötigt wird. (hier ist wohl der Kunde König)

Zitat:

Zitat von Surrounder

hast Du mal die NexusDN angeschaut?

Zitat:

Zitat von Garby

• NexusDB: Unicode???, Embedded Server mehrere User??? (ehrlich gesagt bin ich bei diesem System noch nicht ganz durchgestiegen ;) )

[Bernhard Geyer]

Zitat:

Zitat von Garby

Können mehrere MySQL Embedded auf eine Datenbasis zugreifen?

Bin ich überfragt. Setze es nicht ein.

Zitat:

Zitat von Garby

Braucht MSDE keine Installation?

Braucht eine

Zitat:

Zitat von Garby

Wie meinst du das? .Net Strings sind doch Unicode(UTF16) codiert, oder nicht?
Steh ich vielleicht aufm Schlauch? ;)

Deine .NET-String kann Unicode. Aber kann es auch deine Datenbank speichern ...
Falle es direkt nicht unterstütz kann man ja es vor dem Schreiben in eine Verträgliche (UTF8) Form wandeln.

Zitat:

Zitat von Der_Unwissende

Aber solltest eigentlich über ODBC-Bridges an so ziemlich jede DB rankommen (womit .net Java ein Stückchen näher käme).

Blos nicht mehr mit ODBC anfangen. Du mußt eh für jede DB anpassungen vornehmen (SQL-Dialekte) und bist mit ODBC ab Win64 aufgeschmissen. Eher sollte man wenn man mehrere DB's unterstützt möglichst direkt darauf zugreifen und die Unterschiede z.B. mittels Bridge-Pattern kapseln. Dies unterstützt .NET mit ASP.NET ganz gut da nicht wie unter ADO eine Vermischung zwischen Datenhaltung auf dem Client zu Zugriff in einer Komponente erfolgt.

[Surrounder]

Zitat:

Zitat von Surrounder

hast Du mal die NexusDN angeschaut?

Zitat:

Zitat von Garby

• NexusDB: Unicode???, Embedded Server mehrere User??? (ehrlich gesagt bin ich bei diesem System noch nicht ganz durchgestiegen ;) )

Uups :duck:

also ich nutze NexusDB V2, ist eigentlich ähnlich wie der FlashFiler von TurboPower. Hatte bisher aber immer nur C/S und kann dir deshalb nicht sagen ob Userverwaltung geht wenn kein Server läuft.

[Hansa]

Zitat:

Zitat von Garby

Das Problem ist, dass unsere bestehende Software auf Foxpro aufsetzt, wo die DB-Dateien eben auf einem Fileserver liegen.
Lt. Erfahrungen unseres Helpdesks würden die Meisten unserer Kunden kein Update mehr kaufen wollen/dürfen, wenn ein eigener Server benötigt wird. (hier ist wohl der Kunde König)...

Das ist eine subjektive Meinung von jemand der vielleicht keinen Plan hat. 8) Um was dreht es sich denn nun : um einen Fileserver=eigener Rechner oder um ein Programm, das automatisch im Hintergrund läuft (auf einem Netzrechner) ? Ist letzteres der Fall, dann verstehe ich die Aussage nicht. Alleine wegen eines Netzwerkes muß einiges installiert werden : Netzwerkkarten-Treiber, Protokolle usw. Und zwar auf jedem angeschlossenen Rechner ! Was macht es da schon aus, daß auf einem der Rechner die DB liegt und z.B. ein Firebird Prozeß zusätzlich läuft ?

Es geht um 10-15 Rechner ? Dann käme für mich sowieso (egal wie) ein Fileserver zum Einsatz. Denn ich kann doch nicht wegen eines Stolperers oder eines Klammeraffen-Testers :mrgreen: am "Fileserver" 14 Leute zum Nichtstun zwingen inkl. Datenverlust usw. Gleichzeitig ist es aber auch nicht nötig bei 2 Rechnern noch einen dritten als Filserver zu "verschwenden".

Ah, roter Kasten : ja, fast vergessen : FlashFiler. Da ist wirklich alles in der EXE drin. Das ist eine gute Idee ! Aber leider nur fast. :lol: Es wird nicht mehr offiziell weiterentwickelt und bei SourceForge tut sich auch nicht sehr viel.

[Surrounder]

Zitat:

Zitat von Hansa

Ah, roter Kasten : ja, fast vergessen : FlashFiler. Da ist wirklich alles in der EXE drin. Das ist eine gute Idee ! Aber leider nur fast. :lol: Es wird nicht mehr offiziell weiterentwickelt und bei SourceForge tut sich auch nicht sehr viel.

Wie schon erwähnt, NexusDB ist eigentlich der Nachfolger von FlashFiler. Meines Wissens nach haben die den FalshFiler für TurboPower mit entwickelt. Wenn man sich die alter Version der NexusDB anschaut z.B. den Explorer anschaut dann stellt man sehr schnell viele ähnlichkeiten fest. NexusDB kann auch Flashfiler DB´s convertiern und dann lesen.

[Garby]

Zitat:

Zitat von Hansa

Das ist eine subjektive Meinung von jemand der vielleicht keinen Plan hat. 8) Um was dreht es sich denn nun : um einen Fileserver=eigener Rechner oder um ein Programm, das automatisch im Hintergrund läuft (auf einem Netzrechner) ? Ist letzteres der Fall, dann verstehe ich die Aussage nicht. Alleine wegen eines Netzwerkes muß einiges installiert werden : Netzwerkkarten-Treiber, Protokolle usw. Und zwar auf jedem angeschlossenen Rechner ! Was macht es da schon aus, daß auf einem der Rechner die DB liegt und z.B. ein Firebird Prozeß zusätzlich läuft ?

Es geht mir hier nicht ums warum.
Ich kann an den Gegebenheiten leider nichts ändern (probiert hab ichs INTENSIV)

Zitat:

Zitat von Hansa

Es geht um 10-15 Rechner ? Dann käme für mich sowieso (egal wie) ein Fileserver zum Einsatz. Denn ich kann doch nicht wegen eines Stolperers oder eines Klammeraffen-Testers :mrgreen: am "Fileserver" 14 Leute zum Nichtstun zwingen inkl. Datenverlust usw. Gleichzeitig ist es aber auch nicht nötig bei 2 Rechnern noch einen dritten als Filserver zu "verschwenden".

Meinst du vielleicht, dass nur ein DB Server für dich in Frage kommt?
Sonst komm ich da nicht mit.

[mschaefer]

Moin zusammen,

Dann wird ein Rechner, der halt nicht vom aktuen Superuser verwendet wird so eingerichtet, das Windows die Hintergrundprozesse und den Cache bevorzugt hehandelt. Die aktuellen Rechner sind deutlich schnell genug um damit verzögerungsfrei zu arbeiten.

Das ist einfach kein praktisches Problem. Jedenfalls nicht unter 20 Rechnern die daran hängen.

Letzlich haben daher die Kunden mit ihrer Haltung da banal recht. Und ein Firebird Server-Setup bekommt man dann auch in seine eigene Setuproutine rein. Damit ist es für den Kunden dann Wartungsfrei bis auf die regelmäßgen Backups, aber da kamm man wahrscheinlich auch noch was machen.


Grüße // Martin

[Garby]

Ich schau mir inzwischen TurboDB an.
Ist zwar kein C/S System, aber hat schon Jemand Erfahrungen mit der Version 5?

[alzaimar]

Zitat:

Zitat von Garby

Zitat:

Zitat von alzaimar

Manchmal muss man Kunden aber zu ihrem Glück zwingen. Du kannst ja nicht in ein Autohaus gehen und sagen:"Ich will ein Auto, aber auf Tanken hab ich kein Bock". Geht nun mal nicht.
oder auch "Ich will keine Wartungsintervalle einhalten"... "Klar, aber wundern Sie sich nicht, wenn das Auto nicht lange hält"

Deine Ausführungen sind alle Verständlich und Logisch.
Das Problem ist, dass unsere bestehende Software auf Foxpro aufsetzt, wo die DB-Dateien eben auf einem Fileserver liegen.
Lt. Erfahrungen unseres Helpdesks würden die Meisten unserer Kunden kein Update mehr kaufen wollen/dürfen, wenn ein eigener Server benötigt wird. (hier ist wohl der Kunde König)

Worum geht es denn dann? Wenn Eure Kunden FoxPro/DBase/Access (egal, eine Desktop-DB) haben, dann wissen sie ja, das eben diese DB manchmal abschmiert. Um das zu verhindern, kommt man nicht umhin, ein sicheres System (=DB-Server) einzusetzen. Es geht nicht anders. Du kannst eine MSDE lokal installieren (Ganz ohne Zutun des Anwenders) und hast schon eine richtig ordendliche DB. Andere aus dem Netz können sich problemlos damit verbinden (muss man allerdings bei der Installation angeben, das Netzwerkfunktionalität gewünscht ist. Geht, wie gesagt, über ein Skript völlig unsichtbar). Übrigens kann man mehrere MSDE nebeneinander installieren, die bekommen dan einen eigenen 'Instanznamen'.

Wenn dann irgendwann Sicherheit vorrangig wird, verschiebt man die MSDE auf einen eigenen Rechner, biegt die Zugriffe der Clients (IP-Adresse) einfach um und fertig. Wenn dann mal der grosse Bruder ran soll, besorgt man sich die Lizenz und ist wieder im Grünen. Die MSDE ist 'berühmt' wegen ihrer Skalierbarkeit.

Nennt sich "Salamitaktik". :mrgreen: Denn im Endeffekt kriegen die Kunden dann das, was sie laut 'Helpdesk' derzeit ablehnen.

Aber eins muss man den Kunden eben vermitteln: Wer den Nachfolger einer Pferdekutsche will, der muss eben Benzin tanken statt Hafer zu füttern. Tja.

[Elvis]

Desktop DBMSse im Mehrbenutzerbetrieb? :shock: Autsch!

Für .Net sehe ich da eigentlich nur
SQL Server 2005 Express (alzaimar's MSDE ;) und Oracle Express (bis auf weiteres aber nur Beta!)

Alles andere würde dir keine wünschenswerte Option auf einen größeren Server ermöglichen.
Mit viel Auge zudrücken gibt es noch Firebird.

Eins sollte dir nach all den Kommentaren hier klar geworden sein: Mehrere Prozesse auf eine DB Datei zugreifen zu lassen ist alles andere witzig. Stelle es einfach als no-go dar.
Für solche Friemeleien würde ich nie meinen Kopf hinhalten wollen.

[Hansa]

Zitat:

Zitat von Elvis

Mit viel Auge zudrücken gibt es noch Firebird...Für solche Friemeleien würde ich nie meinen Kopf hinhalten wollen.

Dann sage mal noch, wo Dein Auge in der Richtung drückt. Mein Kopf ist allerdings für diese Fummeleien auch zu Schade. :mrgreen:

[mschaefer]

In Firebird tut sich viel. Die 2.0 Version ist deutlich verbessrt, was Hochlast und maximale Tabellengrößen angeht. Auch vom Sprachumfang tut sich entscheidentes z.B. Inserts mit Generatorwertrückgabe. Da kann man schon getrost die Augen auf machen.
Das Grundproblem ist derzeit sicher noch, dass man bei FB in Jahresabständen das gesamte Serversystem tauschen muß, aber da ist eine OpenSource-Entwicklung natürlich etwas ungesteuerter.

Grüße // Martin

[Alfons_G]

VistaDB kann man sich auch mal ansehen. Das System bietet einen DB-Server an sowie eine eingebettete Datenbank. Die Datenbank ist sowohl für NET, als auch für WIN32 geeignet. Die Doku für Delphi ist etwas besch(eiden), die Leistung jedoch nicht schlecht.

:coder:

[Jelly]

@Garby: Es hilft kein Jammern und Stöhnen, sorry. Aber wenn 10-15 Leute auf eine Datenbank zugreifen wollen, klappt das NUR mit einem Datenbank Server. Vergiss mal ganz schnell den Quatsch mit Embedded MySQL Server, der ist nämlich nicht Multiuserfähig. Punkt.

Installier beim Chef den Firebird Server, oder besser noch den SQL Server der aber wohl wieder wegen Lizenzgebühren wegfällt, und sag ihm er darf ja nie seinen Rechner ausschalten oder sonstige Dummheiten mit anstellen, da sonst 15 Leute im Betrieb nicht mehr arbeiten können. Vielleicht ändert er da ja seine Meinung.

Ich versteh dein Problem ganz wohl. Du hast Vorgaben, an die Du dich zu halten hast. Nur leider ist es nun mal in der Datenbankwelt so, dass in Multiuser Systemen ein Datenbankserver her muss. Alles Andere ist grob fahrlässig (Einsatz von Access im Netz o.ä.)

[mschaefer]

Spätmoin,

Ist den bei FoxPro wirklich ein Fileserver heute noch notwendig? Selbst das bekommt eine flotte Arbeitsstation locker hin. Dann bekommt die halt etwas mehr Ram. Man darf nicht vergessen, das die Rechner aus der FoxPro-Hochzeit nur 20%-10% der heutigen Leistung hatten.

Grüße // Martin

[alzaimar]

Zitat:

Zitat von Jelly

Installier ... oder besser noch den SQL Server der aber wohl wieder wegen Lizenzgebühren wegfällt...

:gruebel: Seit wann? MSSQL Express Edition bzw. MSDE ist umsonst. Keine Lizenzen. Die MSDE ist nur beschränkt (Connection pipes, DB-Größe), SQL 2005 Express ist dagegen voll funktionsfähig. Oder was meinst Du mit Lizenzgebühren?

[Jelly]

Zitat:

Zitat von alzaimar

Seit wann? MSSQL Express Edition bzw. MSDE ist umsonst. Keine Lizenzen. Die MSDE ist nur beschränkt (Connection pipes, DB-Größe), SQL 2005 Express ist dagegen voll funktionsfähig. Oder was meinst Du mit Lizenzgebühren?

Ich leb noch in der SQL 2000 Welt. Da war die MSDE funktional auf 5 (glaube ich) User beschränkt. Gings darüber hinaus, wurde alles grottenlahm. SQL 2005 Express ist da anders, das stimmt.

Bei einem vollen SQL Server fallen pro Server und pro Client Lizenzen an.

[Garby]

Hallo,

eure Argumente haben alle etwas für sich.
Sicher möchte ich auch am liebsten nur ein Client-Server System anbieten.
Das Hauptaugenmerk bei dieser Anwendung liegt zum Einen bei der einfachen Skalierbarkeit und zum Anderen bei der Möglichkeit unser bestehendes Programm (Foxpro) einfach, und ohne großen Personalaufwand unsererseits, einem Update zu unterziehen.

@Jelly: Deinem Vorschlag mit dem Einen Rechner, der immer gestartet bleiben muss kann ich aus 2 Gründen nichts abgewinnen:

• Wir wollen eine professionelle Software vertreiben. Lt. Umfrage bei unseren Kunden würde ein solches Vorgehen von den meisten als unprofessionell angesehen werden.
• Die Umstellung auf die neuen Technologien (.net, neue DBs) muss schrittweise erfolgen. Deshalb wird vorerst nur ein neues Modul entwickelt, welches im Rahmen eines Updates an die Kunden verteilt wird. Dieses Update würde dann bei ca. 1000 Kunden fast gleichzeitig benötigt werden. Das würde unsere Kapazitäten (Support, bzw. Hilfestellung vor Ort) bei weitem sprengen.

Diese Vorgehensweise würde ich bei 1-10 verschiedenen Kunden vielleicht einsetzen.

Noch was zu Fileserver DBs:
Mir wurde z.B. vom TurbeDB Support folgendes versichert:

Zitat:

Es gibt in TurboDB keine zerstörten Datenbank-Tabellen, weil wir ganz be-
wusst eine sehr simple Heap-Struktur benutzen, die fast ohne Verwaltungs-
information gelesen werden kann. Indexe gehen manchmal kaputt, was
bei einer Desktop-Datenbank nicht ganz vermeidbar ist. Allerdings lange nicht
so oft wie bei Paradox. Es gibt dafür auch Analyse und Reparaturfunktionen.

Zitat:

Das ist ein typisches Szenario für TurboDB. Je nach Einsatz sind allerdings
15 User schon ein Anzahl, bei der man prüfen sollte, ob die Performanz
mit einer Desktop-Datenbank zu erreichen ist. Wenn Sie allerdings mit
ADO.NET arbeiten, erwarte ich keine Schwierigkeiten.

Was sagt ihr dazu?

Klar werde ich diese Aussagen in diversen Stresstests prüfen.
Trotzdem tendiere ich im Moment dazu, den Datenbankzugriff offen zu gestalten.
d.h. vorerst bieten wir eine lokale DB (TurboDB bzw. VistaDB) und einen Server (evtl. Firebird) an.

Dies hat den weiteren Vorteil:
Einige unserer Kunden möchten die Daten auf ihrem hauseigenen DBMS liegen haben.
Es wäre mit dieser Architektur relativ einfach neue Datenbanksysteme zu unterstützen.

P.S. Mir ist klar was das für einen Aufwand mit sich bringt ;)

[Bernhard Geyer]

Zitat:

Zitat von Garby

Trotzdem tendiere ich im Moment dazu, den Datenbankzugriff offen zu gestalten.

Sehr löblich

Zitat:

Zitat von Garby

d.h. vorerst bieten wir eine lokale DB (TurboDB bzw. VistaDB) und einen Server (evtl. Firebird) an.

Was ist mit MS-SQL oder Oracle. Diese sind in Deutschland sehr gebräuchlich. Firebird ist als "hauseigenes" DBMS praktisch nicht anzutrefffen.

Zitat:

Zitat von Garby

Es wäre mit dieser Architektur relativ einfach neue Datenbanksysteme zu unterstützen.

Wie schon gesagt: Bridge-pattern und kapslung des DB-Abhänigen anteils in einer Unit.

[Garby]

Zitat:

Zitat von Bernhard Geyer

Sehr löblich

Danke ;)

Zitat:

Zitat von Bernhard Geyer

Was ist mit MS-SQL oder Oracle. Diese sind in Deutschland sehr gebräuchlich. Firebird ist als "hauseigenes" DBMS praktisch nicht anzutrefffen.

Das ist mir klar.
Ich dachte auch eher daran eine Komplettpaket (Hardware, Linux, Firebird) anzubieten. Andere Systeme zu unterstützen ist sozusagen ein "Zuckerl".

Zitat:

Zitat von Bernhard Geyer

Wie schon gesagt: Bridge-pattern und kapslung des DB-Abhänigen anteils in einer Unit.

Meinst du damit die Erstellung einer abstrakten Klasse, die als Basis für die verschiedenen DB Zugriffsklassen dient? :snowball:
So hab ichs nämlich vor ;)

[Bernhard Geyer]

Zitat:

Zitat von Garby

Das ist mir klar.
Ich dachte auch eher daran eine Komplettpaket (Hardware, Linux, Firebird) anzubieten. Andere Systeme zu unterstützen ist sozusagen ein "Zuckerl".

Aber damit wirst du nicht gerade auf Gegenliebe stoßen wenn Firmen schon viel Geld z.B. für eine Firmenlizenz ausgegeben haben mit allem Drum und Dran wie autmatisches Backup (mit HW) und Schulungen.

Zitat:

Zitat von Garby

Meinst du damit die Erstellung einer abstrakten Klasse, die als Basis für die verschiedenen DB Zugriffsklassen dient? :snowball:
So hab ichs nämlich vor ;)

Genau. Abstrahieren und Basisklasse.

[Elvis]

Zitat:

Zitat von Bernhard Geyer

Wie schon gesagt: Bridge-pattern und kapslung des DB-Abhänigen anteils in einer Unit.

Oder einfach ein DataAbstract Server. Dem ist es dann vollkommen Bohne, ob du auf eine lokale DB auf seiner Maschine zugreifst oder auf einen DB Server, solange ein DA-Treiber vorliegt.
Mit RO/DA bekommst du IMHO sogar eine Lizenz für embedded NexusDB dazu, die könntest du gleich darin laufen lassen. Nach außen sieht man nur den DA Service, nicht die DB. ;)
Dadurch müssen deine Clients nicht wissen welche DB dahintersteckt.

Ich bin selbst kein Pro was DA angeht, meine Projekte liefen leider schon an bevor ich davon hörte. :wall:
Aber für zukünftige Entwicklungen werden ich es wohl auch einsetzen. :)

Zitat:

Skalierbarkeit

Klassische C/S Architekturen sind per Definitiion schlecht skalierbar. Statuslose Appserver, wie DA oder .Net XML Services, lassen sich einfach hochskalieren indem man eine weitere Maschine dazustellt. Bei DBMSen wird Clustering schnell heikel, Mini DBs wie Firebird, Vista, SqlExpress,... unterstützen gar kein Clustering und sind somit auch nicht skalierbar.

[Garby]

Zitat:

Zitat von Bernhard Geyer

Aber damit wirst du nicht gerade auf Gegenliebe stoßen wenn Firmen schon viel Geld z.B. für eine Firmenlizenz ausgegeben haben mit allem Drum und Dran wie autmatisches Backup (mit HW) und Schulungen.

Ob ich gleich von Anfang an mehrere Systeme unterstützen will hänt davon ab, wieviel Aufwand es letztendlich darstellt.
Weil aber der Anteil unserer Kunden mit eigenem (und auch verwendbarem) DB Server in der Minderheit, sind werden wir eine solche Entwicklung eher bei Bedarf (und evtl. einer kleinen Unkostenbeteiligung) entwickeln.

@Elvis:
DataAbstract schau ich mir mal näher an, danke.

[mschaefer]

ZEOS !

[Bernhard Geyer]

Zitat:

Zitat von mschaefer

ZEOS !

Löst nicht alle Probleme. Vor allem nicht das Problem der unterschiedlichen SQL-Dialekte.

[Garby]

Gibts ZEOS auch für .NET/C# ?

[mschaefer]

@Bernhard: Ja tut es natürlich nicht, aber wenn man im Dialekt mit Firebird-Fyracle und Oracle als Orientierung hat, dann
ist damit schon ein interessantes Duo abgedeckt.

@Garby: Weiss es leider nicht. Zeos liegt im Quellcode vor, habe aber bisher keine NET-Erfahrung.

Grüße // Martin

[Elvis]

Zitat:

Zitat von Garby

Gibts ZEOS auch für .NET/C# ?

Ist mit .Net 2.0 schlichtweg unnötig geworden. Mit den Provider factories bekommt man die nötigen Zugriffsobjekte solange sich der Provider in die machine.config eingetragen hat. Aber auch ohne diesen Eintrag lassen sich alle Zugriffsklassen auf die ADO.Net interfaces, bzw. abstrakte Klassen ab 2.0, zurückführen.
Berhards Einwand gilt aber immernoch und ich kenne da als Lösung nur DA. (Gibt aber sicher noch andere)
nHibernate als ORPF kommt auch mit ein paar Dialekten DBs klar...

[dfried]

Zitat:

Zitat von Elvis

Zitat:

Zitat von Bernhard Geyer

Wie schon gesagt: Bridge-pattern und kapslung des DB-Abhänigen anteils in einer Unit.

Oder einfach ein DataAbstract Server.

Dem kann ich nur zustimmen, hab jetzt schon mehrere Projekte mit DataAbstract gemacht (auch mit unterschiedlichen Datenbanken) und bin sowohl von RemObjects als auch DataAbstract mehr als begeistert!

[Bernhard Geyer]

Zitat:

Zitat von Elvis

Berhards Einwand gilt aber immernoch und ich kenne da als Lösung nur DA. (Gibt aber sicher noch andere)
nHibernate als ORPF kommt auch mit ein paar Dialekten DBs klar...

Solche Frameworks gehen aber noch weiter und bieten ein Object-Relationales Mapping an. Die ersten Versionen krankten aber daran das sie fast immer den DB-Inhalt komplett auf Objekt abgebildet haben und dann bei großen DB's abgesoffen sind. Sollte aber heutzutage auch lösbar sein.