Bookmarks

Yahoo Gmail Google Facebook Delicious Twitter Reddit Stumpleupon Myspace Digg

Search queries

sqlexpress database file auto-creation error, dbf2mysql parameter, WWWXXXAPC, wwwxxxAPC, How to unsubscrube from dategen spam, docmd.close 2585, WWWXXXDOCO, nu vot, dhcpd lease file "binding state", WWWXXXDOCO

Links

XODOX
Impressum

#1: "Entwicklungsumgebung" fuer stored procedures?

Posted on 2007-11-09 23:25:59 by Sebastian Suchanek

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] <fh2lsj$3ml$1@suchanek.de>
[2] http://www.heidisql.com/

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

Report this message

#2: Re: "Entwicklungsumgebung" fuer stored procedures?

Posted on 2007-11-10 11:05:11 by Johannes Mueller

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.

Report this message

#3: Re: "Entwicklungsumgebung" fuer stored procedures?

Posted on 2007-11-15 10:41:56 by Kris

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=F6hntopp?= <kris@xn--khntopp-90a.de>

Report this message

#4: Re: "Entwicklungsumgebung" fuer stored procedures?

Posted on 2007-11-15 11:39:44 by Christian Kirsch

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

Report this message

#5: Re: "Entwicklungsumgebung" fuer stored procedures?

Posted on 2007-11-15 14:25:40 by Claus Reibenstein

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

Report this message

#6: Re: "Entwicklungsumgebung" fuer stored procedures?

Posted on 2007-11-16 18:25:09 by Kris

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=F6hntopp?= <kris@xn--khntopp-90a.de>

Report this message

#7: Re: "Entwicklungsumgebung" fuer stored procedures?

Posted on 2007-11-16 19:38:52 by Stefan Braumeister

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
>

Report this message