phpbar.de logo

Mailinglisten-Archive

Grenzen von MySQL

Grenzen von MySQL

Ralf Geschke ralf at kuerbis.org
Don Mar 6 21:25:25 CET 2003


Hallo !

> Das ist genaus das , was die Liste braucht.

Wirklich?

> Dahingehend habe ich mit meinen Provokationen wenigstens wieder ein paar Leute zum schreiben gebracht. Und das Resultat kann sich doch sehen lassen.

Also doch Troll. Nun gut, eine letzte Fuetterung. :-)

> PS: Sorry für mein schlechtes Quoting, werde Besserung geloben.

Geloebnisse bringen einen nicht weiter, aber trotzdem danke. 
Es waere dazu sehr zuvorkommend, wenn Du Deine Zeilen etwas
kuerzen wuerdest, so ca. 72 Zeichen waeren optimal, dann liessen
sich Deine Texte wesentlich besser zitieren. 

> Und nochwas, Den Unsinn mit Deinen Sproc Aussagen will ich nicht weiter vertiefen, denn man lernt bereits im ersten Studienhalbjahr an jeder Hochschule, dass die beste Performance einer DB Aufgabe (Insert, Update, Delete) in der DB selbst erlangt wird.

Ach ja? Also in den Vorlesungen, die ich kenne bzw. Buecher, die sich
mit Datenbanken und nicht einer konkreten Implementierung 
beschaeftigen, wird da doch eher auf Grundlagen bzw. Theorie Wert 
gelegt, also alles von Aufbau von Datenbanksystemen, Geschichte und 
Architektur derselben, Eigenschaften, Schemata, Schichten, 
Datenmodelle, selbstverstaendlich Relationen, Tupel, 
relationale Algebra, Normalformen, bis hin zu Organisation
der Datenspeicherung. Selbst SQL findet je nach Schwerpunkt
allenfalls nebenbei Erwaehnung, und stored procedures werden 
dabei nur als eine Art der Anfrage anderen gegenuebergestellt. 
Aber das nur am Rande...

> Es gehört zum einmaleins, eine DB Aufgabe nach Möglichkeit aus der Seitenlogik heraus zu nehmen. Die Betonung liegt hier auf "nach Möglichkeit". Bei einem Select ist es wieder was anderes, hier scheiden sich die Geister immer noch. Aber grundsätzlich gehört's auch in eine Sproc. Ein erhebliches Argument ist natürlich auch die Sicherheit gegen SQL Injection. Mit einem Parameter in einer Sproc, ist SQL Injection ausgeschlossen.

Du schmeisst Sicherheitsaspekte und stored Procedures in einen
Topf und ruehrst gut um. Leider kommt dabei nur dieser hier
geschilderte Brei heraus. ;-)
Was oder wer nun dafuer sorgt, dass SQL injection verhindert wird, 
ist doch nun wirklich irrelevant. 

Es steht ja gar nicht zur Debatte, dass stored Procedures ganz
brauchbar sein koennen. Und in MySQL 5.0 sollen sie sogar
zur Verfuegung stehen. Wer bis dahin nicht ohne diese auskommt
der moege halt eine andere Datenbank verwenden. 
Ich hab' sie nichtsdestotrotz bislang nicht sonderlich vermisst,
und das durchaus in Anwendungen weit abseits des "Mein Gaestebuch"-
Levels. 

Beste Gruesse,
   Ralf


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


php::bar PHP Wiki   -   Listenarchive