expertenaustausch > comp.lang.* > comp.lang.php.datenbanken

Andreas Korthaus (24.07.2003, 15:31)
Hallo!

Unter steht, dass PHP neben
ODBC auch IBMs DB2 unterstützt. Heißt dass jetzt DB2 nur über die
ODBC-Schnittstelle, oder gibt es eine eigene API? Ich habe ein bisschen
gesucht, aber nichts derartiges gefunden. Zumal es unter
noch extra
Konfigurations-Parameter gibt - wofür? Ich finde weder im deutschen noch im
englischen Manual irgendwas dazu. Und auch bei google finde ich nur ODBC
Zugriffe.

Wenn es das nicht gibt, welche DB würdet Ihr für einen professionellen
Einsatz in einer B2B-Software basierend auf PHP empfehlen? Oracle ist schon
recht teuer(außerdem habe ich schon viel schlechtes über die API von PHP
gehört), aber was gibt es da noch außer DB2? Microsoft SQL-Server scheidet
auch aus da die Anwendung unter Unix läuft, MySQL ist ja noch nicht wirklich
für den professionellen Einsatz geeignet, da fehlen noch einige Features und
die 4er Version ist auch noch recht frisch, außerdem habe ich noch kein so
rechtes Vertrauen in die ja noch recht neuen INNO-DB Treiber. Vielleicht
SAP-DB, oder PostgreSQL? Letzteres verwende ich im Augenblick, nur genießt
PostgreSQL zwar ein hohes Ansehen in der Open-Source Gemeinde, aber bei
vielen Firmen kann man damit keinen Blumentopf gewinnen.
Die für mich wichtigsten Maßstäbe sind absolute Datensicherheit
und-Integtität, also Transakktionen, Fremdschlüssel... , sehr hohe
Stabilität und nicht zuletzt eine gute Performance. Und der Preis sollte
nicht gerade auf Oracle-Niveau liegen. Und natürlich eine gute Unterstützung
für Linux und eine gute Schnittstelle für PHP.

Was könnt Ihr da aus Eurer Erfahrung sagen? Oder kann PostgreSQL inzwischen
auch mit den großen wie DB2 und Oracle mithalten? Wohle eher nicht, oder?

Und noch eine Frage, ich habe immer viel mit PEAR DB gearbeitet, weil das
doch recht praktisch ist da die Anwendung mit MySQL entwickelt wurde und
inzwischen mit PostgreSQL läuft. Nur ist PEAR DB ja bekanntlich nicht gerade
schnell und eigentlich viel zu komplex, würdet Ihr einen anderen
DB-abstraktions-Layer empfehlen, oder würdet Ihr Euch einen eigenen
schreiben(was ich zur Zeit vorhabe)? Denn das direkte Verwenden
spezifischen Funktionen läßt eigentlich kein vernünftiges globales
Error-Handling zu, und auch bei der Umstellung auf ein anderes DBMS würde
einen sehr hohen Aufwand bedeuten.

Viele Grüße
Andreas
Niels Braczek (24.07.2003, 15:46)
Andreas Korthaus <akorthaus> schrieb:

> MySQL ist ja noch nicht wirklich für den professionellen Einsatz
> geeignet, da fehlen noch einige Features und die 4er Version ist
> auch noch recht frisch, außerdem habe ich noch kein so rechtes
> Vertrauen in die ja noch recht neuen INNO-DB Treiber.


Warum sollte MySQL nicht professionellen Ansprüchen genügen? Ich schätze
mal, dass es kein RDBMS gibt, das derart ausgiebig unter sämtlichen
Lastverhältnissen erprobt wurde wie MySQL.

> Die für mich wichtigsten Maßstäbe sind absolute Datensicherheit
> und-Integtität, also Transakktionen, Fremdschlüssel... , sehr hohe
> Stabilität und nicht zuletzt eine gute Performance. Und der Preis
> sollte nicht gerade auf Oracle-Niveau liegen. Und natürlich eine gute
> Unterstützung für Linux und eine gute Schnittstelle für PHP.


Du beschreibst MySQL.



MfG
Niels
Andreas Korthaus (24.07.2003, 17:01)
Hi!

Niels Braczek wrote:
> Warum sollte MySQL nicht professionellen Ansprüchen genügen?

Ich würde mal behaupten dass sicherlich über 99% der MySQL-Installationen
keine besonders ktitischen Daten verwalten. Sicher verwendet Nasa,
Mobile.de... MySQL, aber die verwenden nicht nur MySQL, für kritische
Bereiche werden andere DBMS verwendet. So ist das auch bei den meisten
providern die im Shared-Hosting fast alle MySQL verwenden, aber intern wird
meist was anderes verwendet, entweder PostgreSQL oder was komerzielles.

