Moderne Technologien für (Datenbank-) Anwendung

[Morphie]

Hi,

ich spiele mit dem Gedanken ein neues (größeres) Projekt zu starten.
Es soll eine art ERP-Software werden, daher sehr Datenbanklastig.

Was für Technologien würdet ihr da einsetzen, wenn ihr noch die freie Wahl hättet, und die Software sehr langlebig und über Jahre hinweg weiterentwickelt werden soll?

Datenbank:
MSSQL (ist teuer und nur auf Windows-Systemen lauffähig, oder? Die Express-Version ist in einigen Bereichen eingeschränkt, z.B. max 10 GB pro Datenbank)
MySQL (komisches / riskantes / teures Lizenzmodell)
Firebird (eher ein Nieschenprodukt, dafür kostenlos)
PostgreSQL (noch keine Erfahrung mit)
Access (nein, das ist ein Scherz, ich rede von Datenbanken )
...?

Datenbankschicht:
Entity / ORM basiert? (setzt ein gutes DataBinding voraus, unter Dephi wäre das dann wohl LiveBindings / DSharp und unter .NET wäre das dann wohl das normale DataBinding / WPF... Kann man das vergleichen?)
Wenn Entity, welcher Mapper?
Recordset basiert? (wobei ich schon gern meine Modelle gemappt hätte, ist für mich "echter" an objektorientierter Programmierung)

Programmiersprache:
Delphi (in wie weit würdet ihr eine Neuentwicklung, die über Jahre hinweg weiterentwickelt werden soll, in Delphi starten?)
.NET insbesondere C#? (habe ich in letzter Zeit viel mit zutun)
Java? (habe ich noch keine Erfahrung mit)

Oberfläche?
Delphi: VCL / FireMonkey?
.NET: WinForms / WPF?
Java: ???

Architektur?
MVVM? MVC? n-tier? ...


Und was gibt es sonst noch so für Technologien, die man sich eventuell vorher mal ansehen sollte?

Bin gespannt auf eure Antworten

[QuickAndDirty]

Ich würde das Thema von der Seite der Multiplatformfähigeit angehen.
Da bleiben an Datenbanken:

-Firebird (Hier gibt es schon ein OpenSource ERP auf dem man aufbauen könnte, wenn man wollte)
-MariaDB (100% Mysql Kompatibel und von den original MYSQL Entwicklern)
-PostgresSQL (Das ist im Gegensatz zu Firebird VSS fähig und kann also im laufenden Betrieb über schattenkopien konsistent gesichert werden. Bei Firebird muss man eine Sicherung per GBAK mitliefern)

Die Geschäftslogik würde ich nicht in dem DB Server unterbringen wollen wegen der Login Risiken. Evtl. sollte alles auf mehreren verschiedenen Datenbanksystem laufen. Viele Oracle oder MSSQL Kunden wünschen sich das das System den bereits vorhandenen arschteuren DBServer auch benutzt. Also bräuchte es eine Abstraktionsschicht die auf mehreren Plattformen vernünftig läuft.

Ich weiß das AnyDac stabil und rattenschnell mit MSSQL und Firebird läuft. Das verlagert das filtern intelligent auf den Server und arbeitet intelligent im Zugriff.
Ich weiß nicht ob es ein passendes ORM gibt das auf TDataset (Tables und Queries) aufsetzt.
Auf jeden Fall gibt es Anydac für Lazarus und damit für alle Plattformen.

Als IDE würde ich seit "Codetyphon" Lazarus nehmen. Oder irgend eine C++ IDE.

Als Anwendungsmodell würde ich entweder MVP(mit passivem Presenter) nehmen oder eigentlich viel lieber eine klassische Webservices orientierte Webanwendung. Dadurch habe ich ein Frontend das auf jedem "Device" ohne Installationsaufwand funktioniert und ein Backend wo sich die Wartungsarbeiten konzentrieren. Außerdem habe ich durch eine Aufteiling der Anwendung in Webservices die Möglichkeit Kundenspezifische Geschäftsprozesse mittels BPMN oder BPL Transparent zu modellieren. Das wäre natürlich nur notwendig wenn das ERP für den Markt und nicht für einen einzigen Kunden mit recht festen Strukturen entwickelt würde.
Man würde das ERP dann natürlich mit einem Referenzmodell ausliefern. Und das customizing nach Aufwand abrechnen und/oder einen Superuser dafür schulen.
Gerade durch den ORM Ansatz bietet sich dann ja auch eine Weboberfläche an da man ViewObjekte ja dank RTTI/Reflections direkt in XML für XHTML Darstellung umwandeln kann. Mit nem CSS würde es dann noch hübsch und customizeable.

[Lemmy]

Hallo,

ein Großteil der Fragen ergibt sich / erledigt sich, wenn man ne entsprechende MArktstudie gemacht hat - denn die sagt dann aus, was gebraucht wird, ob es eher kleine und mittelständische Firmen sind (wo Firebird ne attraktive Sache ist) oder für größere Mittelständler, die i.d.R. eh schon oracle und oder MS SQL am laufen haben - da spielt eine DB mehr oder weniger auch keine ROlle mehr.

