Womit zukunftssichere Datenbankanwendungen erstellen?

[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