multiline - fähige Query-GUI für mySQL

TSc

TSc

Legendäres Mitglied
Hi!

Von MSSQL auf der Arbeit verwöhnt würde ich privat gerne auch mit mySQL 5.x stored procedures einsetzen.

Dafür bräuchte ich aber eine GUI die multlinefähige Querys unterstützt. phpMyAdmin scheint das wohl leider nicht...

Hat jemand einen Tip damit ich mir nicht selber ein Script basteln muss?

Gruß,
Tom

 
Bevorzugt als Script, da ich keinen Root-zugriff auf meinen Server habe.

Daher hab ich mir auch die mySQL GUI-Tools nicht näher angeschaut.

 
Dafür brauchst du auch keinen Root-Zugriff. mySQL sollte lediglich Verbindungen ausserhalb Localhost zulassen - natürlich mit einem entsprechend privilegierten Account.

Bietet Heute eigentlich jeder brauchbare Hoster an
laugh.gif


 
Gut, dann sprech ich meinen mal an.

Bisher war ich immer froh wenn mein Hoster eher paranoid war und nur localhost-Zugriffe zu lies.
wink.gif

Security for the win...


Mal sehen was die Jungs sagen, vieleicht haben sie ja auch schon eine implementierte Lösungen.
Der Support war bisher immer hervorragend.
 
Genauso wenig wie mySQL Query Browser wenn es ein einfaches Hosting paket ohne DB-Zugriff ausserhalb von local host geht...
wink.gif




Da es echt nur um das anlegen von SPs geht mach ich mir jetzt ein kleines mySQLi-Script in die ich das reinposten kann.

Der Resr der Adminsitration funktioniert ja soweit über myPHPAdmin.

 
Vielleicht denke ich gerade in zu großen Maßstäben, aber normalerweise baut man doch eher lokal oder auf Entwicklungswerkzeugen und schiebt nur die Releases bzw. Stable Versionen ins Netz. Also so entwickle ich zumindestens
smile.gif
 
Ändert ja nichts an meinem Problem - spätestenz wenn ich die Scripte auf die Produktivsysteme schiebe muss ich dort besagte multiline querys einmal ausführen, nicht wahr?
wink.gif


Und dazu kommt - ich nutze als Entwicklungsumgebung ein System das exakt gleich zum Produktivsystem aufgesetzt ist - indem ich zweimal das selbe Hostingpaket nutze, die Entwicklungsumgebung nur .htaccess-geschützt.

Ich meine es macht ja nur Sinn auf einem baugleichen System zu entwickeln/testen sonst habe ich bei Release eventuell mit ganz neuen Problemen zu kämpfen.

So the same problem here.
wink.gif




Aber das Problem hat sich erledigt.
Ich nutze ab sofort den SMQB.

Den small multiline query browser von TSc.
wink.gif

 
QUOTE (lerel @ Mo 2.11.2009, 15:46)Vielleicht denke ich gerade in zu großen Maßstäben, aber normalerweise baut man doch eher lokal oder auf Entwicklungswerkzeugen und schiebt nur die Releases bzw. Stable Versionen ins Netz. Also so entwickle ich zumindestens
smile.gif


Bei Systemen, die kontinuierlich online laufen, lohnt das überhaupt nicht.

Wenn ich innerhalb von Server-Daten neue Funktionen ergänze und dafür neue Systemspalten benötige, dann werden diese sofort online über alle Datenbanken dazugefügt. Das ist ohne Probleme im laufenden Betrieb möglich. Anschließend nimmt man sich eine Testdatenbank und entwickelt die Datenbank-Logik dazu. Falls zusätzliche Webserver-Logik benötigt wird, kann man die auf einem parallelen Online-System schrittweise entwickeln, das einfach auf einem anderen Port läuft.

Ist alles fertig, wird das rüberkopiert - das wars. Da die neue Funktion zu diesem Zeitpunkt noch niemand nutzt, stört das auch keinen Kunden.
 
