Welche Datenbank - zum 1256sten mal

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