> Ich
> schätze mal, dass es kein RDBMS gibt, das derart ausgiebig unter
> sämtlichen Lastverhältnissen erprobt wurde wie MySQL.


Zum einen glaube ich das nicht, ich denke Oracle & Co. werden dem in nichts
nachstehen, eher im Gegenteil, außerdem sind das qualitativ andere Tests.
Wenn ich nur viele verhältnismäßig unwichtige Daten hätte wie mobile.de...,
dann wäre das sicherlich eine Überlegung wert, aber für den Umgang mit
hochsensiblen Daten weiß ich nicht pb ich den INNO-DB Treibern von MySQl
unbedingt 100%ig vertrauen würde. Wie gesagt, die sind ja noch gar nicht so
lange dabei, können also nicht so ausgetestet sein wie eine Software die
sich seit je her auf sowas konzentriert hat.

Ich verwende MySQL oft und durchaus gerne, weil MySQL wirklich sehr
unkompliziert und sehr gut dokumentiert ist, aber die frühere Fokussierung
auf reine Lese-Performance, fehlende Kompatibilität zu ANSI SQL92, keine
Subselects und überhaupt die IMHO zu hohe Entwicklungsgeschwindigkeit
sprechen wie ich finde nicht gerade für die zuverlässigste Software in
diesem Umfeld. Oder so Sätze im MySQL-Manual wie: " Die
Transaktionsunterstützung in MySQL ist noch nicht so gut getestet wie das
System von
PostgreSQL"()
sprechen da wohl eine sehr deutliche Sprache. Sicher, das ist alles
verbessert worden, trotzdem ist es noch viel zu jung um mit der
Zuverlässigkeit komerzieller RDBMS mithalten zu können. Auch so Aussagen
dass Fremdschlüssel ja nicht so gut wären da man damit viel Mist machen
könnte... das alles bestärkt nicht wirklich mein Vertrauen sensible
Anwendungen auf MySQL basieren zu lassen. Aber das ist ja auch klar, dafür
war MySQL schlicht nicht gedacht, man hat gemerkt dass man da große Defizite
hatte und hat mit den INNO-DB Treiben einige der fehlenden Features
nachgereicht, nur wie ich schon sagte, zum einen fehlt da noch einiges,
außerdem fehlen einfach genügend Erkenntnisse über die Stabilität der noch
recht neuen Features, denn gerade _diese_ werde so gut wie nie eingesetzt,
denn die meisten MySQL-Installationen sind entweder von vornherein ohne
INNO-DB Treiber(da viele Provider hier Performance-Engpässe befürchten), und
sonst verwenden die meisten einfach MyISAM-Treiber, da sie diese Features
nicht benötigen und/oder nicht kennen. Also sind gerade die Dinge die mir
wichtig wären eben _nicht_ besonders erprobt. Ich weiß auch dass dies bei
PostgreSQL anders ist, da gibts diese Dinge schon _erheblich_ länger, und
bei PostreSQL werden die auch viel mehr eingesetzt, eigentlich fast immer.
Aber trotzdem bin ich mir selbst hier nicht sicher ob PostreSQL mit
komerziellen Produkten mithalten kann, ich denke ADABAS und SAP DB haben
andere Schwerpunkte, sind aber nicht unbedingt besser geeignet, aber gerade
Oracle und IBM beschäftigen sehr viele Entwickler die an Ihren DBMS sitzen,
und diese werden schon seit je her auch in ganz anderen Anwendungsbereichen
eingesetzt, nämlich immer dann wen es kritisch wird, und ein Datenverlust
oder Fehler teuer wüde. Der Vorteil von DB2 ist, dass es eigentlich gar
nicht so teuer ist, und die paar EUR hast Du mehrfach wieder raus wenn Du
mit MySQL oder PostgreSQL ein Problem hast, was Du mit DB2 nicht gehabt
hättest. Wenn irgendeine Dynamische Webseite oder ein Forum kurzzeitig nicht
richtig funktionieren ist das relativ egal, aber bei Business-Anwendungen
kann so ein Ausfall oder ein Problem mit der DB _richtig_ Geld kosten, das
ist auch der Grund warum große Online-Shops oder irgenwelche großen
Marktplätze kein MySQL oder PostgreSQL verwenden, sondern Oracle & Co.

Viele Grüße
Andreas
Markus Brinkmann (24.07.2003, 21:47)
Andreas Korthaus wrote:

> Unter steht, dass PHP
> neben ODBC auch IBMs DB2 unterstützt. Heißt dass jetzt DB2 nur über die
> ODBC-Schnittstelle, oder gibt es eine eigene API? Ich habe ein bisschen
> gesucht, aber nichts derartiges gefunden. Zumal es unter
> noch extra
> Konfigurations-Parameter gibt - wofür? Ich finde weder im deutschen
> noch im englischen Manual irgendwas dazu. Und auch bei google finde ich
> nur ODBC Zugriffe.


Bei dem Zugriff von PHP auf eine IBM DB2 Datenbank dienen die ODBC
Funktionen nur als Schnittstelle (man könnte auch sagen API). Hinter den
Funktionen steht dierekt das CLI (Command Line Interface) der Datenbank.
Es wird kein ODBC benutzt, es ist eine native Implementation.

In der Firma, bei der ich arbeite haben wir eine IBM DB2 mit PHP zusammen
im Einsatz. Bis auf einen kleinen Fehler in der Implementation der
Schnittstelle, den ich im PHP Code beheben konnte haben wir damit gute
Erfahrungen gemacht. Allerdings benutzen wir _keine_ besonderen features
wie z.B. callable statements, stored procedures oder blobs.

Ob Du eine kommerzielle Datenbank benötigst hängt ganz vom Anwendungsfall
ab. Wenn der deren features die Implementation wesentlich vereinfachen
ist es sicher sinnvoll, ansonsten wohl eher nicht. Um für besondere
Datensicherheit zu sorgen ist allerdings wohl eher ein gutes
Backupkonzept ausschlaggebend. Die Datenbank spielt da wohl eine eher
untergeordnete Rolle.

Bis dann ...

Markus Brinkmann
Andreas Korthaus (24.07.2003, 23:10)
Hallo!

Markus Brinkmann wrote:
> Bei dem Zugriff von PHP auf eine IBM DB2 Datenbank dienen die ODBC
> Funktionen nur als Schnittstelle (man könnte auch sagen API). Hinter
> den Funktionen steht dierekt das CLI (Command Line Interface) der
> Datenbank. Es wird kein ODBC benutzt, es ist eine native
> Implementation.

OK, das ist natürlich was anders. Aber wieso keine eigenen Funktionen?
Hättest Du zu dieser Schnittstelle das gleiche Vertrauen wie bei denen zu
MySQL oder PostgreSQL? Ich habe gerade auch gelesen, dass es wohl Leute gibt
die sich eine eigene DB2-Schnittstelle bauen, also aus PHP direkt die
native DB2 CLI aufrufen. Was hälst Du von sowas? Also das komplett selbst zu
implementieren? Oder würde das keinen Vorteil bedeuten? Vermutlich eher eine
Fehlerquelle extra, oder?

> In der Firma, bei der ich arbeite haben wir eine IBM DB2 mit PHP
> zusammen im Einsatz. Bis auf einen kleinen Fehler in der
> Implementation der Schnittstelle, den ich im PHP Code beheben konnte
> haben wir damit gute Erfahrungen gemacht.

Was war das denn für ein Fehler? Ist das irgendwo dokumentiert, bzw. hast Du
das als Bug gemeldet?

> Allerdings benutzen wir
> _keine_ besonderen features wie z.B. callable statements, stored
> procedures oder blobs.

Wenn _Ihr_ keine der besonderen Features verwendet, wieso verwendet Ihr dann
kein freies RDBMS?

> Ob Du eine kommerzielle Datenbank benötigst hängt ganz vom
> Anwendungsfall ab. Wenn der deren features die Implementation
> wesentlich vereinfachen ist es sicher sinnvoll, ansonsten wohl eher
> nicht. Ist das bei Euch der Fall?


> Um für besondere Datensicherheit zu sorgen ist allerdings wohl
> eher ein gutes Backupkonzept ausschlaggebend. Die Datenbank spielt da
> wohl eine eher untergeordnete Rolle.

Klar, aber darum geht es weniger, es gehr darum Daten zu Laufzeit zu
verlieren, oder zum falschen Zeitpunkt nicht zur Verfügung zu sein. Das
schlimmste was passieren kann ist dass bestimmte Daten zu einem bestimmten
Zeitpunkt nicht zur Verfügung stehen, ob jetzt der DB-Server abgestürzt ist,
ob es eine Fehler bei Transaktionen oder irgendwo anders gab...das gäb sehr
viel Ärger und würde vermutlich sehr teuer. Die Wahrscheinlichkeit das
Auftreten eines solchen Fehlers zu minimieren, das ist das Ziel. Und meinst
Du dass es da keinen Unterschied macht ob ich MySQL, PostgreSQL, DB2 oder
Oracle verwende? Dann frage ich mich aber ernsthaft, wieso die Teile so
teuer sind, nur wegen der tollen Tools und erweiterten SQL-Dialekten?

Meinst Du nach Deiner Erfahrung dass DB2 nicht zuverlässiger läuft als
PostgreSQL?

Vielen Dank für die Hilfe!

Grüße
Andreas
Markus Brinkmann (25.07.2003, 00:11)
Andreas Korthaus wrote:

> OK, das ist natürlich was anders. Aber wieso keine eigenen Funktionen?
> Hättest Du zu dieser Schnittstelle das gleiche Vertrauen wie bei denen
> zu MySQL oder PostgreSQL? Ich habe gerade auch gelesen, dass es wohl
> Leute gibt
> die sich eine eigene DB2-Schnittstelle bauen, also aus PHP direkt die
> native DB2 CLI aufrufen. Was hälst Du von sowas? Also das komplett
> selbst zu implementieren? Oder würde das keinen Vorteil bedeuten?
> Vermutlich eher eine Fehlerquelle extra, oder?


Ich denke nicht, dass über die Namen der Funktionen darauf schließen
sollte ob man einer Schnittstelle vertrauen kann oder nicht.
Entscheidend ist sicher die Implementation. Man könnte vielleicht eher
andersrum einen Schuh draus machen. DB2 scheint einigermaßen
Standardkonform zu sein, was das CLI (steht natürlich für Call Level
Interface, und nicht für Command Line Interface wie ich falsch
geschrieben hatte) betrifft, dass scheinbar nur minimale Anpassungen
notwendig waren. Das ist allerding eine reine Spekulation meinerseits.

>> In der Firma, bei der ich arbeite haben wir eine IBM DB2 mit PHP
>> zusammen im Einsatz. Bis auf einen kleinen Fehler in der
>> Implementation der Schnittstelle, den ich im PHP Code beheben konnte
>> haben wir damit gute Erfahrungen gemacht.


> Was war das denn für ein Fehler? Ist das irgendwo dokumentiert, bzw.
> hast Du das als Bug gemeldet?


Der Fehler ist, dass laut Doku nach dem erfolgreichen Ausführen eines
Statements die Funktion odbc_errormsg() einen leeren String enthalten
sollte. Alternativ (die Doku ist an der Stelle nicht ganz eindeutig) den
letzten Fehler der vorher irgendwann aufgetreten ist. Stattdessen bekam
man einen String irgendwo aus dem Heap von PHP zurückgeliefert. Dabei
bekam man als error message Ausschnitte von HTML-Seiten oder Stylesheets
zu sehen. Ich habe diese Stelle insofern behoben, als dass bei einer
erfolgreichen Ausführung dort ein String der nur aus einem nullzeichen
besteht reingeschrieben wurde. Da ich mir über die Konformität dieser
Verfahrensweise nicht im klaren bin, haben wir das dann noch zusätzlich
als Bug eingestellt.



>> Allerdings benutzen wir
>> _keine_ besonderen features wie z.B. callable statements, stored
>> procedures oder blobs.


> Wenn _Ihr_ keine der besonderen Features verwendet, wieso verwendet Ihr
> dann kein freies RDBMS?


Um genau zu sein: Das weiß ich auch nicht! :-) Ich habe das nicht zu
entscheiden. Ich bin der Meinung, dass wir mit einem freien DBMS
genausogut auskommen würden.

[..]
> Unterschied macht ob ich MySQL, PostgreSQL, DB2 oder Oracle verwende?
> Dann frage ich mich aber ernsthaft, wieso die Teile so teuer sind, nur
> wegen der tollen Tools und erweiterten SQL-Dialekten?


Was die Ausfallsicherheit betrifft, kann ich, was freie Datenbanken
betrifft keine Aussage machen, da ich mit denen nur Erfahrungen als
Backend mäßig besuchter Webseiten gemacht habe. Bei der DB2 kam es
bisher zu keinen Ausfällen bei uns, die direkt auf die Datenbank
zurückzuführen waren. Der Umfang einer unserer Tabellen wuchs dabei pro
Monat schonmal um 1 Mio Einträge.

Was die Tools betrifft: Ein phpMyAdmin ist m.E. wesentlich komfortabler
als der Java Mist, der bei DB2 mitgeliefert wird. Die Kommandozeile ist
dort Dein Freund.