QUOTE (Jürgen Auer @ Mo 2.11.2009, 15:10) Anschließend nimmt man sich eine Testdatenbank und entwickelt die Datenbank-Logik dazu. Falls zusätzliche Webserver-Logik benötigt wird, kann man die auf einem parallelen Online-System schrittweise entwickeln, das einfach auf einem anderen Port läuft.

Ist alles fertig, wird das rüberkopiert - das wars.

Ich schätze mal das es das war, was er mit einer Entwicklungsumgebung meinte...


 
QUOTE (TSc @ Mo 2.11.2009, 16:17)
QUOTE (Jürgen Auer @ Mo 2.11.2009, 15:10) Anschließend nimmt man sich eine Testdatenbank und entwickelt die Datenbank-Logik dazu. Falls zusätzliche Webserver-Logik benötigt wird, kann man die auf einem parallelen Online-System schrittweise entwickeln, das einfach auf einem anderen Port läuft.

Ist alles fertig, wird das rüberkopiert - das wars.

Ich schätze mal das es das war, was er mit einer Entwicklungsumgebung meinte...


Die Frage ist doch: Ist die Entwicklungsumgebung lokal / offline oder ebenfalls online. Den Beitrag von @lerel hatte ich so verstanden, daß die Entwicklung offline gemacht wird.


QUOTE (TSc @ Mo 2.11.2009, 16:07)Und dazu kommt - ich nutze als Entwicklungsumgebung ein System das exakt gleich zum Produktivsystem aufgesetzt ist - indem ich zweimal das selbe Hostingpaket nutze, die Entwicklungsumgebung nur .htaccess-geschützt.

Ich meine es macht ja nur Sinn auf einem baugleichen System zu entwickeln/testen sonst habe ich bei Release eventuell mit ganz neuen Problemen zu kämpfen.


Offenbar online.
biggrin.gif



Ich hatte früher auch gedacht (nachdem die Grundentwicklung vor Anmietung der Server lokal stattfand), daß ich für spätere Weiterentwicklungen ein Offline-System bräuchte. Bis sich dann schrittweise herausgestellt hat, daß das problemlos online geht und man damit sogar gerade Probleme vermeidet.

Damit benötigt man gewisse solcher interaktiver Tools online.
 
Wird zwar jetzt etwas Offtopic, möchte aber auch noch eine kleine Anmerkung loswerden;

Eine solche Frage wird man kaum global beantworten können - da spielen diverse Faktoren eine Rolle. Bei kleineren "Projekten" wo 1 oder 2 Personen dahintersteckten lohnt sich der Aufwand kaum. Ich denke hier kann man keinem böse sein wenn er so arbeitet..

Wir entwickeln ausschliesslich auf einer Testumgebung, egal wie gros/kleins das Projekt ist. Der Mehraufwand ist in meinen Augen minimal wenn die Umgebungen soewiso vorhanden sind.

Vorteile;

1.) Versionierung;
Sämtliche Änderungen/Erweiterunen werden Etappenweise entwickelt und in der Versionskontrolle (z.B. CVS) eingescheckt. Dazu gehören auch die manuell gebauten SQL Scripts die die entsprechenden Änderungen auf der DB erledigen.

2.) Zentrale Ablage;
Jedes von uns geführte Projekt ist auch abseits des Produktivsystems abgelegt. Wenn mal was ist - weiss jeder wo er das Projekt in seiner aktuellen Version findet.

3.) Qualitätssicherung;
So kann der Verantwortliche alle Änderungen noch Begutachten und validieren bevor sie auf das Produktivsystem gelangen. Dank der Versionskontrolle kann jede Änderung auch wieder verworfen werden.

Releases sind danach sehr einfach und schnell erledigt. CVS auschecken, Changescripts ausführen - fertig.

Ein weiterer Punkt ist auch, dass ab einer gewissen Projektgrösse die Entwickler und die Betreiber unterschiedliche Personen oder gar Firmen sind. Daher ist hier eine strikte Trennung der Umgebungen unumgänglich. Aber spätestens dann sollte man auch keine Probleme mehr mit Zugriffsmöglichkeiten/Rechten mehr haben
wink.gif


Freut mich für dich dass du eine Lösung gefunden hast.
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben