Neue Datenbank

[mkinzler]

Noch eine (älterer) Vergleich:

http://web.archive.org/web/201003051...n.com/pg_vs_fb

[jobo]

Zitat:

Zitat von Thomas Feichtner (Beitrag 1366567)

Wie schwer war für die die Umstellung (Syntax,...)?

Was sagen die Kunden bzw. Edv-Betreuer zu Prosgres? Kennen sie die Datenbank oder sehen sie dich mit großen Kulleraugen an wie das leider beim ADS ein wenig war.

Benötigt man bei Postgres exclusiven Zugriff bein einer DB-Änderung?

Die Syntaxumstellung für SQL sollte kaum auffallen. Kommt aber darauf an, wo man herkommt. Wie auch immer, die Hersteller halten sich weitestgehend an definierte Standards bzw. haben (zusätzlich) eine eigene Parallelwelt oder bilden sogar die "Quasi" Standards der großen Konkurrenz ab. (z.B. Postgres hat einen ganzen "Haufen" Scripte, mit denen man es kompatibel zu Oracle DB macht.
Hat ein Hersteller eine "eigene" Funktion erfunden, gibt es logischerweise keine kompatible Syntax bei anderen Herstellern.

Ein Tochterunternehmen eines sehr großer deutschen Anbieters von Internet und Telefonie Diensten ist vor 2 Jahren mit einem gemeinsamen Projekt auf Postgres (von mysql) geschwenkt.

Exclusiven Zugriff benötigt man nicht. Dennoch ist es so, dass es häufig Abhängigkeiten zwischen den einzelnen Tabellen, Views, SP gibt, die nach einer Typänderung nicht mehr passen (würden)
Jeder Hersteller handhabt das unterschiedlich. Postgres liefert bei Typänderungen Hinweise oder Fehler, wenn abhängige Objekte betroffen sind. Die müssen dann "abgeklemmt" werden und nach der Änderung wieder eingespielt werden. Das geht auch unexklusiv, allerdings legt es die Funktion des Systems für bestimmte Objekte lahm.

[Frickler]

Zitat:

Zitat von bernau (Beitrag 1366590)

Zitat:

Zitat von Frickler (Beitrag 1366586)

Feldänderungen während andere User auf die Tabelle zugreifen??? Benutzer A arbeitet mit Version 1.1 der Software, für die das Datenbankfeld "Blubb" ein Datumsfeld ist, währenddessen Benutzer B schon mit der neuen Version 1.2 arbeitet, die beim Update Feld "Blubb" in ein Stringfeld umwandelt... oder wie soll ich mir das vorstellen?

Es geht um Vergrößerung eines Stringfeldes oder um neues Feld anlegen. Damit trifft keiner deiner Szenarien zu.

Kann trotzdem knallen. Eine Funktion, die einen ganzen Datensatz in eine andere Tabelle / ClientDataSet etc umfüllt und dabei feldweise kopiert kommt ins Schlingern, wenn die Quelltabelle plötzlich ein Feld mehr enthält. Sprich: Du musst im ganzen Programm schon von vorneherein so tolerant programmieren, dass "plötzlich auftretende" Tabellenänderungen das Programm nicht stören.

Ich weiß, dass so eine Funktionalität auf der Wunschliste vieler ADS Anwender stand. Aber warum? Wozu so etwas benutzen?

[p80286]

Eine Datenbank enthält in bestimmten Feldern bestimmte Werte. Diese Feld/Wert Kombinationen werden (meist) über eine Abfrage zurück gegeben.
Wer trotz aller Warnungen mit "select * from mytable..." arbeitet weil er ja alle Felder kennt, muß sich nicht wundern wenn er dann vor die Pumpe läuft.

Gruß
K-H

[mkinzler]

Es geht ja nicht darum, ob auf die Datenbank nach der Änderung noch von älteren Programmen zugegriffen werden kann, sondern ob duie Datenbank es erlaubt, ohne exklusiven Zugriff Metadaten zu ändern.
Dies würde ich nie im laufenden Betrieb machen.
Dein Auto würdest Du ja auch nicht auf der Autobahn bei 150 Tunen lassen.

[Edelfix]

Woher kommt die Meinung das ADS eine ungewisse Zukunft hat?

Gibt es konkrete Hinweise oder ist es eine Vermutung weil SAP den Vertrieb nicht wirklich fördert?

[p80286]

Zitat:

Zitat von mkinzler (Beitrag 1366649)

Es geht ja nicht darum, ob auf die Datenbank nach der Änderung noch von älteren Programmen zugegriffen werden kann, sondern ob duie Datenbank es erlaubt, ohne exklusiven Zugriff Metadaten zu ändern.
Dies würde ich nie im laufenden Betrieb machen.
Dein Auto würdest Du ja auch nicht auf der Autobahn bei 150 Tunen lassen.

Ich würde mir ein paar Gedanken machen, und dann das Auto kaufen was meinen Ansprüchen genügt.
Andere hingegen scheinen ohne genaue Kenntnis der Version der Steuerungssoftware noch nicht einmal einen Fuß in die heiligen Hallen eines Autohändlers zu setzen.

Gruß
K-H

[Bernhard Geyer]

Zitat:

Zitat von Edelfix (Beitrag 1366656)

Woher kommt die Meinung das ADS eine ungewisse Zukunft hat?

Gibt es konkrete Hinweise oder ist es eine Vermutung weil SAP den Vertrieb nicht wirklich fördert?

Genau das. Wenn eine Produkt keine Pflege mehr erfährt sollte man sich Gedanken über alternativen Machen um im Extremfall
(SAP verkauft ADS und der neue Besitzer erhöht mal als Preise/Listenz/Wartungskosten um das 100fache) gewappnet zu sein.

[Frickler]

Zitat:

Zitat von Edelfix (Beitrag 1366656)

Woher kommt die Meinung das ADS eine ungewisse Zukunft hat?

Gibt es konkrete Hinweise oder ist es eine Vermutung weil SAP den Vertrieb nicht wirklich fördert?

• Das Produkt wird nicht mehr beworben
• Das "Supportforum" isn Witz
• Die "Developer Zone" wird nicht mehr weiter gepflegt
• Früher wars so, dass eine Version X erst dann aus dem Support genommen wurde, wenn Version X+2 auf den Markt kam. SAP hat das zu festen Supportzeiträumen abgeändert. Der Support für 10 ist schon abgelaufen, bevor Version 12 kam. Inzwischen ist auch Version 11 abgelaufen. Und bei 12 passiert nix weiter. Unterstützung für Delphi 10.1 und 10.2? Fehlanzeige. Unterstützung für Windows 10 und Server 2016? Fehlanzeige. Beseitigung der z.T üblen Bugs? Fehlanzeige. Roadmap? Fehlanzeige.
• Es gibt auch keinen eigenen Projektmanager mehr für ADS. Das macht der PM für Sybase iAnywhere so nebenbei.

Was sagt uns das alles?

[RSF]

Zitat:

Zitat von Edelfix (Beitrag 1366656)

Woher kommt die Meinung das ADS eine ungewisse Zukunft hat?

Gibt es konkrete Hinweise oder ist es eine Vermutung weil SAP den Vertrieb nicht wirklich fördert?

siehe hier : http://www.delphipraxis.net/191721-o...twicklung.html

[delphirocks]

Meine Erfahrungen mit DBs liegen schon ein paar Jaehrchen zurueck.

Oracle ist teuer, schwierig zu admistrieren und sehr ressourcenintesiv. Dafuer aber full featured und die Stored Procedure Language (PLSQL, ein Ada Dialekt) ist um einiges besser als bei Postgres oder speziell Firebird.

Postgres kann fast alles, was Oracle und SQL Server koennen, kostet nix und ist bekannt fuer seine hohe Code Qualitaet. Eine Besonderheit sind spezielle GIS Features, die DB wird deswegen in der GeoInformatik Szene auch sehr viel eingesetzt.

MySql nehm ich her, wenn ich eine leichtgewichtige DB haben will, die mehr oder weniger nur als Datenstore dient.

Firebird hat ein paar komische Eigenschaften (z.B. mehrere Dialekte), ausserdem ist die Stored Procedure Sprache sehr gewoehnungsbeduerftig. Ein Vorteil ist allerdings, dass es auch eine serverless Option gibt, dh. man greift per Dll einfach auf's Datenfile zu, was fuer offline Szenarien ziemlich interessant ist.

Den MS Sql Server kenne ich am wenigsten. Bei mir hatte der immer irgendwelche Macken, wobei das wahrscheinlich am Benutzer und nicht an der Software selbst lag :)

Wirklich auffallen tun die Unterschiede aber nur bei riesigen Datenmengen. Da kann es dann z.B. sein, dass Oracle oder der SQL Server automatisch einen sehr guten Queryplan verwenden, waehrend du bei Firebird eventuell die Abfrage umschreiben musst.

NoSql Datenbanken wie MongoDB wuerde ich mich bei businesskritischen Anwendung eher nicht einsetzen. Wobe ich clusterfaehige Datenbanken wie Cockroach schon interessant finde. Aber gerade bei Geschaeftsdaten sollte man lieber auf Altbewaehrtes setzen, finde ich.

[Ghostwalker]

Zitat:

Zitat von delphirocks (Beitrag 1366709)

NoSql Datenbanken wie MongoDB wuerde ich mich bei businesskritischen Anwendung eher nicht einsetzen. Wobe ich clusterfaehige Datenbanken wie Cockroach schon interessant finde. Aber gerade bei Geschaeftsdaten sollte man lieber auf Altbewaehrtes setzen, finde ich.

Warum ? Gerade hier zeigen sich die Stärken von NoSQL-DB's (Thema: Big Data). Und wird auch bereits eingesetzt (z.B. GitHub). Die Clusterfähigkeit ist hierbei meist direkt in der DB-Server-Software integriert (auch MongoDB soweit ich weiß) und läuft recht stabil und zuverlässig. Bei MySQL z.B. benötigt man hier eine (recht teure) Software um sowas zu realisieren und läuft soweit ich weiß auch nicht wirklich stabil.

