MySQL Builder Library

Wichtiger Hinweis: Bitte ändert nicht manuell die Schriftfarbe auf schwarz sondern belasst es bei der Standardeinstellung. Somit tragt ihr dazu bei dass euer Text auch bei Verwendung unseren dunklen Forenstils noch lesbar ist!

Tipp: Ihr wollt längere Codeausschnitte oder Logfiles bereitstellen? Benutzt unseren eigenen PasteBin-Dienst Link
  • Hallo, viele von euch kennen das Problem mit den langen MySQL Querys und das es sehr unübersichtlich ist.


    Aus diesem Grund habe ich mal eine kleine Library geschrieben womit man einfach diese Querys erzeugen lassen kann.


    Funktionen:


    native MySQL_Insert(handle,const rows[][],const target_Table[],const form[],{Float, _}:...);
    native MySQL_Update(handle,const rows[][],const target_Table[],const where[], const form[],{Float, _}:...);


    Beispiel:


    //Unter OnGameModeInit
    handle = mysql_connect(...);



    //Oben ins Skript:
    stock const rows[][] = {
    "`Geld`","`Alter`","`X`","`Name`" //Hier sind die Spalten Namen, wichtig sind hier die `
    };
    //Dann da wo Ihr den User registriert (INSERT INTO) benötigt:
    new money = 5000,alter=16,Float:x=3.141,name[] = "Test123"; //Das sind Beispiel Daten zum speichern

    MySQL_Insert(handle,rows,"Test","ddfs",money,alter,x,name);
    /*
    "Test" = Der Tabellen-Name
    "ddfs" = Die Form (die Reihenfolge der Datentypen) d=Integer,f=Float,s=String
    */



    //Angenommen wir wollen jetzt den Spieler nur noch Updaten:
    new money = 9500,alter=16,Float:x=3.141,name[] = "Test123";


    MySQL_Update(handle,rows,"Test","Name","ddfws",money,alter,x,name);
    /*
    "Test" = Wieder der Tabellen Name
    "Name" = Das Where Statement.
    "w" = Das w in dem Format gibt an, dass das nachfolgende das WHERE Statement ist (und s dahinter der Typ halt von dem).
    */


    Mehrere Where Statements:


    new money = 9500,alter=16,Float:x=3.1412,name[] = "Test123";

    MySQL_Update(handle,table,"Test","Name|Alter","dfwswd",money,x,name,alter);


    Download:
    Source-Code: Pastebin
    Direkter-Download: MediaFire


    mfg. :thumbup:

    ast2ufdyxkb1.png


    Leute, lernt scripten und versucht mal lieber etwas selber zu schreiben, als es aus einem GF zu kopieren. :S

  • Die Idee dahinter, die Queries kürzer zu gestalten, ist zwar gut, aber die Umsetzung ist meiner Meinung nach nicht gut. Das liegt wohl auch daran, dass so ein Query einfach nicht kürzer gemacht werden kann als es ist, oder zumindest kaum.
    Grundsätzlich würde ich MySQL Anfängern, an die dies wohl gerichtet ist, strengstens davon abraten, dies oder ähnliches zu nutzen, da sie so das Prinzip MySQL nicht lernen. Außerdem sehe ich keinen wirklichen Vorteil in diesem System.


    Warum?

    • Mehr Code
    • Langsamer
    • Fehleranfälliger (vor allem wenn der String von 1024 voll ist und man es nicht merkt)
    • Funktionseinschränkend (OR geht zum Beispiel nicht)
    • Unübersichtlicher als ein ganz normales Query
    • Schlechte Wartbarkeit/Allgemeinverständlichkeit (niemand weiß, dass Name|Alter für Name und Alter steht, da hätte ich wenigstens & genommen)


    Zudem kommt, dass wenn man mehrere Queries hat, die unterschiedliche Spalten in derselben Tabelle ändern, dann muss man die "rows" Variable für dieses Query jedes mal, bzw. oft, neu anlegen, das ist Speicherverschwendung, wenn man in Betracht zieht, dass kein wirklicher Vorteil dabei entsteht.


    Außerdem fehlt beim Insert die Möglichkeit ein Callback aufzurufen, mit welchem zum Beispiel die neu eingefügte ID (A_I) über den Cache ausgelesen werden kann.

  • Mehr Code


    Also eine simple Zeile ist länger, als 6 Zeilen wo man mit jedem Komma und jedem Sonderzeichen zu kämpfen hat...ok


    Langsamer


    Bei 100 Aufrufen...1ms


    Fehleranfälliger


    Eigentlich ja eher nicht.
    Wieso auch....wenn man es so macht wie ich es gezeigt habe, werden eben keine Fehler auftreten, dafür ist es ja da...man muss sich mit den Kommas etc nicht mehr rumplagen und es wird ja geprüft ob Spalten & Anzahl der Attribute übereinstimmt :)


    PS: Wenn String > 1024 kann man ihn erhöhen, das steht dann in der Konsole, genauso die anderen Fehlermeldungen...


    Unübersichtlicher als ein ganz normales Query


    Du findest eine Zeile wo du klar siehst welche Variable zu was gehört unübersichtlicher als 6 oder mehr Zeilen, die voll geschrieben sind mit Sonderzeichen und Feldern...alles klar ?(


    Schlechte Wartbarkeit


    Wieso? Wenn was nicht funktioniert...muss es ja an einem der 2 Kriterien liegen...eigentlich ist das eine sehr gute Wartbarkeit


    Allgemeinverständlichkeit (niemand weiß, dass Name|Alter für Name und Alter steht, da hätte ich wenigstens & genommen)


    Es stehen beide Zeichen indirekt dafür:


    new x,y,z
    if(x | y | z) //Hier geht der Compiler auch durch alle Variablen, anstatt bei der 1. falschen abzubrechen ^^



    Zudem kommt, dass wenn man mehrere Queries hat, die unterschiedliche Spalten in derselben Tabelle ändern, dann muss man die "rows" Variable für dieses Query jedes mal, bzw. oft, neu anlegen, das ist Speicherverschwendung, wenn man in Betracht zieht, dass kein wirklicher Vorteil dabei entsteht.


    Ich hoffe dir ist bewusst, dass man nicht gezwungen ist diese Funktionen zu verwenden, aber in den Meisten Fällen kann dies sehr praktisch sein.


    Um noch etwas anzumerken das MySQL Query von BlueG/ maddinator beinhaltet das ORM - System, damit spart man sich genug Zeit.


    Joa das ist ja jedem selbst überlassen :)

    ast2ufdyxkb1.png


    Leute, lernt scripten und versucht mal lieber etwas selber zu schreiben, als es aus einem GF zu kopieren. :S

  • Also eine simple Zeile ist länger, als 6 Zeilen wo man mit jedem Komma und jedem Sonderzeichen zu kämpfen hat...ok


    Du hast das Array mit den Spalten, das macht es im Endeffekt mehr Code. Da jedes Query unterschiedlich ist, muss ich für jedes Query die Spalten neu dort angeben, das macht es eher mehr Code, als weniger.


    Eigentlich ja eher nicht.
    Wieso auch....wenn man es so macht wie ich es gezeigt habe


    MySQL_Update(handle,rows,"Test","Name","dfws",money,x,name);
    oder:
    MySQL_Update(handle,rows,"Test","Name","dfws",alter,x,name);
    Auf den ersten Blick sehe ich hier nicht, welches davon richtig ist, und welches falsch ist. Sowas kann schnell passieren und man merkt es nicht. Das bezieht sich auch auf die Wartbarkeit. Ich muss immer hin und her scrollen, zwischen dem rows Array und der Zeile hier, um herauszufinden, dann entweder alter oder money richtig ist. Bei einem Query mit 100 Attributen wird das lustig.


    Du findest eine Zeile wo du klar siehst welche Variable zu was gehört unübersichtlicher als 6 oder mehr Zeilen, die voll geschrieben sind mit Sonderzeichen und Feldern...alles klar ?(


    Also ich sehe da nichts klar, da ich immer hin und her scrollen muss, wenn ich wissen will, welcher Wert denn nun kommt.
    Da bevorzuge ich sowas:
    format(query, sizeof(query), "UPDATE users SET ");
    format(query, sizeof(query), "%s `Alter` = '%i', ", query, pInfo[playerid][pAlter] );
    format(query, sizeof(query), "%s Personalausweis = '%i', ", query, pInfo[playerid][pPerso] );
    format(query, sizeof(query), "%s Spawnchange = '%i' ", query, pInfo[playerid][pSpawnchange] );
    format(query, sizeof(query), "%s WHERE id = '%i' ", query, pInfo[playerid][pDB] );
    Da sehe ich ganz genau, was zu was gehört.


    Es stehen beide Zeichen indirekt dafür:


    Nur weiß das kaum einer.


    Ich hoffe dir ist bewusst, dass man nicht gezwungen ist diese Funktionen zu verwenden, aber in den Meisten Fällen kann dies sehr praktisch sein.


    Natürlich bin ich mir dessen bewusst, ich habe lediglich meine Meinung und mögliche Probleme dargestellt. Ich finde nicht, dass es praktisch ist, da wie gesagt jedes Query unterschiedlich ist (hätte ich zwei mal das gleiche Query, könnte ich es über eine Funktion lösen), daher ist es im Endeffekt mehr Schreibarbeit und vor allem bei langen Queries wird das ziemlich unübersichtlich, wenn du da sowas stehen hast:
    MySQL_Update(handle,rows,"Test","Name","dddfdfdsfsdfdfdfdsfdfddddddddddfdfsdfdfdfdfdfdsssdddddddddddddddddddddddddddddddddddddws",...);
    Das wird ein Spaß herauszufinden, welche Spalte dann vielleicht den falschen Typ hat oder ob vielleich doch eine Spalte fehlt. Das passiert dir bei der Methode oben nicht, und wenn, dann siehst du es sofort ;)

  • Du hast das Array mit den Spalten, das macht es im Endeffekt mehr Code. Da jedes Query unterschiedlich ist, muss ich für jedes Query die Spalten neu dort angeben, das macht es eher mehr Code, als weniger.


    Dir sollte bewusst sein, wenn du meinen Text gelesen hast, dass es nur um das Speichern z.B. von Spielerdaten o.ä. geht.


    Und da reicht es 1x die Tabellen Struktur zu deklarieren, somit es es wesentlich weniger Code!


    Auf den ersten Blick sehe ich hier nicht, welches davon richtig ist, und welches falsch ist. Sowas kann schnell passieren und man merkt es nicht. Das bezieht sich auch auf die Wartbarkeit. Ich muss immer hin und her scrollen, zwischen dem rows Array und der Zeile hier, um herauszufinden, dann entweder alter oder money richtig ist. Bei einem Query mit 100 Attributen wird das lustig.


    Dir ist klar, dass es bei dem normalen format nicht anders ist du scherzkeks.


    Zudem kann man sich die Struktur auch dahin als Kommentar schreiben...


    Da sehe ich ganz genau, was zu was gehört.


    Das ist aber langsamer...
    und wie gesagt...die Struktur kann man angeben, das nicht so kompiziert als kommentar...


    Nur weiß das kaum einer.


    Ändert nichts an der Tatsache...


    Queries wird das ziemlich unübersichtlich


    Nun, wenn man es 1x am Anfang richtig gemacht hat...ist es sehr einfach weitere dazuzutun.
    Man muss das halt schritt für schritt machen, aber dafür ist es wesentlich einfacher, neue Sachen leicht hinzuzufügen.


    und ein normales Query in diesem Maße ist noch viel unübersichtlicher...


    Aber wie gesagt..ist jedem selbst überlassen wie er es macht...


    Ein paar Leute wollten so eine Include, also habe ich sie Ihnen zur Verfügung gestellt, ich verstehe dein Problem damit nicht.

    ast2ufdyxkb1.png


    Leute, lernt scripten und versucht mal lieber etwas selber zu schreiben, als es aus einem GF zu kopieren. :S

  • Und da reicht es 1x die Tabellen Struktur zu deklarieren, somit es es wesentlich weniger Code!


    Dann erkläre mir doch bitte mal, wie ich mit einer Struktur das hier hinbekommen soll:


    In einem Timer:
    MySQL_Update(handle,rows,"Test","Name","dfws",money,x,name);


    Beim Registrieren:
    MySQL_Update(handle,rows,"Test","Name","dfws",alter,x,name);
    So geht es ja offensichtlich nicht.



    Zum Rest:
    Ich spare mir die Zeit mit dir zu diskutieren, da das ohnehin nichts bringt. Meine Meinung kennst du, die kannst du akzeptieren oder auch nicht, das ist mir egal.
    Die Verwendung empfehle ich aus genannten Gründen so keinem.

  • In einem Timer:


    Wofür brauchst du bitte einen Timer? :huh:


    Man muss die Daten doch nur 1x beim Ausloggen speichern...und da ist es immer wieder die selbe Struktur.


    Und bei Registrieren muss man halt 1x einen Insert Query ausführen und der hat natürlich auch die selbe Struktur.


    Für triviale kleine Querys, brauchst du das natürlich nicht verwenden...


    Mein Gott :rolleyes:

    ast2ufdyxkb1.png


    Leute, lernt scripten und versucht mal lieber etwas selber zu schreiben, als es aus einem GF zu kopieren. :S

  • Man muss die Daten doch nur 1x beim Ausloggen speichern


    Dann crasht der Server aus und alle Daten der Spieler wurden nicht gespeichert.


    Es ist und war noch nie sonderlich klug die Spielerdaten nur beim Ausloggen zu speichern.
    Das macht evtl. vereinzelt Sinn, aber man sollte nicht auf die Idee kommen, den Spieler wenn er sich ausloggt komplett zu speichern.


    Ich will gar nicht wissen wie du deine querys schreibst, wie Jeffry: schon sagte, es gibt kaum Fälle in dem man deine Libary nutzen könnte,
    außer man speichert wirklich auf Teufel komm raus den Spieler nur beim ausloggen.


    Ansonsten muss man sich die Struktur für jedesmal anlegen - ist dann doch etwas sehr aufwendig.


    Wenn man sowas schon anbietet, dann sollte das auch einen allgemeinen nutzen haben.
    Aussagen wie "du musst es ja nicht nutzen", sind für's Ego vielleicht sehr schön, für die Allgemeinheit leider unbrauchbar.


    Dann kann man sich die Veröffentlichung auch sparen, wenn man sowieso auf Meinung anderer nichts gibt-

    "Bevor ich mir Informationen aus der "Bild" hole,
    werde ich anfangen, Wahlergebnisse danach vorauszusagen,
    neben welchen Busch unsere Katze gepinkelt hat."

    Margarete Stokowski

  • Wofür brauchst du bitte einen Timer?


    Meister, das war ein Beispiel.



    Prinzipiell sagst du also, deine Include ist für genau 2 Queries gedacht, und dafür hast du 2 Funktionen erstellt (wovon der Insert nur halbwegs was taugt, da keine Rückgabe geschieht). Das macht keinen Sinn. Wenn ich 25 Queries nach Standard schreibe und dann eines mit der Include.
    Zudem, wenn ich es für fast nichts verwenden kann, dann bringt es ja nichts.

  • Ansonsten muss man sich die Struktur für jedesmal anlegen - ist dann doch etwas sehr aufwendig.


    Wieso? :huh:


    Darum geht es doch gerade, dass man das nicht muss...


    Weil wenn du die Tabelle speicherst...hat die Tabelle an sich doch immer die selbe Struktur :wacko:


    Wenn man sowas schon anbietet, dann sollte das auch einen allgemeinen nutzen haben.


    Was redest du da? Es hat doch einen allgemeinen nutzen...


    Aussagen wie "du musst es ja nicht nutzen", sind für's Ego vielleicht sehr schön, für die Allgemeinheit leider unbrauchbar.


    Achso...da man jedes Tool nutzen muss...was redest du hier für einen Schwachsinn? :huh:


    Dann kann man sich die Veröffentlichung auch sparen


    Ok...sobald ein paar Leute ein Tool nicht brauchen, kann man sich die Veröffentlichung sparen...ja ne ist klar..


    Zudem, wenn ich es für fast nichts verwenden kann, dann bringt es ja nichts.


    Das kommt ja darauf an...wenn man viele Querys auf einzelne Tabellen macht, dann bringt diese Include sehr viel...da sie die ganzen Query strukturen übersichtlicher und einfacher macht.


    Wenn man immer nur 1x etwas in eine Tabelle schreibt, dann ist es trivial, aber das ist es im seltesten Fall.


    Das mit dem Rückgabe Wert vom Insert, kann ich leider nicht so ohne weiteres handhaben, da das extrem die Nutzbarkeit von den cache Callbacks einschränken würde...


    Wie dem auch sei...ich wollte es für ein paar Personen zur Verfügung stellen...dass ihr es komplett nutzlos findet...ist euer Ding...manche evtl nicht.


    mfg. :rolleyes:

    ast2ufdyxkb1.png


    Leute, lernt scripten und versucht mal lieber etwas selber zu schreiben, als es aus einem GF zu kopieren. :S

  • wenn man viele Querys auf einzelne Tabellen macht, dann bringt diese Include sehr viel...da sie die ganzen Query strukturen übersichtlicher und einfacher macht.


    Wie gesagt, das sehe ich aus genannten Gründen nicht so. Mehr werde ich dazu auch nicht mehr sagen, entweder du akzeptierst meine Meinung zu dem "Tool" (?) oder nicht, das bleibt dir überlassen. Meine Meinung bleibt die gleiche.

  • An sich ist die Idee ja gut, aber in Pawn meiner Meinung nach nicht so schön umsetzbar, da fehlt Pawn einfach der Zusammenhang zwischen einzelnen Sache.
    Nen QueryBuilder würd ich wenn ehr "Objektorientiert" sehen...

    Code
    Pseudocode:
    select = neuer Select_Query
    select.addReturn(foo)
    select.table(baar)
    select.where(foo,=,baar)
    select.limit(1)
    select.execute


    Irgendwie sowas, das Problem ist eben das man es in Pawn nur extremst schwer umsetzen kann. So gut ich die Idee finde, es ist in Pawn einfach nicht sauber und sinnvoll umsetzbar, sodass auch "Noobs" damit arbeiten können. Bei deinem System besteht eben die Gefahr, das es unübersichtlich wird und auch Spalten geändert/hinzugefügt werden können, die garnicht gewollt sind.

    Mit freundlichen Grüßen
    Developer
    Go/Python Developer | ehm. Webdeveloper | Fachinformatiker Anwendungsentwicklung
    Arbeitet in einem cloudigen Umfeld bei einem der größten deutschen Rechenzentrumsbetreibern