Hi Klaus!
Besser finde ich es, weil wenn DU die Artikel sowieso schon in einem RDBMS speichern willst, halte ich es für besser, wenn Du nicht 'aus dem System herausspringst'. Daten, die zusammengehören, auf zwei unterschiedliche Medien auzuteilen, finde ich nicht so toll.
Ja, das habe ich mir auch gedacht. Was hälst Du denn von er Idee die Struktur mehr oder weniger persistent in einem PHP-Array zu speichern?
Gut, Oracle könnte mir auch gefallen, obwohl ich da so gut wie keine Erfahrung mit habe, aber man hört ja dies und das...
Also so nebenbei würde ich das nicht mehr machen. Ich hatte bisher immer das Glück einige erfahrene Oracle-DBA's um mich zu haben, wenn ich damit zu tun hatte (und habe). Ohne qualifizierte Unterstützung ist das sicherlich ein Höllenritt. Sie kann zwar wirklich viel, obwohl ich auch schon einiges vermißt habe, aber man muß bei allem schon sehr genau überlegen, was das alles für Konsequenzen hat.
Ja, da hast Du vollkommen Recht. Oracle würde vermutlich die Entwicklungskosten deutlich in die Höhe treiben, und dazu die Lizenzkosten um ein vielfaches erhöhen. Das wiederum tribt am Ende den Preis für die Software in die Höhe, was natürlich nicht so schön ist, udn nach Möglichkeit vermieden werden soll.
_Das_ kommt dann ja auch noch dazu. Aber wenn die Kunden es so haben wollen. Ich bin mir zwar nicht sicher, aber afaik ist die Benutzung zumindestens für Entwicklung von Anwendungen kostenfrei.
Ja, aber man braucht ja spätestens wenn es Produktiv eingesetzt wird Lizenzen, also bringt das auch nicht viel. Außerdem wird bei größeren Rechnern und ein paar mehr Usern schnell _sehr_ viel teurer.
Von DB2 weiß ich lediglich, daß es sie gibt und daß sie von IBM kommt.
Ist immer hin nach Oracle am meisten verbreitet, wenn auhc vornehmlich auf IBMs Mainframes, aber auch dei Linux-Version macht wohl viel Boden gut. Auf jeden Fall ist DB2 _erheblich_ günstiger als Oracle. Nur ist es schwer objektive Informationen zu den jeweili Vor- und Nachteilen zu erhalten, denn meist finden man nur white-papers, meist von oracle und die lassen dann kein gutes Haar an DB2, sei noch unzuverlässiger als MSSQL Server... aber ich kann diese Aussagen nicht wirklich bewerten, ich bin da lieber etwas vorsichtiger, denn IBM führt Studien an die dasselbe von Oracle behaupten...
ODBC ist keine Datenbank, sonder eine Client-Schnittstelle, vergleichbar mit DBI oder JDBC.
Klar ;-)
Habe übrigens herausbekommen, dass PHP DB2 doch über die native Schnittstelle unterstützt, zwar verwendet man die odbc-Funktionen, aber diese verwenden kann kein ODBC-Interface, sondern das native DB2 CLI. Wie gut diese Schnittstelle allerdings ist/sein kann kann ich nicht beurteilen.
Die Sybase-Datenbank ist dem MSSQL-Server ziemlich ähnlich, kein Wunder, waren bei in ihren früheren Versionen einmal dasselbe.
Funktioniert wenigstens auf Linux, und gehört ebenfalls zu den 5 größten.
Auch zu PostgreSQL kann ich auch nichts sagen, das gleiche gilt für Adabas bzw. SAP-DB und Informix.
SAP-DB ist ja wohl aus ADABAS hervorgegangen und frei verfügbar. Mehr weiß ich da auch nicht. Informix war früher mal sehr verbreitet, wurde aber von IBM aufgekauft und verliert an Bedeutung, naja, eien objektive Meinung über die Qualität und Unterschiede mehrerer DBs zu bekommen ist nicht einfach ;-)
PostgreSQL ist schon wirklich nett
Transactions
Procedural languages (PL/pgSQL und PL/Perl)
Fully ACID compliant
ANSI SQL compliant
Referential Integrity
Replication
Native interfaces for ODBC, JDBC, C, C++, PHP, Perl, TCL, ECPG, Python, and Ruby
Rules
Views
Triggers
Unicode
Sequences
Inheritance
Outer Joins
Sub-selects
An open API
Stored Procedures
Support for UNION, UNION ALL and EXCEPT queries
Extensible data type system providing for custom, user-defined datatypes and rapid development of new datatypes
Cross-database compatibility functions for easing the transition from other, less SQL-compliant RDBMS
...
Und PostgreSQL gibt es schon wirklich lange, und da sehe ich auch den Vorteil gegenüber MySQL, ist ja alles schön und gut dass es inzwischen Transaktionen und Fremdschlüssel gibt, aber leider noch nicht so besonders lange, und es wird nicht oft benutzt, das ganez ist noch nicht wirklich gut ausgetestet, so dass man sich beruhigt 100%ig drauf verlassen könnte. Und das geben did Entwickler ja selbst im Manual zu, und gerade das ist mir bei der Wahl des RDBMS besonders wichtig.
Das wichtigste Kriterium ist, dass die Wahrscheinlichkeit, dass zu einem bestimmten Zeitpunkt bestimmte Daten nicht oder nicht korrekt vorliegen minimiert wird - nicht um _jeden_ Preis(Oracle), aber es darf durchaus was kosten. Denn wenn so etwas passiert wird das am Ende sicher teurere als eine komerzielle DB-Lizens. Nur ist es auf der anderen Seite ja auch Quatsch Geld für sowas auszugeben, wenn eine freie Lösung wie PostgreSQL den komerziellen Systemen hier in nichts nachsteht - was mich allerdings wundern würde. Auf jeden Fall sollte die Software auf Linux wirklich zu Haus sein, nicht dass es hier probleme gibt da ein System "auf dei Schnelle" nach Linux portiert wurde, oder dass die Schnittstelle von PHP schlecht implementiert ist.
Bleiben wir bei Firebird.
Eigentlich gefällt mir die DB recht gut. Sie hat zwar einige Eigenheiten, aber mit denen kann man recht gut leben.
Von Firebird habe ich eigentlich nur in einem CT-Artikel mal was gelesen, naja, hab es mir noch nicht nähr angeschaut, muss den Artikel nochmal lesen und mir das ggfs. nochmal neäher ansehen.
Sie beherrscht neben Tabellen (no na *g*) auch noch Views, Sequences (Generatoren), Trigger, Stored Procedures, Domains (damit kann man quasi logische Datentypen definieren), Transaktionen und User-defined-Funktions (UDF). Letzteres macht so ziemlich die Spärlichkeit bei eingebauten Funktionen wett.
Auch Hot-Backups können dank interner Daten-Versionierung gemacht werden. Und der Transfer einer kompletten DB von hinnen nach dannen ist an sich auch ein Kinderspiel.
Ist dann also von den Features ein wenig vergleichbar mit PostgreSQL, welches ich hier glaube ich vorziehen würde wegen der guten Schnittstelle in PHP. Wie/ob man auf Firebird aus PHP zugreifen kan weiß ich nicht, nur tue ich mich immer schwer mit ODBC, damit hatte ich schonmal arge Probleme, und das unter Windows wo es ja eigentlich herkommt.
Die neue Version, die anscheinend kurz vor der offiziellen Release steht, kann dann auch noch so Sachen wie Savepoints (also so was ähnliches wie Transaktionen in einer Transaktion) LIMIT und son Zeuchs.
Wie gesagt, mir gefällt sie schon recht gut, vor allem bei kleinem bis mittlerem Datenaufkommen (sagen wir mal bis einer Datenbankgröße von einigen 100MByte).
Ich werde es mir auf jeden Fall nochmal näher ansehen.
Jedenfalls vielen Dank für Deine Tipps!
Viele Grüße
Andreas