Moderne Technologien für (Datenbank-) Anwendung

[Furtbichler]

Zitat von WM_CLOSE:

C# und Java Entwickler gibt es billig wie Sand am Meer.

Java=Ja, C#=Nein (merken wir gerade, da wir suchen)

Ich habe vor 15 Jahren mal ein MES gebaut und MSSQL verwendet. Mittlerweile würde ich bei Datenbanken auf PostGres umschwenken, wenn der Kunde kein Geld für ein RDBMS ausgeben will. Das ist 'fett'.

Die Logik hatte ich komplett in der DB also SQL-Code untergebracht. Wieso? Weil die Business-Logik auf der Ebene relativ einfach ist und ich dafür keinen Spezialisten (aka Middle-Tier) brauche.

Vermutlich würde ich die Daten per JSON oder XML in die DB übergeben und dort verarbeiten. Ich erwarte 70% statische Strukturen und 30% dynamische (=konfigurierbare) Eigenschaften. Das packe ich mit dem RDBMS mit links. Ich teste aber zunächst die Performance und wenn es nicht passt, ziehe ich doch eine Logikschicht ein.

Alles in allem eigentlich kein großes Ding (also das Backend). Das DB-Design ist der Knackpunkt: Ohne Erfahrung und Können fährst Du jeden Versuch gegen die Wand.

Mit ORM würde ich nicht viel machen, denn ich vertraue der Performance nicht. Je weiter hinten (Backend) ich programmiere, desto mehr Kontrolle möchte ich haben. Und das habe ich bei einem ORM nicht.

Das ORM verwende ich im Frontend, wo ich mich genug mit GUI-Problemen rumschlagen muss.

Vermutlich bin ich zu konservativ und es gibt andere/bessere Meinungen.

Eine Sache noch (Phoenix): Bisher durften wir unsere RDBMS in Firmen einführen, da wir auch den Support geleistet haben. Aber das waren Auftragsarbeiten, kein 'Massenprodukt'.

[Uwe Raabe]

Zitat von Furtbichler:

Mit ORM würde ich nicht viel machen, denn ich vertraue der Performance nicht. Je weiter hinten (Backend) ich programmiere, desto mehr Kontrolle möchte ich haben. Und das habe ich bei einem ORM nicht.

Das deckt sich auch mit meinen Erfahrungen. Eine simple DB-Anwendung mit einem ORM (komplexe sind damit sowieso nur selten brauchbar abzubilden) funktionierte auf einer lokalen (im lokalen Netz) Datenbank noch ganz performant, ging aber ungalublich in die Knie, als es über das Internet ging. Nach der Umstellung auf direkten DB-Zugriff konnte ich das Laden einer überschaubaren Liste von Datensätzen von 20 Minuten auf 0.5 Sekunden herunterschrauben. Mag an dem spezifischen ORM gelegen haben, aber sowas prägt.

Zitat von Furtbichler:

Vermutlich bin ich zu konservativ und es gibt andere/bessere Meinungen.

Es gibt keine besseren Meinungen, nur gleiche und andere.

[QuickAndDirty]

Zitat von Uwe Raabe:

Zitat von Furtbichler:

Mit ORM würde ich nicht viel machen, denn ich vertraue der Performance nicht. Je weiter hinten (Backend) ich programmiere, desto mehr Kontrolle möchte ich haben. Und das habe ich bei einem ORM nicht.

Das deckt sich auch mit meinen Erfahrungen. Eine simple DB-Anwendung mit einem ORM (komplexe sind damit sowieso nur selten brauchbar abzubilden) funktionierte auf einer lokalen (im lokalen Netz) Datenbank noch ganz performant, ging aber ungalublich in die Knie, als es über das Internet ging. Nach der Umstellung auf direkten DB-Zugriff konnte ich das Laden einer überschaubaren Liste von Datensätzen von 20 Minuten auf 0.5 Sekunden herunterschrauben. Mag an dem spezifischen ORM gelegen haben, aber sowas prägt.

Ich dachte auch die Hauptvorteile von einem ORM ist der das der aktuelle Programmstatus in der DB eingefroren ist wenn ich den Stecker ziehe und das ich keine Datenbankreoganisationen brauche wenn ich die Datenstrukturen ändere. Also hilft es vor allem, wenn ich beim Kunden Entwickle und keine langen Ausfälle wegen Datenbankreorganisationen verschwenden will. Da aber kaum ein Kunde auf Dauer täglich mit neuen Anforderungen ankommt die sich auf die Datenstruktur auswirken. Und die meisten Hardware Systeme fallen auch nicht einfach so aus. Deswegen halte ich von ORM auch nicht sooo viel.