Womit zukunftssichere Datenbankanwendungen erstellen?

[Matze]

Hi zusammen,

eine Frage aus reinem interesse:
Womit sollten heutzutage Datenbankanwendungen geschrieben werden, die zukunftssicher sind?
Wichtig wäre, dass ohne große Kosten kommerzielle Software damit geschrieben werden kann. Ich kenne mich mit den Lizenzen da nicht so gut aus. Beispielsweise, ob man das kostenlose Visual Studio Express kommerziell nutzen darf.

Programmiersprachen/Frameworks

Zum Einen gibt es da verschiedene "Umgebungen" wie:

- .NET-Framework
- Win32
- Win64

Dann natürlich Programmiersprachen:

- Delphi
- C++
- C#, Visual C++, Visual Basic, J# (alles für .NET)
- Java
- ...

Und dann noch verschiedene Frameworks oder was das genau ist

- WinForms (veraltet)
- WPF (neuer als WinForms, doch vermutlich auch bald veraltet)
- Silverlight (glaub das ist noch recht aktuell, aber zukunftssicher?)
- LightSwitch (momentan in der Betaphase, aber wer weiß, wie lange es bestehen wird)

Gerade bei den ganzen MS-Entwicklungen wie den letzten genannten Punkten stehe ich sehr kritisch gegenüber. Diese sind dermaßen kurzlebig, dass ich bei soetwas vorsichtig wäre.
Die klassische Programmiersprache C++ besteht seit Jahrzehnten und wird heute immer noch gerne eingesetzt. Daher sehe ich hier auch in den nächsten Jahrzehnten so schnell kein Ende dieser Sprache. Ich weiß jedoch nicht, wie es hier mit der grafischen Oberfläche aussieht. Wenn das so ein Krampf ist wie bei Java, wäre das schlecht.
Aber es gibt viele professionelle Anwendungen mit ansprechenden GUIs, die in C++ geschrieben sind.

Datenbanken

Jo, da gibt es auch nicht weniger Auswahl:

- MySQL
- MSSQL
- Firebird
- Access
- ...

Welche Programmiersprache mit den verschiedenen Datenbanken umgehen kann, muss dann natürlich auch noch untersucht werden.
Das Ganze sollte unter Windows laufen, aber es wäre sicher kein Fehler, wenn es zusätzlich leicht nach Linux portierbar wäre.

Ich bin sehr auf sachliche Beiträge gespannt und möchte kein Diskussionen, die aus dem Ruder laufen.

Grüße
Matze

[Mithrandir]

Zitat:

Zitat von Matze (Beitrag 1066131)

Beispielsweise, ob man das kostenlose Visual Studio Express kommerziell nutzen darf.

Darf man, steht in den AGB.

Die Kombination Visual Studio 2010 Professional, C# und MSSQL 2008 läuft bei mir eigentlich ordentlich. Mit der Expressversion kommst du Datenbankmäßig imho nicht weit...

Ich wäre momentan vorsichtig, mich auf ein bestimmtes grafisches Framework festzulegen. WPF ist sicherlich nicht am Aussterben, auch Microsoft hat die Aussage mittlerweile revidiert. Windows Forms wird momentan immer stärker vernachlässigt. LightSwitch ist imho eine Mischung aus Access und Visual Foxpro. Die SQL-Abfragen sind grottig, beim 3-Schichten-Modell wird (momentan) zwingend ein IIS benötigt, ebenso ein DBMS von Microsoft. Ich arbeite damit und werde jedesmal leicht grünlich im Gesicht. Es ist halt doch mehr für den versierten Abteilungsleiter, der sich seine Arbeitnehmerverwaltung zusammenbauen will.

Momentan scheint es für mich, als wolle Microsoft immer mehr in die Cloud gehen bzw. ins Web. Ob HTML 5 den heiligen Gral darstellt... Ich weiß nicht. Silverlight ist ein guter Ansatz, Beta 5 kommt im Frühjahr 2011. Momentan würde ich auf WPF und/oder Silverlight setzen. Allerdings ist die Lernkurve massiv. Frust ist vorprogrammiert. Wenns dann aber funktioniert, isses geil. :mrgreen:

