News: Interessante Neuerung in MySQL

MySQL 5.1.6 soll beliebige SQL-Skripte nach einem frei definierbaren Ausführungszeitplan automatisiert abarbeiten können.

http://dev.mysql.com/tech-resources/articles/event-feature.html

Ey supi.. muss wohl doch bald mal wieder nen Update fahren..

Danke woody

Klingt doch mal nützlich.

Habs mir jetzt nicht durchgelesen. Ist das sowas wie ein Cronjob für die DB?

CRON/AT für die MySQL datenbank

also ja

*will*
....
hoffe nur mein hoster updated das lieb und nett...

nur so als anmerkung ehe hoster mysql 5.1 haben wird php6 rauskommen - da wette ich drum

Kleine Umfrage: Wofür würdet ihr das verwenden?
Mir würden z.B. Aufräumaktionen innerhalb der DB einfallen (alte Daten löschen usw.)...

Gibt es äquivalente Features auch in anderen DBMS?

Kommt auf das Projekt drauf an.. Man kann diese Funktion ja für viellerei verwenden.
Backups, Löschen von temporären Daten (Aufräumen), Statistiken aufräumen/auswerten und für BGs könnte man hier sicher auch noch Interne Auswertungsscripts realisieren (z.B. Gehaltszahlungen in WiSims oder Rohstoffupdates in tickbasierten Strategiespielen).

das klingt äußerst brauchbar...
da kann man sich einige crons sparen

Da kann man sich nicht einige Crons sparen, da kann man sich ALLE crons sparen!

Denn mit den Extensions von Mysql 5 kann man ja neuerdings auch mit Stored Procedures / Triggern arbeiten. Konsequenz dessen: In PHP Steckt keinerlei Logik mehr - nur noch Ablauf, Überprüfung, Ausgabe.

Das heist: Die DB macht endlcih mal ihre Arbeit. Somit kannst du problemlos alles was über PHP Cron geschwüre läuft auch in der DB lösen.

Problem des ganzen: MySQL 5.0 und Stored Procedures ist wie Russisch Roulette... nicht zu empfehlen da unsicher, langsam und unstabil. Die Extension für Crons dürfte hier keine grossee Ausnahme sein.

Gruss

Was für Crons auch mächtig Performance spart.

Hab das ganze mal zu Tipps&Tricks verschoben, da passts besser hin.

Original von schokofreak
Problem des ganzen: MySQL 5.0 und Stored Procedures ist wie Russisch Roulette... nicht zu empfehlen da unsicher, langsam und unstabil. Die Extension für Crons dürfte hier keine grossee Ausnahme sein.
Gruss

Das höre ich das erste mal. Hast du da persönliche Erfahrungen gemacht oder nen Link dazu? Denn besonders bei Trennung von Webserver und Datenbank könnte man mit Stored Procedures ne Menge unnötige Kommunikation sparen.

Naja... mir fällt nur immer wieder auf, dass auf den offiziellen Tutorials erwähnt wird, dass Transaktionen korrupt hingeraten können. Zudem gibt es noch mehrere Bugs, welche im Bereich des ACID anzuordnen sind.

Wenn die Grundlagen nicht stimmen, wenn man nach nem Absturz unter Umständen die DB Integrität verliert so bedeutet das in meinen Augen genau eines: Komplexe, lange Updateprozesse ja nicht in der DB lösen...

Ansonsten hast recht: Es würde die Arbeit immens erleichtern.

Als erstes würde ich dann folgendes machen:

CREATE EVENT
Optimieren
ON SCHEDULE
EVERY 1 WEEK
DO
OPTIMIZE TABLE blaa

Unterstützt PHPMyAdmin das auch schon?

phpMyAdmin unterstützt den Optimieren-Tag aber nicht zu einem regelmässigen Zeitpunkt. Wenn dann muss man hierzu manuell auf nen Knopf drücken.

Ja, dass PHPMyAdmin Raparieren, analysieren, Optimieren usw. kann ist mir klar. Ich wollte wissen, ob es schon die Unterstützung für "CREATE EVENT" hat. Dem scheint laut deinem Beitrag nicht so :roll:

Wie soll phpMyAdmin das unterstützen, wenn die EVENT-Funktion noch nichtmal released wurde.
Es geht hier um eine Funktion in der Version 5.1.6. Aktuell gibt es erst 5.0.18 ..

Hmm. Wenn ich da jetzt nicht völlig was durcheinander bringe, kann man in phpMyAdmin JEDEN von der Datenbank unterstützten Befehl in das SQL-Feld eingeben und absenden.
Also sehr wohl auch CREATE EVENT sobald die benutzte Datenbank das unterstützt.. was aber noch eine Weile dauern wird...
Und bevor ich das in einer Produktivumgebung einsetzen würde, vergeht noch eine ganz Weile mehr....

Ohh, tut mir leid. Ich dachte, das wäre schon draußen, wie gesagt, ich hab mir das nicht so genau durchgelesen...

jupp, das ganze klingt sehr interessant, aber man sollte defintiv erstmal paar stable versionen nachher abwarten wie sich das ganze stabilitaetstechnisch macht (wie bei jeder db version halt ^^)

@Fornax, warum schreibst du dann was dazu wenn du dir nicht alles durchgelesen hast ?

Hmmm... mal ne Mini-Umfrage: Würdet ihr, falls ihr JETZT was neues anfangfen würdet - das mit diesen technologien tun?

Versteht mich nicht falsch, ich werde mit garantie nix neues anfangen... einfach mal aus interesse - wie gross schätzt ihr das Risiko ein, dass in ca. 1.5 Jahren noch keine stabile Version da ist?

Gruss

Also den EVENT-Tag würde ich sicher nicht integrieren..
Wenn ich etwas anfangen würde, würde ich schauen das ich MySQL 5 und PHP5 verwende (wobei ich da mein vServer langsam mal updaten muss).
Da ich generell mit Klassen arbeite wäre da eine Änderungen von z.B. jetzt einem MySQL-Command auch nicht so wild..

defintiv nein, ich würde weiterhin bei live anwendungen auf ne 4.1 setzen (wenns ne mysql sein soll), weil so trau ich der 5.0 noch net

Ich hab vor 4 Wochen auf 5 geupdated. Hab bisher noch keine Probleme feststellen können. Allerdings warte ich auch lieber ein paar Wochen, wie sich das ganze so entwickelt.

Nein,

wenn ich einen kompletten Neuanfang machen würde und die Möglichkeiten hätte, würde ich vollständig auf PostgreSQL oder SQL Server setzen.

Ich würde auch mindestens 6 Monate warten, bis ich eine Technologie live einsetzen würde.

naja wenn ich jetzt was neues anfangen würde, dann würd ich auch die neuste technologie nehmen. und wenn ich fertig bin gibts dann sicherlich 1 bis 2 patches, welche die mögliche instabilität beheben.

weiß nicht aber postgre würd ich nicht im spielebereich verwenden. dafür find ich db zu lahm.

Ja, guter Einwand. Ich würde mit der neuesten Technologie anfangen und hoffen, dass sie bis zum Release des Spieles einsatzbereit ist.

Original von KoMtuR
weiß nicht aber postgre würd ich nicht im spielebereich verwenden. dafür find ich db zu lahm.

Was ist das denn für eine Äußerung :roll:
Klingt so, als ob ein Browsergame die größte Herausforderung an ein DBMS sei O.o

Langsam würd ich bei Postgres nicht sagen... mich überzeugt das produkt mehr und mehr grundsätzlcih nimmer so...
Qualität, Doku, Community.
Von Leistung ist n BG ja meist kein Problem für die DB.

Gruss

Also PostGres ist sicherlich nicht Ideal für den Anwendungszweck in einem Browsergame.
Dort werden auf einer Connection nur wenige Abfragen ausgeführt (so 2 - max. 30), dafür sehr viele Connections hergestellt (eben eine pro Seitenaufruf).
Da hat PostGres schwächen und ist deutlich Langsamer als MySQL. Gleiches gilt auch für MaxDB.

MS SQL-Server ist da ähnlich schnell, allerdings sehe ich das Problem hier in der ersten Silbe des Namens. Oder gibts den auch für Linux-Maschinen?

Naja du kannst von Linux aus, mit PHP und Co, auf nen MS-SQL Server zugreifen, aber MS-SQL auf Linux laufen zu lassen geht nicht..

Original von Kampfhoernchen
Also PostGres ist sicherlich nicht Ideal für den Anwendungszweck in einem Browsergame.
Dort werden auf einer Connection nur wenige Abfragen ausgeführt (so 2 - max. 30), dafür sehr viele Connections hergestellt (eben eine pro Seitenaufruf).
Da hat PostGres schwächen und ist deutlich Langsamer als MySQL. Gleiches gilt auch für MaxDB.

Wenigstens einer versteht mich :roll:

Danke

Wenn interesse besteht, frag ich bei meinem alten Prakti-Betrieb mal an, ob ich die Benchmarkergebnisse veröffentlichen darf.

Original von schokofreak
Langsam würd ich bei Postgres nicht sagen... mich überzeugt das produkt mehr und mehr grundsätzlcih nimmer so...
Qualität, Doku, Community.
Von Leistung ist n BG ja meist kein Problem für die DB.

Gruss

der einzige flaschenhals ist die db bei mir..
Die fangt schon am rumzuspinnen wenn ich nur über 20 MB komm mit meiner db - liegt auch daran das ich nen webspace hab und keinen root, aber sonst braucht bei mir nix soviel zeit wie die db..

Allerdings verstehe ich icht ganz was der Nachteil von crons sein soll...
Hier ist mit Sicherheit ein compiliertes Programm schneller als eine Stored Prozedure, die im mysql hängt. Ich würde Trigger ja andersherum verwenden: Bei einem bestimmten Ereigniss sollen die ein externes Programm anschmeißen.
Außerdem sind die stored Prozedures doch nicht in der entsprechenden DB untergebracht, sondern global, oder? Das gefällt mir auch nicht wirklich...