MySQL Dynamische Variablen

[Stigma]

Hallo,

ich habe mal eine Frage. Ich muss mich im Moment mit Stored Procedures in MySQL befassen. So weit so gut. Die eine Aufgabe ist aber estwas knifflig. Daher versuche ich es mal anzuschneiden.

Was ich brauche sind Variablen, die sich aufgrund einer Menge x selbst erstellen. Hintergrund hierfür: Ich weis nicht, wieviel Variablen als Rcükgabe kommen könnten. Sie würden zwar im Verlauf immer gleich bleiben, aber beim starten weis ich sie noch nicht.

Mit der Masse an dynmisch deklarierten Variablen würde ich dann eine zweite Prozedur aufrufen, die mir diese Werte als IN und als OUT Parameter schluckt. In dieser werden diese dann berechnet und an die obere Prozedur zurückgegeben.

Geht das überhaupt mit MySQL? Leider gibt es für diese Aufage keine Alternative ausser nur rein MySQL.

Ich würde mich über Antworten echt freuen.

Liebe Grüße,

Stigma

[perdian]

Ich blicke nicht wirklich durch, was du nun wirklich vor hast, aber das ganze klingt doch sehr gewagt um es als Datenbanklogik abzubilden. Die Datenbank sollte primär zur Datenspeicherung nicht zur Datenverarbeitung genutzt werden. Stored Procedures und Konsorten haben sicherlich ihre Daseinsberechtigung aber direkt damit loszulegen und das als einzige richtige Lösung zu sehen bringt oftmals mehr Probleme als man eigentlich haben müsste.

[Stigma]

Hallo,

ja das mag sein, dass es gewagt ist. Nur ist das nicht meine Idee gewesen, sondern ich muss die Anforderung versuchen so umzusetzen.

Ich muss x variablen declarieren können, wieviel ich in einem cursor finde, da ich x Objekte mit einander vergleichen muss. Sofern ich das dann habe dürfte der rest kein Problem mehr sein. Zum Schluss kommt für jedes Objekt ein berechneter Wert heraus.

Wenn also 20 Objekte berechnet werden müssen, und der CURSOR 20 sagt, dann müsste ich auch 20 Variablen haben, die ich einzeln miteinander berechnen kann.

In einem Cursor weiter runter gehe ich eine Menge von oben nach unten durch und die einzelnen dazu verknüpften Objekte werden dann auch nachgerechnet.

Wie gesagt, das Problem ist wirklich nur die Variablenerstellung.

Liebe Grüße,

Stigma

[perdian]

das mag sein [...] Nur ist das nicht meine Idee gewesen

Na wenn ich merke die Anforderung ist falsch, dann sollte ich nicht einfach stur dennoch weitermachen sondern ruhig auch den Mut haben zu sagen "da gibt es abr einen besseren/schöneren/billigeren Weg ans Ziel zu kommen".umzusetzen.

Ich muss x variablen declarieren können [...] Wenn also 20 Objekte berechnet werden müssen, und der CURSOR 20 sagt, dann müsste ich auch 20 Variablen haben, die ich einzeln miteinander berechnen kann.

Was spricht dagegen einfach ein Array bzw. eine Liste zu nehmen und die entsprechenden Objekte dort hin zu packen?!

[flashpixx]

Also ich verstehe das Problem an sich nicht.

Wenn ich eine Menge an Daten brauche, dann erstelle ich diese per Select direkt (oder hinterlege dafür einen View). Nun kann ich mit meiner SP den View bzw das Result des Selects einfach verarbeiten.

Für mich ist eine "Menge an dynamischen Variablen" eine Liste (kein Array, da statisch), eine Liste ist nichts anderes als ein Resultset einer Tabelle / Statements (entweder horizontal als Spalten oder vertikal als Zeilen, spielt aber keine Rolle, da ich diese durch ein Pivot entsprechend drehen kann).

Phil

[dr.dimitri]

Die Datenbank sollte primär zur Datenspeicherung nicht zur Datenverarbeitung genutzt werden.

Dann verschenkt man grob geschätzt 50% von dem was ein moderner Datenbankserver leisten könnte.

Ich muss x variablen declarieren können, wieviel ich in einem cursor finde, da ich x Objekte mit einander vergleichen muss.

Das hört sich an, als ob Du versuchst etwas prozedural nachzuprogrammieren, obwohl es eigentlich in SQL gelöst werden könnte. Wenn die Daten über einen Cursor geliefert werden, dann hast Du ja schon mal zwei SQLs als Grundlage. Jetzt hängt es nur noch davon ab, was Du genau vergleichen möchtest und vor allem wie die Ergebnismenge aussehen soll.

Dim

[perdian]

Dann verschenkt man grob geschätzt 50% von dem was ein moderner Datenbankserver leisten könnte.

Ansichtssache. Ich denke das in freier Wildbahn sehr vieles (lies: nicht alles!) von dem, was über Stored Procedures gemacht wird mindestens genauso gut (tendenziell sogar besser) ausserhalb der Datenbank zu lösen ist. Der Nachteil bei Stored Procedures ist immer, dass ich sie synchron zu meinem restlichen Programm halten muss und sicherstellen muss, dass auf allen ähnliches Systemen (Development, Test, Staging, Produktion, ...) immer die aktuellste Version zu finden ist.

Ich sage nicht, dass es immer und überall unnütz und überflüssig ist - mit Sicherheit ist es das nicht - aber ehe man freudestrahlend denkt "wow super, das kommt auch in die DB" sollte man doch zunächst überlegen ob es wirklich genau dort sinnvoll aufgehoben ist.

[flashpixx]

Ich sage nicht, dass es immer und überall unnütz und überflüssig ist - mit Sicherheit ist es das nicht - aber ehe man freudestrahlend denkt "wow super, das kommt auch in die DB" sollte man doch zunächst überlegen ob es wirklich genau dort sinnvoll aufgehoben ist.

Ich will einmal dazu ergänzen, dass viele noch dem Glauben anhaften, dass man alles in die Anwendung programmieren muss. Meisten werden 2- bzw 3-schichtige Architekturen noch nicht voll ausgereizt. Zu @Dim muss man definitiv noch ergänzen, dass man häufig "dicke" DBMS Abwärme produzieren lässt, als diese wirklich voll auszureizen.

Zu dem Aspekt der Synchronität von @perdian sehe ich da keine Einwände. Ich habe ein Testingsystem evtl sogar mehrere, ein Produktivsystem und auch andere Systeme. Während der Entwicklung kann es immer irgendwo Probleme geben, aber das ist letztendlich ein Kommunikationsproblem. Ob das Problem nun in einer DLL oder in der Datenbank liegt, ist letztendlich gleich

Phil