Neue Datenbank

[bernau]

Zitat von Frickler:

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.

[mkinzler]

Noch eine (älterer) Vergleich:

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

[Frickler]

Zitat von bernau:

Zitat von Frickler:

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?

[Bernhard Geyer]

Zitat von 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?

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 von 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?

• 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 von 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?

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.