DBMS? Hmm. Von Oracle würde ich die Finger lassen, Microsoft kocht sein eigenes Süppchen. Ggf MySQL, da ist nur der Support kostenpflichtig.

[stahli]

Man sollte sicherlich als erstes klären, wo die DB laufen soll und wie darauf zugegriffen werden soll (Desktop, Internet, Browser).
Außerdem ist sicher wichtig wie groß und komplex die DB werden muss.

Ich denke, so pauschal kann man da kaum sinnvoll etwas zu sagen...

[Matze]

Danke für deinen Beitrag Daniel.

Dann gehe ich noch eine Stufe weiter, wo ich gerade "Cloud" lese.
Die Anwendungen müssen eigenständig auf einem PC lauffähig sein, der nicht ans Internet angeschlossen ist.

Wenn es eine Möglichkeit gibt, so eine Anwendung zusätzlich über den Browser bedienen zu können, dann ist das evtl. nett aber (noch) nicht erforderlich.

Edit @Stahli: Auch dir dankeschön. Es können schon einige Millionen Datensätze sein. Also große Datenbanken sollten ohne Einschränkungen verwendet werden können. Die Anwendungen selbst laufen auf einem PC und die Datenbank muss nicht unbedingt an dem PC laufen. Diese könnte auch auf einem externen Server oder einem zweiten Rechner liegen.

[Insider2004]

MS ist immer gross im Einführen on neuen Dingen. Leider sind sie dann wie ein kleines Kind. Das Spielzeug ist langweilig und wird in die Ecke geworfen sprich vernachlässigt und nicht mehr gepflegt. Sie lassen dann die Entwickler im Regen stehen. Siehe Visual Basic Native oder J# oder Silverlight. Alles mehr oder weniger tot. Es gibt bestimmt noch 20 andere Techniken, die ich zum Glück nie gelernt/gekauft habe und vergessen habe!!! :-D Das Einzige, was bei MS Bestand hat ist die Win32 API.

[Lemmy]

Zitat:

Zitat von Matze (Beitrag 1066131)

Womit sollten heutzutage Datenbankanwendungen geschrieben werden, die zukunftssicher sind?

am besten gar nicht. Schau dir nur mal die letzten 10 Jahre an was aus VB (nicht .Net), Kylix und Interbase wurde.

Zitat:

Zitat von Matze (Beitrag 1066131)

Wichtig wäre, dass ohne große Kosten kommerzielle Software damit geschrieben werden kann. Ich kenne mich mit den Lizenzen da nicht so gut aus. Beispielsweise, ob man das kostenlose Visual Studio Express kommerziell nutzen darf.

Was soll das? Die 1000€ für eine IDE bzw. 5.000-7.500€ (einfach mal ins blaue geschätzt) für einen Arbeitsplatz sind Peanuts! Was ins Geld geht sind die Personalkosten! Diese kann man mit sinnvollen Arbeitsumgebungen zwar nicht reduzieren aber wesentlich mehr herausholen! Wenn du "billig" programmieren willst, dann verwende [Übertreibung] Turbo Pascal 5.5 oder Vb 6.0 [/Übertreibung] ;-) Oder verwende Notepad und einen Kommandozeilencompiler. Sehr billig, die Entwicklung wird aber ewig dauern....

Zitat:

Zitat von Matze (Beitrag 1066131)

Programmiersprachen/Frameworks

Kommt auf deinen Geschmack und auf die vorhandenen Ressourcen an. Wenn du ein großes Entwicklerteam hast, die an einer Anwendung arbeiten müssen, ist .NET durch das Assembly-Konzept jeglichen Win32-Sprachen im VOrteil. Weiterhin wirst Du einfach wesentlich schneller genügend Mitarbeiter finden.

Zitat:

Zitat von Matze (Beitrag 1066131)

- WPF (neuer als WinForms, doch vermutlich auch bald veraltet)

OT:
??? Habe ich was nicht mitbekommen? In den letzten WOchen wird als Gerücht in div. Blogs immer von Silverlight gesprochen, das eingestellt werden soll, aber warum denn WPF? Dann kann Microsoft mit .Net endgültig einpacken....

