Muß man immer noch aussuchen, ob man lieber kaputte Transaktionen oder kaputte Volltext-Indices will? Kann mysql immer noch nicht richtig mit NULL umgehen? Ist der 30.02. immer noch ein gültiges Datum? Gibts endlich Sequences, nested Queries und Row Level Trigger? Ist der Query Optimizer immer noch so ein Trauerspiel?
Die sollten anstatt ständig irgendwelche halbgaren Möchtegern-Enterprise-Features einzubauen erstmal ihre Hausaufgaben machen. Beispielsweise mal eine Storage Engine bauen, die auch wirklich uneingeschränkt funktioniert.
Bis da hin nehm ich dann nach Möglichkeit doch lieber postgresql, das ist genauso frei, performanter, einfacher zu installieren und konfigurieren und sehr viel leistungsfähiger.
Ich verstehe nicht ganz, warum Du Dich darüber beklagst, dass ein Produkt, das Du weder einsetzt noch einsetzen willst, bestimmte von Dir benötigte Funktionen nicht unterstützt.
P.S.: Nested Queries funktionieren übrigens schon ziemlich lange, in MySQL 5 sogar recht performant.
Gut, der Hinweis auf die eigenen Präferenzen mag falsch sein, aber die angesprochenen Dinge sind zu einem großen Teil immernoch vorhanden und beeinträchtigen vor allem die Entwicklung von DB-übergreifenden Anwendungen für MySQL. Ich finde auch, dass die diversen Sonderverhaltensweisen endlich abgestellt werden sollten.
Don't do full checking of dates. Check only that the month is in the range from 1 to 12 and the day is in the range from 1 to 31. This is very convenient for Web applications where you obtain year, month, and day in three different fields and you want to store exactly what the user inserted (without date validation). This mode applies to DATE and DATETIME columns. It does not apply TIMESTAMP columns, which always require a valid date.
This mode is implemented in MySQL 5.0.2. Before 5.0.2, this was the default MySQL date-handling mode. As of 5.0.2, the server requires that month and day values be legal, and not merely in the range 1 to 12 and 1 to 31, respectively. With strict mode disabled, invalid dates such as '2004-04-31' are converted to '0000-00-00' and a warning is generated. With strict mode enabled, invalid dates generate an error. To allow such dates, enable ALLOW_INVALID_DATES.
Mein Prof. in DABA versteht nicht wie MySQL sich so weit verbreiten konnte ^^ Wenn es war ernstgaftes sein sollte, dann sollte man anscheinend Sybase etc. verwenden.
Irgendwie ging mein Kommantar zu postgres von gestern verloren. Also versuche ich es nochmal:
Hat postgres immer noch das Problem, dass ein SQL-Fehler direkt ein Rollback ausführt? Wir hatten das Problem früher und es nie gelöst bekommen, weswegen wir dann mysql genommen haben. Eigentlich sollte die DB nur eine Exception werfen, die von der Applikation abgefangen werden kann, so dass sie entscheiden kann, ob ein Rollback gefahren werden soll oder nicht.
Öhm, das mag vom Kontext abhängen, ob man solches Verhalten wirklich will, ich möchte es aber zum Beispiel nicht der Anwendung überlassen, ob fehlerhafte Daten einen Rollback auslösen oder nicht. Aber gut, man sollte es zumindest konfigurieren können.
Von Sybase würde ich ehrlich gesagt abraten. Wenn man nicht gerade das nicht zur DB gehörende Admintool "Sybase Central" als Plus anführt, dann bleibt bei den reinen Datenbankeigenschaften nicht mehr viel übrig. Fakt ist, dass sich auch ASA wie MySQL einige schräge Eigenheiten erlaubt hat.
Zum Beispiel bei der Behandlung von NULL-Values, wenn man einen Vergleichsoperator heranzog. In den älteren Versionen verhält es sich unter anderem dabei nicht standardkonform, indem es NULL-Values positiv in die Operationen aufnimmt. Bei neueren ASA-Versionen ist das zwar korrigiert, wer dieses unsägliche Verhalten allerdings noch braucht, kann es mit der Enterprise-Version dazukaufen.
Auch hatte ich bei Migrationen durchaus die eine oder andere bizarre Situation - zwei Zeilen mit dem gleichen Primary Key zum Beispiel.
Oder die (empfohlene) Synchronisation in den neueren Versionen mittels des Tools MobiLink. Zum einen zieht es sich zur Synchronisation erst einmal alle zu synchronisierenden Datensätze lokal und synchronisiert sie dann, was selbst in Unternehmen mit wenigen Änderungen (dafür größeren Datenbanken) zu stundenlangem Synchronisieren führen kann und uns letztlich dazu brachte, eine Terminalserver-Lösung für das mobile Arbeiten einzusetzen, zum anderen ist es bezüglich des Lockings sehr unflexibel. Hat beim "holen" der zu synchronisierenden Daten ein Nutzer einen Rowlock auf einer betroffenen Tabelle, so schlägt die ganze Synchronisation fehl. Das liegt vorrangig an der SQL-Implementierung. Damit ist es zwar theoretisch DB-übergreifend einsetzbar, eine Lösung, die mithilfe des Transaktionslogs die Transaktionen in der konsolidierten Datenbank nachvollzieht wäre aber deutlich hilfreicher und zugriffsunabhängiger gewesen.
Ich weiß nicht, ob Sybase besser geworden ist, aber ich empfand die DB immer als nervig. Vor allem das Problem der zyklischen on-delete-cascade-Referenzen, die bei anderen DBs (Informix, Oracle, mysql) kein Problem darstellten. In MS-Sql (zumindest früher, ob aktuell auch noch weiß ich nicht) gab es das auch, weil MS-Sql ursprünglich ja m.W. von Sybase abstammt.
> weil MS-Sql ursprünglich ja m.W. von Sybase abstammt Ja. Allerdings hat sich MSSQL inzwischen bedeutend weiterentwickelt, das muss man schon sagen. Vor allem jetzt auch die 2008er-Version. Auch wenn ich gern mit dem Sybase Central MS-Datenbanken verwalten würde, es ist einfach ein großartiges Tool, aber da hat man sich offenbar dann doch schon zu weit auseinanderentwickelt, auch schon in der 2005er-Version.
Sybase ist meines Erachtens heute ausschließlich aus Bestandserhaltungsgründen attraktiv und weil es, im Gegensatz zu MSSQL, auch für alternative Betriebssysteme verfügbar ist. Ansonsten ist es nur noch eine reine Geldmaschine für Sybase Inc., deren Kunden aufgrund der jahrelangen Bindung (auch durch Produkte wie den Sybase PowerBuilder) nicht mehr wechseln können.
Sun hat das alte MySQL-Logo noch nicht endgültig gecancelt.
Nimm besser dieses Logo:
http://dev.mysql.com/common/logos/logo_mysql_sun.gif
Die sollten anstatt ständig irgendwelche halbgaren Möchtegern-Enterprise-Features einzubauen erstmal ihre Hausaufgaben machen. Beispielsweise mal eine Storage Engine bauen, die auch wirklich uneingeschränkt funktioniert.
Bis da hin nehm ich dann nach Möglichkeit doch lieber postgresql, das ist genauso frei, performanter, einfacher zu installieren und konfigurieren und sehr viel leistungsfähiger.
P.S.: Nested Queries funktionieren übrigens schon ziemlich lange, in MySQL 5 sogar recht performant.
Ich könnte dir jetzt erzählen welche Bratpfannen ich toll finde,...
lg
Erik
#
ALLOW_INVALID_DATES
Don't do full checking of dates. Check only that the month is in the range from 1 to 12 and the day is in the range from 1 to 31. This is very convenient for Web applications where you obtain year, month, and day in three different fields and you want to store exactly what the user inserted (without date validation). This mode applies to DATE and DATETIME columns. It does not apply TIMESTAMP columns, which always require a valid date.
This mode is implemented in MySQL 5.0.2. Before 5.0.2, this was the default MySQL date-handling mode. As of 5.0.2, the server requires that month and day values be legal, and not merely in the range 1 to 12 and 1 to 31, respectively. With strict mode disabled, invalid dates such as '2004-04-31' are converted to '0000-00-00' and a warning is generated. With strict mode enabled, invalid dates generate an error. To allow such dates, enable ALLOW_INVALID_DATES.
lg
Erik
Hat postgres immer noch das Problem, dass ein SQL-Fehler direkt ein Rollback ausführt? Wir hatten das Problem früher und es nie gelöst bekommen, weswegen wir dann mysql genommen haben. Eigentlich sollte die DB nur eine Exception werfen, die von der Applikation abgefangen werden kann, so dass sie entscheiden kann, ob ein Rollback gefahren werden soll oder nicht.
lg
Erik
Zum Beispiel bei der Behandlung von NULL-Values, wenn man einen Vergleichsoperator heranzog. In den älteren Versionen verhält es sich unter anderem dabei nicht standardkonform, indem es NULL-Values positiv in die Operationen aufnimmt. Bei neueren ASA-Versionen ist das zwar korrigiert, wer dieses unsägliche Verhalten allerdings noch braucht, kann es mit der Enterprise-Version dazukaufen.
Auch hatte ich bei Migrationen durchaus die eine oder andere bizarre Situation - zwei Zeilen mit dem gleichen Primary Key zum Beispiel.
Oder die (empfohlene) Synchronisation in den neueren Versionen mittels des Tools MobiLink. Zum einen zieht es sich zur Synchronisation erst einmal alle zu synchronisierenden Datensätze lokal und synchronisiert sie dann, was selbst in Unternehmen mit wenigen Änderungen (dafür größeren Datenbanken) zu stundenlangem Synchronisieren führen kann und uns letztlich dazu brachte, eine Terminalserver-Lösung für das mobile Arbeiten einzusetzen, zum anderen ist es bezüglich des Lockings sehr unflexibel. Hat beim "holen" der zu synchronisierenden Daten ein Nutzer einen Rowlock auf einer betroffenen Tabelle, so schlägt die ganze Synchronisation fehl. Das liegt vorrangig an der SQL-Implementierung. Damit ist es zwar theoretisch DB-übergreifend einsetzbar, eine Lösung, die mithilfe des Transaktionslogs die Transaktionen in der konsolidierten Datenbank nachvollzieht wäre aber deutlich hilfreicher und zugriffsunabhängiger gewesen.
lg
Erik
Ja. Allerdings hat sich MSSQL inzwischen bedeutend weiterentwickelt, das muss man schon sagen. Vor allem jetzt auch die 2008er-Version. Auch wenn ich gern mit dem Sybase Central MS-Datenbanken verwalten würde, es ist einfach ein großartiges Tool, aber da hat man sich offenbar dann doch schon zu weit auseinanderentwickelt, auch schon in der 2005er-Version.
Sybase ist meines Erachtens heute ausschließlich aus Bestandserhaltungsgründen attraktiv und weil es, im Gegensatz zu MSSQL, auch für alternative Betriebssysteme verfügbar ist. Ansonsten ist es nur noch eine reine Geldmaschine für Sybase Inc., deren Kunden aufgrund der jahrelangen Bindung (auch durch Produkte wie den Sybase PowerBuilder) nicht mehr wechseln können.
lg
Erik