und eine Aussage zu "und die Software sehr langlebig und über Jahre hinweg weiterentwickelt werden soll?" kann eh keiner machen oder glaubst Du noch an den Weihnachtsmann? Mach die SOftware so, dass diese über die nächsten Jahre hinweg angepasst und gewartet werden kann - alles andere spielt dann keine Rolle mehr. Und dafür gibt es genügned Fachliteratur wie man so was angeht.

Welche Sprache du einsetzen sollst, welches ORM - das sind alles Themen die von deinen bestehenden Ressourcen beantwortet werden. Soll das innerhalb 12-24 Monate einen vorzeigbaren Stand haben, dann musst Du viel gleichzeitig machen, d.h. da müssen viele Entwickler gleichzeitig an irgend welchen MOdulen arbeiten, da hat .NET durch die Assemblies eine gute Antwort, Delphi mit den BPL ist da nach Aussagen im Internet wohl deutlich anfälliger und komplexer. Allerdings brauchst Du dann halt auch fitte Leute in .NET.

Und wenn es dir um die Frage geht ob Du was neues in Delphi oder doch besser in was anderem machen sollst: Kannst nur DU beantworten. Wir hier auf der Arbeit werden auch weiterhin mit Delphi arbeiten. Aktuell ist noch Delphi 7, nächstes Jahr kommt hoffentlich der Umstieg auf XE2. Damit ließe sich dann sicherlich auch die nächsten 10-12 Jahre entwickeln - und was dann kommt, das schauen wir wenn es so weit ist.

Grüße

[WM_CLOSE]

Ist vielleicht auch je nach größe der Softwareschmiede eine finanzielle Frage.
C# und Java Entwickler gibt es billig wie Sand am Meer. Delphientwickler sind teuer und auch persönlich etwas eigen.

Bei einem kleinen Unternehmen ist natürlich die persönliche Vorliebe der vorhandenen Entwickler viel wichtiger.

[Phoenix]

Hrm. Gute Frage. Da gibts keine pauschalen Antworten. Kann es nicht geben. Ich bin für solche Themen immer mal wieder nebenberuflich als Consultant unterwegs - und das wäre eigentlich genau so ein Kandidat.

Ich bin mir eigentlich grad sogar ziemlich sicher, das der klassische Ansatz, ein ERP-System zu erstellen und zu vertreiben zwar funktionieren würde - ein anderer Ansatz an den ihr vermutlich gerade gar nicht denkt aber vermutlich deutlich rentabler wäre.

Die Datenbank-Frage kann mit dem Topic schon erschlagen werden. Ihr wollt ERP anbieten - und die Zielgruppe ist das E da drin. Weil nicht-E braucht kein E-RP. Also braucht ihr - sofern ihr das beim Kunden hosten lassen wollt - eine Datenbank die in die Infrastruktur beim Enterprise-Kunden passt. Das wären vermutlich MS-SQL, Oracle oder DB2. Mit OpenSource-Lösungen braucht man im Enterprise nicht anzukommen, da es hier nahezu unmöglich ist das üblicherweise geforderte SLA (Service-Level-Agreement) zu leisten. Auf keinen Fall geht das ohne zuverlässigen(!) (und damit in aller Regel kommerziellen) Support.

An Technologien im Enterprise-Umfeld bieten sich hier eigentlich nur Java und .NET an. Es gibt kein einheitliches "Enterprise". Es gibt größere und kleinere. Das heisst wenn eine Software in dem Bereich erfolgreich sein will, muss sie mit den Anforderungen mitwachsen. Und nur Anwendungen auf einer skalierbaren Infrastruktur können das leisten. Und Enterprise-Frameworks gibts halt auf diesen Plattformen for free. (z.B. Microsoft Enterprise Library für .NET).

Damit wären wir dann auch schon bei der Architektur. Hinten: SOA. Das hat viele Vorteile, die das gerne dagegen vorgebrachte Totschlagargument 'Komplexität und sich-zu-tode konfigurieren" aber mehr als wieder Wett machen. Wenn hinten Services stehen (nur die lassen sich auch nötig Skalieren, wo wir's schon davon hatten), dann ist das Frontend eigentlich egal.

Viele andere ERP-Anbieter gehen von Desktop-Applikationen inzwischen hin zu Web-Frontends. Das hat viele Vorteile (u.a. ist das 'Plattform'-Problem damit komplett vom Tisch, jedes OS hat einen Browser). Die Architektur verhindert aber auch nicht, für einzelne Devices mit der jeweils idealen Technologie zusätzliche, angepasste Frontends zu bauen, sondern macht genau dies überhaupt erst Möglich. Und gerade im Enterprise-Umfeld kommt BYOD (Bring your own device) z.B. mit iPads im Management immer mehr - und denen dort dann gleich Reports über eine App zu präsentieren wann sie es wollen ist ein cooles Feature - und mit einem native wrapper um eine kleine Webseite superschnell implementiert.

So, nu aber genug. Sonst grab ich meinem Consulting-Geschäft noch selber das Wasser ab

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