Bei der Frage welche Datenbank benutzt werden soll, sollte man sich, denk ich, erstmal ein paar Eckpunkte überlegen:

- Welche Datenmengen kommen zusammen ?
- Wieviele User sollen darauf zugreifen ?
- Wird eine Volltextsuche benötigt ?
- Wie ist die Struktur der Daten ? (einheitlich fixe Struktur oder doch eher unteschiedlich, evtl. Dokumente)
- Was darf das ganze (Software+Hardware) kosten ?
- Welche Software soll auf die DB zugreifen können ? (evtl. unterschiedliche Programmiersprachen im Einsatz)

[Thomas Feichtner]

Hier nochmals einige Eckpunkte:
Wir haben ein ERP-Programm und eine Campingplatzverwaltung. Das sind Fat Client Programme.
Außerdem greift ein weiters Programm (Xml-Server) darauf zu. Dieser läuft als Dienst und ist für Zugriffe z.B. für WebApp's, Importprogramme, Webshops, usw im Einsatz.

- Welche Datenmengen kommen zusammen ?
-> Hier kann die Positionstabelle von den Geschäftsfällen schon mal bis zu 5 GB haben.
-> Eine weiter Tabelle zwar von den Spalten her klein, aber hier werden Dokumente gespeicherte kann schon mal 60 oder mehr GB haben.

- Wieviele User sollen darauf zugreifen ?
-> Je nach Kunde von 1 bis zu 100 Usern

- Wird eine Volltextsuche benötigt ?
-> ja hatten wir bisher mit unserem ADS im Einsatz und möchte ich eigentlich nicht missen.

- Wie ist die Struktur der Daten ? (einheitlich fixe Struktur oder doch eher unteschiedlich, evtl. Dokumente)
-> Die Struktur ist bei den Kunden zu 85% gleich, jedoch hat jeder Kunde meistens noch individuelle Felder -> also keine fixe Struktur!

- Was darf das ganze (Software+Hardware) kosten ?
-> Bisher haben wir für die DB pro User ca. 160,00 verlangt
-> Die Softwarekosten hängt natürlich vom Produkt und anzahl der Arbeitsplätze ab. Da kann es zwischen 2000,00 und 70.000,00 ausmachen

- Welche Software soll auf die DB zugreifen können ? (evtl. unterschiedliche Programmiersprachen im Einsatz)
-> Wie schon gesagt unser ERP bzw. Campingplatzverwaltung (beides Fat Clients) und unser Xml-Server (kann man sich als REST-Server vorstellen).
-> Programmiersprache wird Delphi bleiben. Jedoch wer weiß was in ein paar Jahren kommt. Wobei hier man wahrscheinlich dann einen N-Tier Programm macht.

- Datensicherung
-> Bisher benötigte man einen exclusiven Zugriff oder man erstellte ein Backup

[mkinzler]

Sollte problemlos mit beiden der DBMS funktionieren.
Fulltext gibt es bei FireBird nur mit Zusatzprodukten oder händisch.
Für die Dokumente wiederum wäre FireBird besser geeignet.

[delphirocks]

Zum Thema NoSQL: es kommt immer darauf an, was genau man damit abbilden will. Aber ich nehm' mal an, dass die Daten wichtig sind, konsistent sein muessen und nicht verlorengehen duerfen. Dann wuerde ich zumindest von MongoDB die Finger lassen.

Einer meiner Freunde hat mit seiner Firma auf CouchDB gesetzt, weil da das Feature der Synchronsation mit mobilen Geraeten bereits eingebaut war. Das Ergebnis war, dass die Performance hinten und vorne nicht gepasst hat und sich CouchDB als Mega Kruecke herausgestellt hat. Die sind dann auf Postgres zurueck, was mit einem Riesenaufwand verbunden war.

Anonsten sieh dir einfach an, wie gut der Support fuer die Datenbank ist. Also z.B. wieviele Buecher usw. du auf Amazon zu dem Thema findest - auch was z.B. High Availability usw. anbelangt.

Ich wuerde auf Postgres oder wenn's fuer den Kunden moeglichst einfach sein soll, auf MySql/MariaDB setzen.

[jobo]

Zitat:

Zitat von mkinzler (Beitrag 1366721)

..
Für die Dokumente wiederum wäre FireBird besser geeignet.

Interessant! Was macht Firebird da?

[jobo]

Zitat:

Zitat von Thomas Feichtner (Beitrag 1366718)

Hier nochmals einige Eckpunkte:..

Das sieht relativ harmlos aus. ERP spricht m.E. eher gegen nosql Varianten.

Was die Programm Landschaft angeht sehe ich derzeit 3 Programme, also Clients aus Perspektive der DB. Mit einer Neuentwicklung (n tier) wären es 4.
Würden die alle auf einen Server zugreifen oder wäre ein Server nur für die Datenhaltung einer Anwendung zuständig? Es sieht nach heterogener App Landschaft aus oder?

Praxis:
Wie wäre es, wenn du einfach mal einen Test machst.
Ein Datenbankserver oder 2 (Firebird und Postgres) ist schnell aufgesetzt. (am schnellsten als VM)
Datenexport per SQL soll ADS ja können.
Zunächst nur die Scripte des Datenmodell.
Das dann auf den neuen Servern einspielen und erstmal einfach Fehler zählen / beheben, solange bis alle Tabellen da sind. Dann Daten einspielen.

Alternativ das ganze mit dem Tool / Scripten, mit denen Ihr Euer System selbst aufsetzt.

Man kann lange und viel suchen, recherchieren, die Praxis ist meist recht individuell. Könnte mir vorstellen, dass es sehr hilfreich ist.
Selbst wenn Ihr Euch am Ende natürlich gegen ein oder mehrere Systeme entscheidet, sammelt ihr sicher wertvolle Erfahrungen. Ist also m.E. erstmal kein rausgeworfenes Geld.

[mkinzler]

Zitat:

Zitat von jobo (Beitrag 1366750)

Zitat:

Zitat von mkinzler (Beitrag 1366721)

..
Für die Dokumente wiederum wäre FireBird besser geeignet.

Interessant! Was macht Firebird da?

Blobs werden in einem eigenen Bereich der Datenbank gespeichert. Ihre Größe ist nicht beschränkt.

[p80286]

Zitat:

Zitat von mkinzler (Beitrag 1366761)

Zitat:

Zitat von jobo (Beitrag 1366750)

Zitat:

Zitat von mkinzler (Beitrag 1366721)

..
Für die Dokumente wiederum wäre FireBird besser geeignet.

Interessant! Was macht Firebird da?

Blobs werden in einem eigenen Bereich der Datenbank gespeichert. Ihre Größe ist nicht beschränkt.

da hat mir ein Kollege über die Schulter geschaut, "Da gibt's doch keinen Unterschied!?" Interessant wenn zwei Personen das gleiche sagen, aber etwas unterschiedliches meinen!