Zitat:

Zitat von Matze (Beitrag 1066131)

Datenbanken

Wie bei den Programmiersprachen: Es kommt darauf an. Div. Firmen lassen kein Oracle auf ihre Server, andere keine MS SQL usw. Das ändert sich aber auch immer i.d.R: mit dem Personalwechsel bei Systemadmin ;-) Da werden schon mal eben kurz eine Serverfarm mit funktionierendem Linux-Mailserversystem auf Exchange umgestellt :-)

Was wichtig wäre:
* Die Businnesslogik sollte getrennt von allem erarbeitet werden, d.h. Einsatz einer entsprechenden Beschreibungssprache (UML) um bei einem ggf. notwendigen Systemwechsel zumindest das Businessmodell retten zu können.
* schlägt in die selbe Kerbe: Schichtenaufbau der Anwendung, d.h. die Schichten GUI, Businessmodell und Datenbank greifen nicht direkt aufeinander zu sondern über definierte Schnittstellen (da gibts auch jede Menge Patterns dazu). Damit lässt sich zum einen die Datenbank relativ "einfach" austauschen, zum anderen gäbe es ggf. die Möglichkeit eine andere GUI anzusprechen (z.B. mit einem Delphi-BOM eine .NET Oberfläche "bedienen")
* Vergiss auf übermorgen zu schauen: Du weißt nicht mal was morgen passiert. Meine Bekannten, die sich in der Branche auch auskennen, machen mich immer dumm an: Wer mit Delphi programmiert, der gehört vor Gericht. War aber vor 10 Jahren auch schon so. Je vorsichtiger Du irgenwelche Entscheidungen angehst, je länger (und teurer) wird im Endeffekt deine Entwicklung werden. Das heißt jetzt nicht renn blind durch die Gegend, sondern es gehört einfach ein gesundes Maß dazu. Und Fehlentscheidungen gehören hier wie überall einfach dazu....

GRüße

[stahli]

Zitat:

Zitat von Matze (Beitrag 1066142)

Wenn es eine Möglichkeit gibt, so eine Anwendung zusätzlich über den Browser bedienen zu können, dann ist das evtl. nett aber (noch) nicht erforderlich.

Edit @Stahli: Auch dir dankeschön. Es können schon einige Millionen Datensätze sein. Also große Datenbanken sollten ohne Einschränkungen verwendet werden können. Die Anwendungen selbst laufen auf einem PC und die Datenbank muss nicht unbedingt an dem PC laufen. Diese könnte auch auf einem externen Server oder einem zweiten Rechner liegen.

Dann werden Dir wohl 90% aller DP-User (und ich) zu Firebird raten (zumindest würde ich damit mal anfangen). Zugriffsmöglichkeiten von Delphi aus gibt es dann mehrere (am einfachsten IBX).
Ein Tool wie IBExpert vereinfacht die Organbisation der Datenbanken.

[alzaimar]

Zitat:

Zitat von Mithrandir (Beitrag 1066137)

...MSSQL 2008 ...Mit der Expressversion kommst du Datenbankmäßig imho nicht weit...

Wenn das auf MSSQL bezogen ist, kann ich das nicht teilen.

Zitat:

Zitat von Mithrandir (Beitrag 1066137)

DBMS? Hmm. Von Oracle würde ich die Finger lassen, Microsoft kocht sein eigenes Süppchen. Ggf MySQL, da ist nur der Support kostenpflichtig.

Wie bitte? Wenn Zukunftssicher, dann PostGres, MSSQL oder Oracle. Auf jeden Fall entweder eine Datenbank, die es schon ewig gibt, eine von einem sehr großen Anbieter, der mit der DB ordentlich Schotter macht, oder alles zusammen. Da ist ja wohl Oracle und MSSQL ganz weit vorne. Andere natürlich auch.

Ansonsten würde ich persönlich C#, aber ohne dickes Framework verwenden und der DB-Anbindung ein hohes Abstraktionsniveau spendieren, d.h. so vieles wie möglich (und sinnvoll) in 'Stored Procedures' packen, die entweder im SQL-Server oder in einem Applikationsserver ausgeführt werden.

Dann würde ich mir noch überlegen, wie lange die Anwendung den leben soll. Wir reden ja hier nicht von 100 Jahren, sondern von vielleicht 10-15. Wenn Du heute in C# entwickelst, bist du auf der sicheren Seite. Mit Fortran und Cobol übrigens auch, das gibt es alles noch und wird es immer geben. Auch wenn Du den Riesenfehler gemacht hättest, und vor 10 Jahren in VB entwickelt hättest, wärst du heute nicht am Ende. Man muss ja wohl nicht immer die neuesten Compiler kaufen.

Eine Anwendung von mir ist in D6 geschrieben und da der Kunde die Migration zu einem modernen Delphi nicht bezahlen will, bleibt es dabei. WTF. Dem Programm ist es doch nicht peinlich, das es mit einer alten IDE entwickelt wurde.

Was ich garantiert nicht und auf keinen Fall machen würde, ist:
* Irgendwelchen neumodischen Schnickschnack
* Irgendwelche OpenSource oder Freeware-Komponenten (selbst bei einer DB wäre ich zurückhaltend)
verwenden.

Nachhaltig = Konservativ und Simpel.

Du kannst ja jederzeit eine total abgefahrene GUI rüberstülpen. Da holt man sich ein paar Freaks, die einem die GUI designen und tauscht die alle paar Jahre aus. Im Hintergrund werkelt, wenn gut geschrieben, immer die gleiche gute alte Engine.

Macht MS doch genau so und verdienen sich einen Wolf (Siehe Word, nur das da bis vor Kurzem keine 'gute alte Engine' werkelte, die gut geschrieben war).

[Bernhard Geyer]

Zitat:

Zitat von Matze (Beitrag 1066131)

- MySQL

Da wird in die nächsten Jahre "interessant" inwieweit MySQL von Oracle "an die Leine" genommen wird. Die günstiges Lizenzversion wurde von Oracle schon gestrichen so das man hier schon eine verdreifachung der Kosten hat. Inwieweit die Embedded/libmysql-Kosten bei Closed-Source steigt weis ich nicht. War ja schon vor Oracle-Zeiten mit 30 k€/a nicht gerade günstig für kleinere Firmen

[Matze]

Zitat:

Zitat von Lemmy (Beitrag 1066146)

Was soll das? Die 1000€ für eine IDE bzw. 5.000-7.500€ (einfach mal ins blaue geschätzt) für einen Arbeitsplatz sind Peanuts! Was ins Geld geht sind die Personalkosten!

Ich meinte nicht die einmaligen Kosten, sondern eher die laufenden (Lizenzgebühren für Datenbanken, die Rechnerbezogen sind o.ä.)

Zitat:

Zitat von Lemmy (Beitrag 1066146)

* Vergiss auf übermorgen zu schauen: Du weißt nicht mal was morgen passiert.

Muss man heutzutage aber, wenn man nicht alle paar jahre die Anwendungen in irgendwelche SPrachen portieren möchte.
Ziel ist es, eine Art Standard in der Firma zu schaffen, der zukünftig genutzt werden kann.

z.B. eine Klasse zum Lesen und Schreiben in die Datenbank, eine zum Durchsuchen der Datenbank etc.

Wenn die Klassen mal ausgereift sind, möchte ich die auch in 10 Jahren noch nutzen können im Idealfall.
Das können natürlich auch DLLs werden, die angesprochen werden können.
Alles andere verursacht sonst immense Kosten. Also die Zukunft muss ich im Auge behalten.

@Mark: Zu C# tendiere ich momentan auch oder zu C++. Bei MSSQL muss ich mir die Lizenzkosten einmal ansehen. Momentan wird Access verwendet und wenn die Kosten nicht viel teurer sind, wäre das sicherlich in Ordnung.

Wie kann man denn eine GUI "rüberstülpen"?
Du meinst, man trennt natürlich Logik von der GUI und bei einer neuen GUI werden entsprechende Klassen für die Datenverarbeitung aufgerufen und eben an neuen Controls angezeigt?

[Mithrandir]

Zitat:

Zitat von alzaimar (Beitrag 1066158)

Wie bitte? Wenn Zukunftssicher, dann PostGres, MSSQL oder Oracle. Auf jeden Fall entweder eine Datenbank, die es schon ewig gibt, eine von einem sehr großen Anbieter, der mit der DB ordentlich Schotter macht, oder alles zusammen. Da ist ja wohl Oracle und MSSQL ganz weit vorne. Andere natürlich auch.

Ich höre diejenigen, die bei uns mit Oracle arbeiten, nur immer laut fluchen. Von daher wollte ich ihm das ersparen. Von MSSQL habe ich ihm nicht abgeraten, ich wollte nur auf T-SQL hindeuten.

[s.h.a.r.k]

Allgemein hört man hier halt schon sehr viel Sachen, die halt dem eigenen Geschmack am nächsten kommen. Ich persönlich muss mit Oracle im Moment arbeiten und hab eher weniger Probleme damit. Man muss halt auch einiges nehmen wie es ist, sonst artet es eben in Grundsatzdiskussionen aus, wer denn was warum am liebsten mag und warum etwas anderes untauglich ist. Wobei das meist subjektiv ist.

Dass C# noch lange leben wird, sollte jedem klar sein, ebenso C++. Aber wer schon mal mit C++ zu tun gehabt hat, weiß Delphi zu schätzen imho. Man kann viel Schabernack damit treiben und Effizienz ist eben nicht alles. Da schreibe ich dann lieber in einer Scriptsprache à la Python oder eben the Delphi way. HTML5 wird zurzeit imho überbewertet, da man immer an einen Browser gebunden ist und dafür optimieren darf. Ich denke auch nicht, dass man non stop Code in eine andere Sprache portieren wird -- welcher Kunde zahlt denn das freiwillig? Dem ist es doch (meist) gleich, in welcher Sprache es geschrieben ist. Das Programm muss sich nur in eine gegebene Struktur einpassen und das Ergebnis zählt.

[implementation]

Zitat:

Zitat von Matze (Beitrag 1066131)

Ich weiß jedoch nicht, wie es hier mit der grafischen Oberfläche aussieht. Wenn das so ein Krampf ist wie bei Java, wäre das schlecht.

Ach, bei C++ sollte das kein Problem sein.
Wenn du Emba's C++Builder nimmst, haste die gewohnte VCL;
Bei Microsoft's C++ solltest du die MFC haben, bzw. bei Managed C++ hättest du das Problem der Wahl zwischen WinForms und WPF (WinForms gilt zwar als veraltet, ich favorisiere es aber trotzdm noch und es würde mich auch nicht wundern, wenn es trotzdem noch eine ganze Weile durchhält).

Ansonsten gäbe es da noch GTK und Qt, damit könntest du die Anwendungen sogar auf Linux portieren.

[s.h.a.r.k]

Alte Standards à la WinForms werden wohl nie so richtig sterben, da es große Anwendungen darin gibt -- behaupte ich jetzt einfach mal so :mrgreen -- die man nicht so einfach mal schnell umschreibt bzw. einen Kunden findet, der das zahlt. So geht es mit vielen Sachen, obwohl es (angeblich) schon "tollere" Sachen gibt.

[Lemmy]

Zitat:

Zitat von Matze (Beitrag 1066162)

Ich meinte nicht die einmaligen Kosten, sondern eher die laufenden (Lizenzgebühren für Datenbanken, die Rechnerbezogen sind o.ä.)

sind immer noch billiger als 70.000-100.000 € die dir ein Softwareentwickler als Angestellter kostet. Nicht eingerechnet Einarbeitung, Fortbildung, Krankheit und Verlust durch Arbeitsplatzwechsel.

Zitat:

Zitat von Matze (Beitrag 1066162)

Wenn die Klassen mal ausgereift sind, möchte ich die auch in 10 Jahren noch nutzen können im Idealfall.
Das können natürlich auch DLLs werden, die angesprochen werden können.
Alles andere verursacht sonst immense Kosten. Also die Zukunft muss ich im Auge behalten.