Bis dann ...

Markus Brinkmann
Keita Ito (25.07.2003, 13:37)
On Thu, 24 Jul 2003 23:10:22 +0200, Andreas Korthaus wrote:

[ODBC-style für DB2]
>OK, das ist natürlich was anders. Aber wieso keine eigenen Funktionen?


Weil alle Welt nach einheitlichen DB-APIs schreit und sich für die
handvoll DBMSe, die diese extension erfaßt, diese Vorgehensweise als
praktikabel erwiesen hat. In anderen Sprachen ist das ja Gang und
Gäbe, warum also nicht auch bei PHP? :)

greetings, Keita
Andreas Korthaus (25.07.2003, 14:15)
Keita Ito wrote:
>> OK, das ist natürlich was anders. Aber wieso keine eigenen
>> Funktionen?

> Weil alle Welt nach einheitlichen DB-APIs schreit und sich für die
> handvoll DBMSe, die diese extension erfaßt, diese Vorgehensweise als
> praktikabel erwiesen hat. In anderen Sprachen ist das ja Gang und
> Gäbe, warum also nicht auch bei PHP? :)


Weil ich mir denke, dass eine Datenbank-Abstraktion nie so effektiv
funktionieren kann wie eine individuelle API. Das ist einfach der Preis der
Komopatibilität. Oder ist der Zugriff via ODBC genauso performant und stabil
wie über das native CLI? Ich merke das ja z.B. bei PEAR::DB, das macht die
Sache nicht unbedingt schneller und stabiler.
Und wieso wird dann DB2 über dessen CLI angesprochen und nicht über ODBC?

Grüße
Andreas
Keita Ito (25.07.2003, 15:24)
On Fri, 25 Jul 2003 14:15:55 +0200, Andreas Korthaus wrote:

>Weil ich mir denke, dass eine Datenbank-Abstraktion nie so effektiv
>funktionieren kann wie eine individuelle API. Das ist einfach der Preis der
>Komopatibilität.


Das ist insofern richtig, als daß eine gemeinsame API auch nur die
gemeinsamen Funktionalitäten abdecken kann, und diese dürften sich auf
SQL/89 oder SQL/92 sowie deren Erweiterungen beschränken, alle
DBMS-spezifischen Dinge müssten anders geregelt werden.

>Oder ist der Zugriff via ODBC genauso performant und stabil
>wie über das native CLI?


Die extension heißt nur deswegen ODBC, weil sie die ODBC-Syntax nutzt,
intern arbeitet sie jedoch mit den DBMS-eigenen Bibliotheken.
Natürlich kann man auch mit dieser Extension über ODBC mit den DBMSen
kommunzieren, dazu muß jedoch die Extension mit iODBC Support gebaut
werden.

>Ich merke das ja z.B. bei PEAR::DB, das macht die
>Sache nicht unbedingt schneller und stabiler.


Abstraktionsschichten in PHP sind nie so effizient wie jene, die in
C/C++ geschrieben sind, da bildet PEAR::DB keine Ausnahme.

>Und wieso wird dann DB2 über dessen CLI angesprochen und nicht über ODBC?


Weil ODBC-Treiber nicht so effizient sind wie DBMS-spezifische
Treiber, weil ODBC selbst Overhead mit sich bringt.

greetings, Keita
Christian Hamacher (26.07.2003, 10:16)
Hallo Andreas,

Andreas Korthaus schrieb:
[über MySQL, PostgreSQL, DB2 und Oracle]
> Dann frage ich mich aber ernsthaft, wieso die Teile so
> teuer sind, nur wegen der tollen Tools und erweiterten SQL-Dialekten?


Die Annahme daß der Preis eines Produkt Rückschlüsse auf seine Qualität
bietet ist weltfremd. Genauso wie die Annahme das die Verbreitung eines
Produkt irgendwelche Rückschlüsse erlaubt. Leider unterliegen sehr viele
Menschen diesen Fehleinschätzungen, was dazu führt das sich das ganze
von alleine hoch schaukelt.

Gruß
Christian
Andreas Korthaus (26.07.2003, 11:55)
Christian Hamacher wrote:
> Die Annahme daß der Preis eines Produkt Rückschlüsse auf seine
> Qualität bietet ist weltfremd. Genauso wie die Annahme das die
> Verbreitung eines Produkt irgendwelche Rückschlüsse erlaubt. Leider
> unterliegen sehr viele Menschen diesen Fehleinschätzungen, was dazu
> führt das sich das ganze von alleine hoch schaukelt.

Ich kenne mich mit Oracle & Co. nicht aus, ich bekomme nur zwischendurch mit
was man damit alles so machen kann, und das übertrifft dei Möglichekeiten
alle freien produklte die ich kenen um ein vielfaches - nur muss man das
auch nutzen können, Oracle an sich ist schon so kompliziert, dass man sich
da nicht mal eben wie mit PostgreSQL oder MySQL einlesen udn nette Sachen
mit machen kann. Bei Oracle muss man sehr genau wissen was man tut. Und ich
halte es gnau im Gegenteil für einen Irrtum zu glauben dass alle Leute die
Das Geld für so eine Anwendung bezahlen das nur tun weil sie glauben dass
alles was teuer ist gut sein muss. Denn _das_ können sich die Firmen nicht
leisten. Du glaubst doch nicht ernsthaft das so viele Unternehmen Oracle in
kritischen Bereichen einsetzen, nur weil sie dem "Irrglauben" unterliegen
dass es ja gut sein muss da es so viele andere Verwenden und so teuer ist -
_das_ ist sehr kurzsichtig und realitätsfern.
Z.B. bei Linux, da entwickeln auch sehr viele Programmierer großer Firmen
hauptberuflich(IBM...), trotzdem kann es im High-End-Server Bereichs bis
heute noch nicht wirklich mit Solaris & Co mithalten. Und ich denke das
andere Open-Source Projekte, die nicht mit einer so breiten Unterstützung
durch große Unternehmen wie Linux ausgestattet sind, noch weiter hinter
einigen komerziellen Produkten hinterherhinken. Klar, bei kleineren,
unwichtigeren Projekten sind große Teile frei verfügbarer Software
kommerziellen Konkurrenten klar überlegen(z.B. Apache), aber gerade im
"High-End" Bereich sieht es da noch etwas anders aus, das liegt unter
anderem daran dass es hier bisher kaum Nachfrage gab(Linux->Cluster...), udn
ich denek auch dass es hier einfach noch an Wissen dr programmierer fehlt,
woher soll das kommen? Z.B. hat jeder der Linux-Programmierer seit jeher
einen X86-Rechner unterm Schreibtisch stehen, aber die wenigsten haben die
Möglichkeit auch Software für/auf Großrechner(n) zu entwickln zu können. Ich
bin überzeugt dass sich das in Zukunft ändern wird, aber wir leben nunmal
nicht in der Zukunft.Ähnlich ist es sicher auch bei Datenbanken,
Oracle-Entwickler konzentrieren sich seit jeher auf unternehmenskritische,
hochverfügbare Anwendungen und da werden die Produkte auch eingesetzt, d.h.
sie bekommen die ganze Zeit feedback, finden Fehler, verbessern Ihr Produkt
immer in diese Richtung, die Möglichkeiten haben MySQL & Co. Entwickler
einfach nicht, zumindest nicht in dem Umfang. Also wie sollen die dann "auf
dem Papier" ähnlich gute Server entwickeln können? Vor allem bei MySQL
konzentrierte man sich ja bisher fast ausschließlich auf ein Produkt für
Internet-Anwendungen, mit besonders schnellen Lesezugriffen. Wie gesagt hat
sich das inzwsichen ein wenig verschoben, aber von heute auf morgen kann man
nicht mal eben zu Oracle & Co. aufschließen. Man ist bei allen Open-Source
Datenbanken noch lange nicht auf demselben Niveau was die Möglichkeiten
angeht, und wenn man das mal ist dauert es noch ne ganze Zeit bis man auch
dieselbe Zuverlässigkeit erreicht, denn _das_ ist das entscheidende
Kriterium bei der Auswahl der Software in unternehmenskritischen Bereichen.
Und auch wenn man heute vielleicht mit PostgreSQL eine ähnlich Stabile
Lösung hätte(was ich nicht glaube), sind da noch die fehglenden Features die
die Entwicklung erleichtern..., ich würde auch die Kosten für eine Firma mit
mehrstelligem Millionen oder Mrd. Umsatz nicht überbewerten.
Naja, so sehe ich das halt, lase mich da auch gerne eines besseren belehren!
Wie gesagt, bei mir ist das anders, für uns wäre Oracle klar zu teuer, daher
suche ich was dazwischen, wenn ich ein kommerzielles RDBMS finden würde,
welches zuverlässiger ist also PostgreSQL ist und evtl die
Entwicklung/Administration erleichtert, dann würden wir hier sicher auch
Geld dafür ausgeben, weil es mit Sicherheit am Ende billiger ist - und sei
es nur dass ein teurer Ausfall/Datenverlust verhindert werden könnte.

Grüße
Andreas
Axel Schwenke (26.07.2003, 15:52)
Christian Hamacher <christian.hamacher> wrote:
> Hallo Andreas,
> Eins mal vorweg; ich habe nicht behauptet das Oracle schlecht ist oder
> sein Preis ungerechtfertigt ist.


Nun, 'schlecht' kann man Oracle nicht direkt nennen, aber es ist auf
jeden Fall viel zu teuer (außer den Lizenzen braucht man ja auch noch
Support [ohne Support gibts nicht mal Bugfixes] und die Hardware muß
für Oracle auch deutlich dicker sein als für andere DBMSe),

> Andreas Korthaus schrieb:
>> Christian Hamacher wrote:


> Es ist aber so. Was glaubst du auf was für absurden Wegen und von was
> für Personen in Unternehmen Entschädigungen getroffen werden.


Absolutes ACK.

Die sogenannten "Entscheider" haben von der Technik meistens Null
Ahnung und verlassen sich nur allzu oft auf Marketingsprüche oder
das Gesabbel von Consultants (die lieber eine teure Lösung empfehlen,
weil so ihre eigenen Kosten etwas in den Hintergrund treten).

Nicht zuletzt müssen auch und gerade Entscheider an die Sicherheit
ihres Arbeitsplatzes denken. »Nobody has ever been fired for buing IBM«

Übertragen auf Datenbanken wird daraus: niemand (zumindest niemand, vor
dem er Angst haben müßte) wird einen "Entscheider" kritisieren, wenn er
die Datenbank des Marktführers kauft. Und das ist - immer noch - Oracle.
Und solange die "Entscheider" nicht umdenken, wird das so bleiben.

man Teufelskreis

XL
Andreas Korthaus (27.07.2003, 08:17)
Axel Schwenke wrote:
> Die sogenannten "Entscheider" haben von der Technik meistens Null
> Ahnung und verlassen sich nur allzu oft auf Marketingsprüche oder
> das Gesabbel von Consultants (die lieber eine teure Lösung empfehlen,
> weil so ihre eigenen Kosten etwas in den Hintergrund treten).


Naja, ich kenne das definitiv anders, aus eigener Erfahrung. Bei einer
Entscheidung fpür eine Software wird in den größeren Unternehmen mit denen
ich zu tun habe jemand aus der IT-Abteilung geholt der sich genau mit dem
Bereich auskennt, und dessen Wort hat dann auch Gewicht, weil die sog.
"Entscheider" auch selbst wissen dass Sie zu wernig Ahnung haben.

> Nicht zuletzt müssen auch und gerade Entscheider an die Sicherheit
> ihres Arbeitsplatzes denken. »Nobody has ever been fired for buing
> IBM«

Ja, und warum? Wenn die freie Datenbank genauso gut lief würde er auch nicht
gefeuert, oder?

> Übertragen auf Datenbanken wird daraus: niemand (zumindest niemand,
> vor
> dem er Angst haben müßte) wird einen "Entscheider" kritisieren, wenn
> er
> die Datenbank des Marktführers kauft. Und das ist - immer noch -
> Oracle.
> Und solange die "Entscheider" nicht umdenken, wird das so bleiben.


Mag sein dass das in machen Firmen so ist, und ich weiß auch was es alles
für Möchtegern-Spezialisten in so Firmen gibt, trotzdem ist keine der freien
Datenbanken auch nur annährend mit Oracle vergleichbar, aus den genannten
Gründen, wie soll denn eien freie Datenbank ohne in den Bereichen überhaupt
eingesetzt zu werden vernünftig für kritische Anwendungen entwickelt werden
können?

Grüße
Andreas
Axel Schwenke (27.07.2003, 23:47)
"Andreas Korthaus" <akorthaus> wrote:
> Axel Schwenke wrote:
> Naja, ich kenne das definitiv anders, aus eigener Erfahrung. Bei einer
> Entscheidung fpür eine Software wird in den größeren Unternehmen mit denen
> ich zu tun habe jemand aus der IT-Abteilung geholt der sich genau mit dem
> Bereich auskennt, und dessen Wort hat dann auch Gewicht, weil die sog.
> "Entscheider" auch selbst wissen dass Sie zu wernig Ahnung haben.


Schön, daß es auch anders geht. *Ich* habe mit meinen eigenen Augen
gesehen, wie es genau anders herum läuft. Consultant sagt "Hüh",
interner sagt "Hott". Chef glaubt dem Consultant. Ob es am Schlips
liegt oder an der Powerpoint-Präsentation oder einfach daran, daß
ein Consultant für EUR 1500,- pro Tag gar nicht falsch liegen kann?

>> Nicht zuletzt müssen auch und gerade Entscheider an die Sicherheit
>> ihres Arbeitsplatzes denken. »Nobody has ever been fired for buing
>> IBM«

> Ja, und warum? Wenn die freie Datenbank genauso gut lief würde er auch nicht
> gefeuert, oder?


Aber er müßte das Risiko selbst tragen. Vergleiche doch mal die
folgenden Szenarien:

$BIG_BOSS: "Das Projekt ist gescheitert. Sie haben entschieden,
$UNBEKANNTES_OPENSOURCE_PRODUKT zu verwenden. Was haben
sie zu ihrer Rechtfertigung zu sagen?"

$ENTSCHEIDER: "Ähh..."

bzw.

$BIG_BOSS: "Das Projekt ist gescheitert....

$ENTSCHEIDER: "An $PRODUKT_DES_MARKTFÜHRERS kann es aber nicht liegen.
Das funktioniert bei @REFERENZKUNDEN hervorragend und wurde
uns von $GROSSE_CONSULTINGFIRMA empfohlen. Vermutlich sind
@MISSLIEBIGE_PERSONEN schuld, vor allem $KOLLEGE hat die
ganze Zeit gestänkert und $OPENSOURCE empfohlen. Wir sollten
da ein paar Positionen neu besetzen..."

Und immer daran denken, $BIG_BOSS hat von Technik noch weniger Ahnung
als $ENTSCHEIDER. Andererseits kennt er den Chef von $MARKTFÜHRER
vielleicht vom Golfplatz...

> Mag sein dass das in machen Firmen so ist, und ich weiß auch was es alles
> für Möchtegern-Spezialisten in so Firmen gibt, trotzdem ist keine der freien
> Datenbanken auch nur annährend mit Oracle vergleichbar,


Muß sie das denn? In den meisten Fällen werden die Killerfeatures von
(z.B.) Oracle gar nicht benötigt. Ein Pressesprecher von MySQL hat es
vor kurzem so ausgedrückt: "Alle Kunden, die wie Oracle abgewinnen, hat
Oracle ursprünglich nicht verdient". Dem wäre nichts hinzuzufügen.

XL
Christian Hamacher (28.07.2003, 07:59)
Andreas Korthaus schrieb:
> Axel Schwenke wrote:


> Naja, ich kenne das definitiv anders, aus eigener Erfahrung. Bei einer
> Entscheidung fpür eine Software wird in den größeren Unternehmen mit denen
> ich zu tun habe jemand aus der IT-Abteilung geholt der sich genau mit dem
> Bereich auskennt, und dessen Wort hat dann auch Gewicht, weil die sog.
> "Entscheider" auch selbst wissen dass Sie zu wernig Ahnung haben.


Ist es nicht eher so, daß sich der Mensch aus der IT-Abteilung mit einem
DBMS gut auskennt, mit einem anderen schon mal zu tun hatte, und noch
ein paar vom Nahmen her kennt?

>> Nicht zuletzt müssen auch und gerade Entscheider an die Sicherheit
>> ihres Arbeitsplatzes denken. »Nobody has ever been fired for buing
>> IBM«

> Ja, und warum? Wenn die freie Datenbank genauso gut lief würde er auch nicht
> gefeuert, oder?


Thomas und Alex haben es ja schon gesagt "wenn was schiefläuft ..."

Außerdem richtet sich der *Wert* (Gehalt, Ansehen ) des Entscheiders ja
auch nach der Höhe seiner Investitionen. Eine Abteilung die selber kein
Geld einnimmt, weil sie ja dafür sorgt das andere dies effektiver
können, muß ihre Wichtigkeit durch das Volumen der Investitionen zum
Ausdruck bringen. Sonnst glaubt man noch, man könnte sie abschaffen.

> ...., trotzdem ist keine der freien
> Datenbanken auch nur annährend mit Oracle vergleichbar, aus den genannten
> Gründen, wie soll denn eien freie Datenbank ohne in den Bereichen überhaupt
> eingesetzt zu werden vernünftig für kritische Anwendungen entwickelt werden
> können?


Mit anderen Worten:
"Eine OpenSource Lösung kommt für _kritische Anwendungen_ nicht in
Betracht, weil es auch noch kein Anderer gemacht hat."?

man Teufelskreis

Gruß
Christian
Ähnliche Themen