Gruß
K-H

[jobo]

Zitat:

Zitat von p80286 (Beitrag 1366773)

Interessant wenn zwei Personen das gleiche sagen, aber etwas unterschiedliches meinen!

Oder wenn es sogar 3 Meinungen gibt!
;)
In Pg gibt es 3 Varianten sogenannte BLOBS zu speichern.
1 Type Text speichert BLOBS bspw mime codiert in der Tabelle
2 Type ByteA speichert uncodiert, Daten werden mit Fetch gemeinsam geholt, max value size 1GB
3 Type OID (Large Objects) uncodiert, gespeichert in Chunks in einer Systemtabelle, max value size 2Gb

Wir arbeiten idR mit 1 oder 2, komfortabel ist der mime codierte Export, sprich Transport von Dateien per Text Insert, Update, Delete
3 nutzen wir nicht, Zugriff per Streaming.

Wie sich das in der praktischen Nutzung bemerkbar macht/unterscheidet kann ich nicht sagen. Variante 1 hat natürlich durch das codieren einen Overhead.

[mkinzler]

Bei Firebird läuft die Erkennung automatisch. Wenig Daten Tabelle sonst nur Zeiger in Datensatz. Es können auch dateien > 2 GB gespeichert werden.

[jobo]

Ich hab noch mal nachgeschaut die Doku sagt, ab Version 9.3 geht der Large Object Type bis 4TB. Kommt offenbar auch darauf an, ob man eine 32bit Version oder eine 64bit Version am Start hat, das betrifft ggF. auch den Client, wo der Large Object Type explicit für Streaming Zugriff, also Teilzugriff, gemacht ist.
Hab damit aber keine Erfahrung, 2Gb ist schon ein komplettes Betriebssystem. Vielleicht ist es wichtig für Video Streaming oder was weiß ich.

[mkinzler]

Vielleicht ist es wichtig für Video Streaming oder was weiß ich.

Zitat:

MTV verwendet lt. Aussage von IBExpert Firebird-Server.

[tsteinmaurer]

@bra:

Zitat:

Ich sehe das ja auch genauso, Firebird ist in der Hinsicht halt deutlich im Nachteil, weil der bei einer langsamen Festplatte in die Knie geht, weil er fast nichts cacht.

Vielleicht ohne Basis-Tuning (Default-Settings), aber man kann Firebird sehr wohl dazu bringen mehr RAM zu verwenden. Und dann ist ja auch noch der OS File System Cache ...

[frapo]

Zitat:

Zitat von p80286 (Beitrag 1366249)

(Wenn ich so lese wie zickig sich MySQL anstellen kann, würde ich es nicht in Betracht ziehen, aber wahrscheinlich kenn ich nur die 10 unzufriedenen, die restlichen 999999999990 sind vollauf zufrieden.)

Diese "Information" solltest du unbedingt Google und FB zukommen lassen. Die arbeiten schließlich damit und sind sicher dankbar für einen Wink ;)

Zum Thema und damit zu den Anforderungen des TE:
Wenn es darum geht Kosten zu sparen, ist MariaDB sicher eine überlegenswerte Variante. Bietet alles was du dir erwartest und kostet nichts(im Gegensatz zu MySQL). Außerdem, aufgrund dessen das MariaDB ein Fork von MySQL ist, gibt es sehr viele Info im Netz dazu.

[mkinzler]

https://www.heise.de/newsticker/meld...0-3679285.html

[Thomas Feichtner]

Welchen Bekanntheitsgrad haben die Datenbanken bei den Administratoren / Kunden?
Oracle und MSSQL ist glaube ich jeden bekannt. Wie sieht es da mit Postgres bzw. Firebird aus?

Weiter oben haben wir bezüglich einer Zwischenschicht gesprochen. Dazu hat es glaube ich hier mal ein Projekt dazu gegeben. Leider finde ich den Beitrag nicht mehr.

[jobo]

Zitat:

Zitat von Thomas Feichtner (Beitrag 1367267)

Welchen Bekanntheitsgrad haben die Datenbanken bei den Administratoren / Kunden?
Oracle und MSSQL ist glaube ich jeden bekannt. Wie sieht es da mit Postgres bzw. Firebird aus?

Schwierige Frage, bzw. was bringt Dir der "Bekanntheitsgrad" bei Admins / Kunden.

Ich würde mal die These aufstellen, dass unter Entwicklern wie hier der Bekanntheitsgrad der genannten und anderer DB relativ hoch ist, vlt > 70, 80, 90 %

Bei Admins einer x beliebigen Firma geringer, die kümmern sich um das Zeug was da ist (und haben max. noch einen Nebenauftrag, mal mit einem Auge nach Alternativen zu schielen)
> 40 -70%

Bei "Kunden".. Geschäftsführer? Einkauf? Anwendern?
Denen ist es glaub ich letztlich schnuppe. Vlt gibt oder gäbe man gern an mit "Wir arbeiten in 4/5 Abteilungen mit SAP", dass da im Zweifel dann Oracle drunter liegt, who cares? Die Leute müssen andere Sachen wissen.

So und dann nützt dieser Bekanntheitsgrad was? Ein Admin der Oracle kennt, hat erstmal kein Plan, wie es zu administrieren ist. Und wird er wahrscheinlich auch nicht freiwillig machen ohne Schulung. * Oft werden in dem Bereich ja schon wieder Dienstleister eingesetzt die den Mist am Fliegen halten.

Also wenn Du eine gute Antwort auf den Bekanntheitsgrad und das was Du vielleicht eigentlich wissen willst, haben möchtest, schau mal im Netz, wieviel professionelle Dienstleister Du findest, die Dir Support für Deine Systeme anbieten, denn dort werden am Ende die Kunden landen, die Dein Datenbanksystem einsetzen und nicht mehr weiter wissen.

Ach und "Zwischenschicht"
Ist schön, wenn sie universell, für alle Anwendungen gleich eingesetzt wird. Also z.B. für Neuentwicklung, in heterogenen Systemen finde ich das schwierig. Hatte ich aber glaub ich schon geschrieben.



* (Analog bei anderen DB Systemen, aber Oracle ist ja berühmt für seinen Wartungsbedarf- was ich nebenbei für unsachlich halte, es bietet eine Menge Möglichkeiten für verschiedenste Anforderungen. Viel Möglichkeit gibt auch Gelegenheit für viele Fragen und Fehler- nur mal so am Rande)

[Bernhard Geyer]

Zitat:

Zitat von jobo (Beitrag 1367288)

Zitat:

Zitat von Thomas Feichtner (Beitrag 1367267)

Welchen Bekanntheitsgrad haben die Datenbanken bei den Administratoren / Kunden?
Oracle und MSSQL ist glaube ich jeden bekannt. Wie sieht es da mit Postgres bzw. Firebird aus?

Schwierige Frage, bzw. was bringt Dir der "Bekanntheitsgrad" bei Admins / Kunden.

Aus unserer Erfahrung ist das Unterstützen eines der "üblichen Verdächtigen" ein Punkt der im Aquiseprozess die Arbeit erleichtert.
Könnte in einem engen Rennen zwischen der eigenen Lösung und einem Mitbewerber der entscheidende Faktor sein.

Ebenfalls hat man im Bereich Administration, Backupkonzept und ähnliches (fast) keine Aufwände,
da (bei vielen Kunden) auf eine bestehende Lösung zurückgriffen werden kann.

Ebenfalls kannst du nicht für irgendwelche Probleme verantwortlich gemacht werden ("Sie haben doch hier auf dem Server eine SW-Installiert. Wir haben jetzt Probleme mit ..." (egal was, man hat was installiert, damit ist man erstmal ein Ansprechpartner für alles mögliche)) weil du auf dem Server eine Installation vorraussetzt.

Möchte nicht wissen wie hoch der Supportaufwand in diesem Bereich wäre, wenn wir die Platzhirschen nicht unterstützten würden.
Es reicht schon das bei manchen Kunden es zwar Oracle-Admins gibt, diese aber das Motto "Egal was ist, die Anwendung ist schuld" verfolgen.

[jobo]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1367305)

Zitat:

Schwierige Frage, bzw. was bringt Dir der "Bekanntheitsgrad" bei Admins / Kunden.

Aus unserer Erfahrung ist das Unterstützen eines der "üblichen Verdächtigen" ein Punkt der im Aquiseprozess die Arbeit erleichtert.
Könnte in einem engen Rennen zwischen der eigenen Lösung und einem Mitbewerber der entscheidende Faktor sein.
..

Gute Argumente, kann ich aus Erfahrung nachvollziehen.

Ich sehe hier in dem Fall dennoch das "Problem", dass es nicht um die Frage "welche DB Systeme unterstützen wir denn alle" geht, sondern um "welche eine von den möglichen nehmen wir denn, fest".

Die Entscheidung für eine, ist dann immer die Entscheidung gegen ~5 andere und zieht auch die von Dir angeführte Marketingsituation nach sich.

Ich sehe in der Situation hier zunächst die Frage, was brauche ich alles. Als erstes müsste man sich da m.E. um die auch von Dir aufgeworfene Frage kümmern, Mehrschicht oder CS System.
Mehrschicht bedeutet m.E. DB als "dumme Datenhaltung", folglich DB egal und die Frage, was die Kunden kennen und "mögen" auch egal.
CS System bedeutet allerdings auch nicht, dass man DB spezifsche Funktionen einsetzt, aber darüber muss man auch nur nachdenken, wenn man CS will (vielleicht gerade weil man für ERP, .. spezielle Anforderungen hat)

[p80286]

Zitat:

Zitat von jobo (Beitrag 1367314)

Die Entscheidung für eine, ist dann immer die Entscheidung gegen ~5 andere und zieht auch die von Dir angeführte Marketingsituation nach sich.

Diese Entscheidung sollte man nicht treffen. Auch wenn sich die letzte "Meile zur DB" unterscheidet (SQL-Dialekt) so ist doch die Schnittmenge der Dialekte um so größer je "dümmer" die DB ist. Und ich habe schon mehr als einen Anbieter erlebt, der mit MS-Code auf eine Oracle-DB gegangen ist und umgekehrt.
Solange es richtig läuft, halte ich es für falsch eine oder mehrere DB auszuschließen.

Gruß
K-H

[Bernhard Geyer]

Zitat:

Zitat von p80286 (Beitrag 1367325)

Diese Entscheidung sollte man nicht treffen. Auch wenn sich die letzte "Meile zur DB" unterscheidet (SQL-Dialekt) so ist doch die Schnittmenge der Dialekte um so größer je "dümmer" die DB ist. Und ich habe schon mehr als einen Anbieter erlebt, der mit MS-Code auf eine Oracle-DB gegangen ist und umgekehrt.
Solange es richtig läuft, halte ich es für falsch eine oder mehrere DB auszuschließen.

Mittlerweile kann ja selbst Oracle ANSI-JOINs aufbauen und mann muss nicht mehr mit der besch*** +-Logik sich rumärgern.

Bei uns ist die DB-Spezielle Schicht auch relativ klein. MySQL und Oracle laufen mittlerweile auch über UniDac und unterscheide sich fast nur noch bei den Table/Index-Create-Statements.

[jobo]

"Die Eine oder Viele"
Nun, der TE will ja scheinbar eine DB auswählen oder muss diese Entscheidung treffen.

Erstmal nur "eine" zu nehmen, ist ja auch kein unumstößliche Entscheidung, hat wahrscheinlich primär Kostengründe.

Für mich ist die Entscheidung eine/viele dann am Ende nicht so spannend, solange es um SQL Dialekt geht. Ein bisschen SQL Code verdrehen kann man ja tatsächlich auf der "letzten Meile".

Viel entscheidender ist für mich die Frage der DB Fähigkeiten jenseits von ANSI SQL.
Also
Geodatentypen und andere, z.B. eigene
Volltext Suche
Index Varianten
JSON / XML embedded
Connectivity / Remote DB / Linked Server
Partitionierung
Replikation
um mal ein paar zu nennen

Dann gibt es noch Dinge, die eine DB kann und außerhalb meines Interesses liegen.

Nutze ich spezifische Datenbankfunktionen, dann ist das natürlich eine starke Bindung an dieses Produkt. Aber:
Summa Sumarum kann ich für bestimmte Eigenprodukte sagen, Oracle oder Postgres ist mir egal, obwohl es um CS Systeme geht, die intensiven Gebrauch machen von spezifischer Datenbankfunktionalität, bspw. SEPA File Erzeugung oder Verarbeitung per SQL.
Damit kann ich dann beliebige heterogene Anwendungs-Landschaften für mein Produkt bedienen und die DB bleibt von alleine sauber.

Alternativ kann ich daraus auch ne Art Premium Marketing machen.

• Das Produkt gibt es in der Community Edition oder LowCost mit SQLite, dafür kann es bestimmte Dinge dann nicht
• Für KMU biete ich eine kostengünstige, leistungsfähigere Version mit PG oder Firebird mit einigen Zusatzfunktionen
• Und Enterprise dann mit ERP Funktion und Schnickschnack gegen MSSQL oder Oracle.

[p80286]

[OT]

Zitat:

Zitat von jobo (Beitrag 1367353)

Summa Sumarum kann ich für bestimmte Eigenprodukte sagen, Oracle oder Postgres ist mir egal,

Mit anderen Worten beide fühlen sich gleich an (DDL,SQL)?
Da ich bisher Beruf (Oracle/Mssql) und privat (FB) getrennt hatte, wäre es ganz gut wenn ich da etwas zum Spielen hätte, denn Oracle-Lizenzen kann sich ein Privatmann ja nicht leisten.

Gruß
K-H
[/OT]

[mikhal]

Zitat:

Da ich bisher Beruf (Oracle/Mssql) und privat (FB) getrennt hatte, wäre es ganz gut wenn ich da etwas zum Spielen hätte, denn Oracle-Lizenzen kann sich ein Privatmann ja nicht leisten.

Oracle und MSSQL Express wären deine Freunde:

Oracle Express 11g R2

SQL Server 2016 Express

In Leistung und Größe der Datenbank beschnitten, aber sonst die gleichen Funktionalitäten wie die "Großen".

Grüße
Mikhal

[p80286]

Danke!
Bisher waren meine Erfahrungen mit den Expressen sehr beschnitten!

Gruß
K-H

[mikhal]

Du wirst dir in beiden Fällen noch Administrationswerkzeuge organisieren müssen: MS stellt das Monster von Administrationstool zur Verfügung, man benötigt dazu keine Datenbank-Lizenz mehr, bei Oracle empfehle ich den Free Toad, den kleinen freien Bruder. Der muss aber alle 30 oder 60 Tage neu installiert werden, nicht so toll...

SQL Server Management

Free Toad for Oracle

Grüße
Mikhal

[p80286]

Vielen Dank, mal schauen, was dabei ist, und was ich noch benötige, einen klitzekleinen Werkzeugkasten hab ich ja schon.

Gruß
K-H

[mikhal]

Vom SQL Server gibt es auch eine Developer-Version, die ist seit einiger Zeit auch kostenfrei...

SQL Server Developer

Inwieweit Oracle-Datenbanken für Entwicklungszwecke frei verfügbar sind, kann ich jetzt nicht sagen.

Grüße
Mikhal

[jobo]

Zitat:

Zitat von p80286 (Beitrag 1367360)

[OT]

Zitat:

Zitat von jobo (Beitrag 1367353)

Summa Sumarum kann ich für bestimmte Eigenprodukte sagen, Oracle oder Postgres ist mir egal,

Mit anderen Worten beide fühlen sich gleich an (DDL,SQL)?
[/OT]

Ja, wir haben Webanwendungen, die fast 100% identisch auf Ora und PG laufen.
Allerdings mit diversen freien Zusatzpaketen für PG, die extra dafür da sind, es oracle kompatibel zu machen. Kann ich dir auch Links und Infos zukommen lassen bei Interesse.
/ot

Zitat:

Zitat von mikhal (Beitrag 1367376)

Inwieweit Oracle-Datenbanken für Entwicklungszwecke frei verfügbar sind, kann ich jetzt nicht sagen.

Naja die Express Edition ist zwar nicht mehr die aller neueste, aber ne ziemlich vollständige 11er? Version. Glaub da sind sogar Enterprise Features bei. Also mehr braucht man für privat nicht, glaub ich. Das gilt auch für "administration". Ich weiß nicht, wann ich das letzte Mal eine Entwciklerdatenbank (Oracle) administriert habe.
Falls doch was gemacht werden muss, geht es auch per SQL.
Für die Entwicklung kann ich auch PLSQL Developer empfehlen. Das kann auch etwas administrieren, aber es ist primär ein Developer Tool. Gibts als Trial oder relativ günstig als Einzellizenz.