Die Geschichte kennst Du sicherlich: Eine Firma hat eine Super Software geschrieben. Richtig viel Geld in die Hand genommen, da kamen einige Mannjahre Arbeit heraus. Das Ding war ein Nischenprodukt. Bei der Präsentation bei der Kundschaft waren diese begeistert, noch begeisterter waren die aber von den Zukunftsaussichten die die Firma beschrieb: SUper tolle neue Funktionen in der nächsten Version. Also wartet der Kunde auf Version 2. Und was passiert: Geld geht aus, Firma pleite, keine Version 2.

Klar muss man die Zukunft im Auge behalten, aber du solltest das Jetzt dabei nicht aus dem Blickfeld verlieren.

Ein Arzt, ein Architekt oder ein Ingenieur ist es wurscht mit welcher Sprache du programmierst und wie du deine Daten speicherst. Das ist beim Militär anders. Bei Daimler und Allianz wird sicherlich das DBMs entscheidend sein, je nach Geschäftsbereich auch die Sprache. Also entscheide nach Kriterien mit denen du das Ziel am besten erreichst.

und noch was zur Zukunftssicherheit: das Wort agil (ich hasse es) hat in der IT-Welt, insbesondere in der Softwareentwicklung einen gewissen Stellenwert. Meiner Meinung solltest Du davon Abstand nehmen was zu entwickeln was in 10 Jahren noch funktioniert, mach lieber was, das mit der Zeit wachsen kann und dessen funktionsweise sich neuen Herausforderungen stellen kann. Wenn Du an deiner Zukunftssicherheit zwanghaft festhälst könntest Du schneller zum alten Eisen gehören als dir lieb ist... ;-)

[Matze]

Zitat:

Zitat von Lemmy (Beitrag 1066207)

Ein Arzt, ein Architekt oder ein Ingenieur ist es wurscht mit welcher Sprache du programmierst und wie du deine Daten speicherst.

Nur mal so: Ich bin Ingenieur und mir ist das nicht ganz egal.

Zitat:

Zitat von Lemmy (Beitrag 1066207)

Das ist beim Militär anders. Bei Daimler und Allianz wird sicherlich das DBMs entscheidend sein, je nach Geschäftsbereich auch die Sprache. Also entscheide nach Kriterien mit denen du das Ziel am besten erreichst.

Ich arbeite im Maschinenbau und es geht um die Anlagensoftware. Ich weiß nicht, ob ich das mal übernehmen werde aber wenn, möchte ich grob wissen, worauf es hinauslaufen kann. Das DBMS könnte z.T. vom Kunden vorgeschrieben werden ja. Daher möchte ich die Möglichkeit haben, mehrere Datenbanken ansprechen zu können.

Zitat:

Zitat von Lemmy (Beitrag 1066207)

Bei der Präsentation bei der Kundschaft waren diese begeistert, noch begeisterter waren die aber von den Zukunftsaussichten die die Firma beschrieb: SUper tolle neue Funktionen in der nächsten Version. Also wartet der Kunde auf Version 2. Und was passiert: Geld geht aus, Firma pleite, keine Version 2.

Die Kunden werden hier keine Version 2 fordern. Wenn die Maschinen laufen, besteht kein Grund, die Software zu aktualisieren.
Ich kenne es z.B. von der Forensoftware phpBB. Wenige Einstellungen und man kann von MySQL auf Oacle wechseln, soweit ich weiß (die SQL-Queries sind kompatibel).

Zitat:

Zitat von Lemmy (Beitrag 1066207)

Meiner Meinung solltest Du davon Abstand nehmen was zu entwickeln was in 10 Jahren noch funktioniert, mach lieber was, das mit der Zeit wachsen kann und dessen funktionsweise sich neuen Herausforderungen stellen kann. Wenn Du an deiner Zukunftssicherheit zwanghaft festhälst könntest Du schneller zum alten Eisen gehören als dir lieb ist... ;-)

Jain. Bei Software, die Kunden bedienen müssen ist das sicher so. Erweiterbar muss natürlich jede Software sein, keine Frage.
Aber einen gewissen Standard zu haben, den man lange nutzen kann (spart Entwicklungszeit), finde ich sinnvoll.

[Lemmy]

Zitat:

Zitat von Matze (Beitrag 1066213)

Zitat:

Zitat von Lemmy (Beitrag 1066207)

Ein Arzt, ein Architekt oder ein Ingenieur ist es wurscht mit welcher Sprache du programmierst und wie du deine Daten speicherst.

Nur mal so: Ich bin Ingenieur und mir ist das nicht ganz egal.

LOL Aber nur deshalb weil du die Software herstellst. Wenn Du nur Nutzer bist, sind andere Dinge wichtig!

Zitat:

Zitat von Matze (Beitrag 1066213)

Aber einen gewissen Standard zu haben, den man lange nutzen kann (spart Entwicklungszeit), finde ich sinnvoll.

Kein Thema, aber diese Standards nennen sich OOP, Patterns und agile Entwicklungsmethoden (Unittests,....).
und klar, wenn Du eine Maschinensteuerung schreibst, ist es sicherlich sinnvoll für bestimmte Aufgaben entsprechende Bibliothekten/Klassen zu erstellen, die diese Aufgaben entsprechend kapseln. Aber da sprechen wir wieder von OOP ;-)

Schau dir mal bestehende OPFs an. Hibernate gibts z.B. für .NET und Java. Spielt damit mal herum. Wenn Du Hintergrundinfos zur Erstellung von OPFs willst, dann sags, ich habe irgend wo 2 PDFs rumliegen die das Thema etwas beleuchten, die muss ich aber erst suchen...

Grüße

[DSCHUCH]

Hallo,

man kann sich nicht wirklich für immer festlegen. Man sagt nicht umsonst Software hat eine Lebensdauer von 10(?!) Jahren. Wir verwenden Delphi seit 10 Jahren, ich gehe auch davon aus das es weitere 10 Jahren problemlos möglich sein wird. Ob eine "Newcommer" technologie wirklich zukunftssicherer ist als eine klassische alte technologie, vorrausgesetzt diese wird weiterentwickelt, und hier schaut es ja nach Jahren des Stillstands auch bei Delphi wieder besser aus, sei dahingestellt. Bisher ist es zuverlässig und sehr verfügbar, erfüllt gerade im Frontendbereich alle unsere Bedürfnisse.

Die einzige Sache worauf ich inzwischen immer achte ist Quellcode. Ich binde nach Möglichkeit nichts ein wofür ich keinen Quellcode erhalte, dort habe ich meine Erfahrungen gemacht.

Wir verwenden DevExpress, PostgreSQL {zum Glück haben wir uns vor 10 Jahren für das unbekanntere DBMS PostgreSQL und nicht auf den damaligen Hype MySQL festegelegt} (mit Devart, früher mit ZEOS) und diverse andere namenhafte Komponenten.

Weiterhin haben wir eine Erfahrung gemacht: wenn der Kunde vorschreiben (häufig noch mit halbwissen) will was wir für eine Technologie einsetzen sollen, ist es idR auch ein Kunde mit dem man dann nur Theater hat von daher vertrete ich hier sowieso eine andere Philosophie. (natürlich prüfen wir die Anregungen aber wenn Bsp. jemand erklärt man verwende Serverseitig Unix nur weil man sich Windows nicht leisten kann - nun ja - ich denke das kennt jeder aus der Branche)

Daniel.

[messie]

Zitat:

Zitat von Matze (Beitrag 1066213)

Ich arbeite im Maschinenbau und es geht um die Anlagensoftware. Ich weiß nicht, ob ich das mal übernehmen werde aber wenn, möchte ich grob wissen, worauf es hinauslaufen kann. Das DBMS könnte z.T. vom Kunden vorgeschrieben werden ja. Daher möchte ich die Möglichkeit haben, mehrere Datenbanken ansprechen zu können.

Wenn es die Anlagensoftware wird, kommen für mich aber noch andere Kriterien in Betracht: wieviel Hardwarezugriffe, gibt es evtl. Steuerkomponenten, mit denen direkt gesprochen werden muss? Muss die Software eigensicher und validiert sein?

D.h. das Anlagenkonzept spielt für mich entscheidend in die Auswahl von Umgebung und Basis rein.

Grüße, Messie