Ist Oracle noch der Platzhirsch oder Schnee von Gestern?

[Elvis]

FileMaker ist wohl eigentlich sowas wie Access (GUI + DB-File, rel. einfach zu bedienen), als Server ist das ziemlich sinnlos.
Man kann fast nix konfigurieren (zum Beispiel welche Art von Index (Bitmap, B-Tree, B-Tree Cluster, Hash Cluster, ..., wie partitioniert, wie auf verschiedenen HDD-Arrays abgelegt wird)
Ohne vernünftige Index-Möglishkeiten kann man gleich ebenso einfach gestrickte Engines wie Firebird oder MySql nehmen, kosten wohl weniger, aber sind verbreiter.

[blondervolker]

Und absolut nicht zu vergessen,dass ich persönlich einige Firmeninhaber kenne,die die Kosten so niedrig wie möglich halten möchten.
Denn aber kommen einige leider garnicht mehr weiter und geben sogar mal
Geld aus. Siehe Filemaker-Magazin...

[Privateer3000]

Preiswert kann man FM nicht nennen, das ist klar.
Da werden sogar die Custom Scripte verkauft.
Aber Acess schlägt IMO trotzdem, dafür sorgt die
wirklich gute GUI, seit der FM12 erst recht.
An die Robustheit von Oracle kommt keine mir bekannte DB heran.
Jedenfalls mit meinen bescheidenen Kenntnissen.

Aber anders gefragt, wer käme als Konkurrent infrage?
Und was ist tatsächlich Schnee von gestern.
Grüße

[Furtbichler]

Filemaker gehört nicht hierher. Wir reden von echten Enterprise-RDBMS, wobei ich Respekt vor dem Buchladen habe, aber ihn nicht zu 'Enterprise' zähle. Normalerweise lasse ich Diskussionen freien Lauf, aber ich würde als Fragesteller lieber bei den RDBMS bleiben.

Mittlerweile muss ich MSSQL, Oracle und Firebird bewerten bzw. erklären, warum das allesamt brauchbare RDBMS sind. Inzwischen weiß ich (dank des Threads), das Oracle zwar altbacken und behäbig in Punkto Wartbarkeit und Administrierung ist, aber performancetechnisch immer noch gut genug für die vorderen Plätze.

MSSQL ist eh mein Lieblingssystem (weil ich es so lange kenne, aber andere sind auch super z.B. PostGres). Teuer, tolle Tools, kann vieles und ich kann mit C# neue Funktionen einbauen. Das geht auch bei Oracle und Firebird, nur nicht mit C#

Und Firebird wird wohl von der Buchhaltung verwendet. Denen wurde erzählt, das Firebird proprietär wäre (WOT?) und ganz ganz schlecht. Das Einzige, was ich dazu weiß ist, das das SYSDBA-Kennwort nicht gerade sicher ist(da gibt es wohl einen Thread hier), aber für 200-300 User komplett ausreichend ist. Dafür ist es echt schnell, klein, wartungsarm, millionenfach im Einsatz usw. Nachteile? Kein VT, keine Spezialindexe usw. Also genau das Richtige, weil ausreichend für die Buchhaltung.

Bei Firebird habe ich brauchbare White Paper und Case Studies gelesen, sodaß ich mir ein ganz gutes Bild machen kann.

[jobo]

Zitat von Furtbichler:

MSSQL ist eh mein Lieblingssystem (weil ich es so lange kenne, aber andere sind auch super z.B. PostGres). Teuer, tolle Tools, kann vieles und ich kann mit C# neue Funktionen einbauen. Das geht auch bei Oracle und Firebird, nur nicht mit C#

Ich hab's noch nie benutzt, aber es gibt schon seit einiger Zeit (oracle db server 10?) die .Net Extensions für Oracle, die glaub ich direkt in VS integrieren.
Damit kann man auch C# usw (wmgl. alles was in .Net/nach CLR geht) stored procs für Oracle bauen und in der DB ansprechen.
http://docs.oracle.com/cd/E17666_01/...7405/intro.htm

Ob's was taugt, weiß ich nicht.

[Furtbichler]

Das ist ja nicht das Problem (Integration in VS). Bisher habe ich einen Layer gebaut und seitdem ich neuerdings DevExpress einsetze, ist auch hier das Serverthema gegessen.

Das Problem ist nicht, wie ich mit den RDBMS arbeiten soll, sondern daß ich der Geschäftsleitung vermitteln muss, das alles ok ist und sie keine ollen Kamellen im Schrank haben. Das hat ihnen nämlich vor einem Jahr eine Torfnase erzählt und das hat sich nun festgebissen.

[jobo]

Ich wollte lediglich anmerken, dass man entgegen deiner Aussage auch in Oracle C# Stored Procedures einnsetzten kann.
Da es hier auch um Schulungsaufwand etc, pp. ging, könnte man an der Stelle die Lernkurve für C# Freaks stark abflachen.

Was Dein zuletzt genanntes Problem angeht: "schlechte Presse" ist immer schlecht. Da kommt man erfahrungsgemäß als Externer/Dienstleister auch schlecht mit klar. Die IT des Kunden zeigt idR. wenig Bereitschaft geschweige Enthusiasmus für ein Fremdprodukt (außer es ist SAP ). Und sobald ein Externer im Boot ist, hat man halt jemand, wo man draufhauen kann. (Was ja manchmal der Hauptanwendungsfall für den Einsatz von Dienstleistern ist)
Was da an "Argumenten" geliefert wird, ist meist nicht rational. Eine "schlechte Software" ist da eher das Ventil.

Letztlich ist es eine Strategiefrage. Setze ich ein RDBMS als Blackbox ein und vernachlässige damit einen guten Teil der spezifischen Funktionen (Die dann bspw. mittels einer 3.Schicht nachimplemntiert werden müssen) oder lege ich mich auf ein spezifisches Produkt fest und ziehe dort alle Register.

Wenn ich also einen Ferrari brauche, nehme ich dann lieber ein paar Fiat 500, weil die Techniker billiger sind?
Wenn ich bereits den Ferrari habe, fahre ich mit dem Ding dann lieber mit dem Autozug von Dortmund nach Berlin, weil ja , weiß auch nicht..