Grenzen von MySQL

[Sven Heising]

Hola,
<schnipp>
> Noch was tum Thema Stored Procedures und Views: Wenn man mal große
> Anwendungen baut und sich nicht 100% auf einen Server festlegen will und
> seine Anwendung auch pflegbar lassen will dann wird man sich sehr schnell
> von diesen "Features" verabschieden. Denn sie bringen rein garnichts.
> StoredProcedures sind nicht portabel und Views behindern
Strukturänderungen
> teilweise erheblich. Auch referrenzielle Integrität via Foreign Key
Angaben
> in Tabellen sind meiner Meinung nach tödlich für Strukturänderungen. Das
> gehört für mich alles in den Abstraktionslayer der Anwendung, die weiss
viel
> besser was sie tut. Gerade bei Foreign Keys ist es oft das Problem Daten
zu
> importieren in einer angemessenen Zeit. Werd schonmal Systeme migiriert
hat
> kann ein Lied davon singen. Und das alles nur weil man den
> Anwenungsentwicklern untersagen will was sie machen. Für mich die falsche
> Stelle in der Datenbank.
Performance? Wir entwickeln Zeiterfassugnssysteme und da bringen stored
Procedures einiges an Geschwindigkeit.
Wir haben unser Produkt auch auf MySQL entwickelt und da ist im Vergleich
der Geschwindigkeiten zu einer SP-fähigen Datenbank bei den Berechnungen ein
erheblicher Unterschied zu merken.
Und wieso untersagt man den Anwendungsentwicklern etwas? Ich bin Entwickler
und schreibe meine SP's selber weil Sie Performance-mässig einiges bringen.
Das man dadurch sein Programm natürlich dann an andere Datenbanken anpassen
muss ist klar, aber mich nur auf ODBC und ANSI Sql zu verlassen fände ich
sowieso nicht so entzückend...

> Gruß,
> Andreas Müller
Grüsse
Sven Heising


-- 
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql