"Entwicklungsumgebung" fuer stored procedures?

Hallo NG!

Nachdem ich den Einstieg in das Thema "stored procedures"[1]
gewagt habe, finde ich die Sache relativ interessant. Allerdings
fehlt es mir bis dato noch an einem brauchbaren Weg, stored
procedures zu entwickeln und zu testen.
Normalerweise arbeite ich mit MySQL mit der Hilfe von $JEHOVA
und HeidiSQL[2] - je nach Tätigkeit.
Soweit bin ich mit beiden zufrieden, jedoch funktioniert damit
die Eingabe von stored procedures nicht besonders gut, weil
beide einerseits mit der DELIMITER-Anweisung nicht klar kommen,
aber andererseits nach meiner Erfahrung ohne DELIMITER stored
procedures bei der Eingabe gerne mal SQL-Fehler werfen.

Notgedrungen bin ich dann erstmal bei der MySQL-Konsole via SSH
gelandet, aber richtig befriedigend finde ich das auch nicht.

Also: womit entwickelt Ihr Eure stored procedures?


Tschüs,

Sebastian
_____
Anmerkungen:
[1]
[2] http://www.heidisql.com/

--
http://www.baumaschinen-modelle.net
http://www.schwerlast-rhein-main.de

Re: "Entwicklungsumgebung" fuer stored procedures?

Sebastian Suchanek wrote:

> Nachdem ich den Einstieg in das Thema "stored procedures"[1]
> gewagt habe, finde ich die Sache relativ interessant. Allerdings
> fehlt es mir bis dato noch an einem brauchbaren Weg, stored
> procedures zu entwickeln und zu testen.
> [..]
> Notgedrungen bin ich dann erstmal bei der MySQL-Konsole via SSH
> gelandet, aber richtig befriedigend finde ich das auch nicht.
>
> Also: womit entwickelt Ihr Eure stored procedures?

Es gibt den von MySQL herausgegebenen QueryBrowser[1], der ist zwar nicht
unfehlbar, unterstützt aber sämtliche von MySQL angebotenen Funktionen. Ich
hatte neulich zwar Probleme mit den GIS-Funktionen, aber wahrscheinlich hab
ich mich da ein bißchen doof angestellt.

Grüße
Johannes

[1] http://dev.mysql.com/downloads/gui-tools/5.0.html

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.

Re: "Entwicklungsumgebung" fuer stored procedures?

Sebastian Suchanek wrote:
> Also: womit entwickelt Ihr Eure stored procedures?

Gar nicht, wenn es geht. Stored Procedures sind ein furchtbarer Irrweg und
sollten nach Möglichkeit vermieden werden.

Kris

--
Kristian =?iso-8859-15?q?Köhntopp?=

Re: "Entwicklungsumgebung" fuer stored procedures?

Kristian Köhntopp schrieb:
> Sebastian Suchanek wrote:
>> Also: womit entwickelt Ihr Eure stored procedures?
>
> Gar nicht, wenn es geht. Stored Procedures sind ein furchtbarer Irrweg und
> sollten nach Möglichkeit vermieden werden.
>

Falls ich die Ironie-Tags übersehen habe: Würdest Du das bei Gelegenheit
etwas ausführen? Ich hatte bisher immer gedacht, SP seien quasi der
Heilige Gral der DB-Entwicklung - lasse mich aber gerne eines Anderen
belehren.

Christian

Re: "Entwicklungsumgebung" fuer stored procedures?

Kristian Köhntopp schrieb:

> Sebastian Suchanek wrote:
>
>> Also: womit entwickelt Ihr Eure stored procedures?
>
> Gar nicht, wenn es geht. Stored Procedures sind ein furchtbarer Irrweg und
> sollten nach Möglichkeit vermieden werden.

Kannst Du das bitte etwas näher erläutern?

Gruß. Claus

Re: "Entwicklungsumgebung" fuer stored procedures?

Christian Kirsch wrote:
> Kristian Köhntopp schrieb:
>> Sebastian Suchanek wrote:
>>> Also: womit entwickelt Ihr Eure stored procedures?
>>
>> Gar nicht, wenn es geht. Stored Procedures sind ein furchtbarer Irrweg
>> und sollten nach Möglichkeit vermieden werden.
>>
>
> Falls ich die Ironie-Tags übersehen habe: Würdest Du das bei Gelegenheit
> etwas ausführen? Ich hatte bisher immer gedacht, SP seien quasi der
> Heilige Gral der DB-Entwicklung - lasse mich aber gerne eines Anderen
> belehren.

Wir wollen ja gerne Systeme bauen, die sich sauber und kostengünstig
skalieren lassen und leicht zu warten sind. Wenn wir uns existierende sehr
große Systeme ansehen, dann stellen wir fest, daß dies alles verteilte
asynchrone Systeme sind.

Stored Procedures sind das Gegenteil von diesem Modell: Sie werden in der
Datenbank ausgeführt und nicht auf einem Frontend- oder Midddleware-System,
also dort wo CPUs und Speicher am knappsten und teuersten sind. Warum
jemand genau dort Code ausführen möchte ist mir vollkommen schleierhaft.

Dazu kommt, daß man hier Code vor seinen Developern versteckt - sie können
dort nicht die selbe Sprache verwenden wie im Rest der Anwendung, Stored
Procedures entziehen sich zum Teil dem üblichen Codemanagement, der übrigen
Development Methodik und auch den normalen Debugmethoden.

Und besonders effizient ist es auch nicht.

Wieso also wollte man etwas mit SPs machen wollen?

Kris

--
Kristian =?iso-8859-15?q?Köhntopp?=

Re: "Entwicklungsumgebung" fuer stored procedures?

Kristian Köhntopp schrieb:
> Christian Kirsch wrote:
>> Kristian Köhntopp schrieb:
>>> Sebastian Suchanek wrote:
>>>> Also: womit entwickelt Ihr Eure stored procedures?
>>> Gar nicht, wenn es geht. Stored Procedures sind ein furchtbarer Irrweg
>>> und sollten nach Möglichkeit vermieden werden.
>>>
>> Falls ich die Ironie-Tags übersehen habe: Würdest Du das bei Gelegenheit
>> etwas ausführen? Ich hatte bisher immer gedacht, SP seien quasi der
>> Heilige Gral der DB-Entwicklung - lasse mich aber gerne eines Anderen
>> belehren.
>
> Wir wollen ja gerne Systeme bauen, die sich sauber und kostengünstig
> skalieren lassen und leicht zu warten sind. Wenn wir uns existierende sehr
> große Systeme ansehen, dann stellen wir fest, daß dies alles verteilte
> asynchrone Systeme sind.

Es gibt verschiedene Arten ein verteilte DB zu realisieren, nicht in
allen Fällen sind stored procedures ein Problem.


>
> Stored Procedures sind das Gegenteil von diesem Modell: Sie werden in der
> Datenbank ausgeführt und nicht auf einem Frontend- oder Midddleware-System,
> also dort wo CPUs und Speicher am knappsten und teuersten sind. Warum
> jemand genau dort Code ausführen möchte ist mir vollkommen schleierhaft.

Ganz einfach weil es je nach Anwendungsfall sicherer bzw schneller ist.
Man stelle sich eine Abfrage vor, bei der du erst verschiedenen Selects
ausführst und aufgrund der Results neue Selects oder Deletes etc.
ausführst. Dann hast du mehrere Aufrufe an die Datenbank, die du sonst
mit einem einzigen CALL erledigen könntest

>
> Dazu kommt, daß man hier Code vor seinen Developern versteckt - sie können
Ok also sind Dinge wie OOP, dlls auch ganz böse Dinge
> dort nicht die selbe Sprache verwenden wie im Rest der Anwendung, Stored
> Procedures entziehen sich zum Teil dem üblichen Codemanagement, der übrigen

Kommt auf die Tools ein die man zur DB Entwicklung einsetzt.

> Development Methodik und auch den normalen Debugmethoden.

>
> Und besonders effizient ist es auch nicht.
>
> Wieso also wollte man etwas mit SPs machen wollen?

Ich zitiere mal aus dem MySQL manual:

When security is paramount. Banks, for example, use stored procedures
and functions for all common operations. This provides a consistent and
secure environment, and routines can ensure that each operation is
properly logged. In such a setup, applications and users would have no
access to the database tables directly, but can only execute specific
stored routines.

Stored routines can provide improved performance because less
information needs to be sent between the server and the client. The
tradeoff is that this does increase the load on the database server
because more of the work is done on the server side and less is done on
the client (application) side. Consider this if many client machines
(such as Web servers) are serviced by only one or a few database servers.

Stored routines also allow you to have libraries of functions in the
database server. This is a feature shared by modern application
languages that allow such design internally (for example, by using
classes). Using these client application language features is beneficial
for the programmer even outside the scope of database use.


Gruß Stefan

>
> Kris
>