Per AJAX, MySQL Tabelle auf neue Einträge prüfen + auslesen

    Schönen Rosenmontag zusammen ;)

    Hab ein kleines Problemchen.
    Ich möchte eine kleine Statusabfrage umsetzen.

    Eine dritte Person tippt z.B. Einträge in eine MySQL-Tabelle.

    Möglichst in Echtzeit, soll in meinem "Admin-Interface" angezeigt werden,
    wenn ein neuer Eintrag vorhanden ist. Zusätzlich will ich dann noch diesen Eintrag
    lesen können.

    Mit AJAX habe ich bis jetzt noch nie gearbeitet und weiss deshalb nicht wirklich bescheid.

    Eventuell könnte mir jemand mal ein, zwei Links zustecken, die mir da eine Lösung oder zumindest ein Tutorial bieten.

    Würde mich über eure Antworten freuen ;)

    Danke

    was du machen willst kostet viele ressourcen, soweit ich weiß.
    und jede aktualisierung via ajax bedeutet dann ne abfrage für die db.
    ich hab mich vor monaten mal mit sowas beschäftigen wollen.^^
    kam bis zum schlagwort server-push, aber hab dann aus zeitgründen nicht weitermachen können.
    wenn du mehr dazu erfährst poste es auch bitte hier, damit alle (besonders ich) was davon haben :)
    :mrgreen:

    ich hab momentan nämlich keine ahnung, wie man des möglichst ressourcen-schonend hinbekommen kann.
    aber zur theorie: wenn jemand was eingetragen hat muss ne flag gesetzt werden, dass es einen neuen eintrag gibt.
    wenn die flag gesetzt ist, muss ein php-script die abfrage starten und die infos von der db holen, diese nackich wie se sind ausgeben (evtl vorformatiert),
    damit deine ajax-funktion die daten ins html stopfen kann.

    Leute, ihr vergesst, dass wir hier von Webseiten reden. Webseiten werden abgerufen und stehen nicht im ständigen Kontakt mit dem Webserver. Das ist einfach so gedacht.
    Faken kann mer das natürlich. Das kannst du ganz billig machen, indem du neue Einträge markierst (wie is egal). In deinem Adminbereich oder was immer per Javascritp-Dauerschleife alle 2 Sekunden ne Abfrage. Ich hoff ma du bist gut mit Arbeitsspeicher bestückt.


    Das ganz geht auch ohne html5

    Nennt sich "Comet" und geht mit reinen Ajax auch

    ja genau, dann trägt a was ein und hält die connec offen, b liest es aus und hält die connec offen, wenns genug tun, is die maximale anzahl von verbindungen erreicht und der server macht dann was? er geht in die knie.
    html ist nicht dafür gemacht und es is nen performance-fresser

    Es geht doch nur darum, neue Einträge anzuzeigen - wofür da bitte eine connection aufrecht erhalten?

    Wenn es nur anhand der Einträge sein soll, muss man die Einträge irgendwie markieren wie jojo beschrieben hat. Oder man macht eine Prozedur die beim Insert getriggert wird. Dann muss man nur noch eine andere Tabelle abrufen die gesäubert wird beim auslesen. Oder man lässt bei der Prozedur die neuen Einträge (vllt. etwas gekürzt auf die 'interessanten' Daten) in ein File schreiben. Statt der Prozedur kann man ja auch eine eigene Eintrag-Maske basteln die eben das erledigt. Oder oder oder...

    Wegen Performance würde ich mir aufjedenfall keine Sorgen machen, soll doch nur im Admin-Interface passieren.

    Zitat von Grevas

    Es geht doch nur darum, neue Einträge anzuzeigen - wofür da bitte eine connection aufrecht erhalten?

    Wenn es nur anhand der Einträge sein soll, muss man die Einträge irgendwie markieren wie jojo beschrieben hat. Oder man macht eine Prozedur die beim Insert getriggert wird. Dann muss man nur noch eine andere Tabelle abrufen die gesäubert wird beim auslesen. Oder man lässt bei der Prozedur die neuen Einträge (vllt. etwas gekürzt auf die 'interessanten' Daten) in ein File schreiben. Statt der Prozedur kann man ja auch eine eigene Eintrag-Maske basteln die eben das erledigt. Oder oder oder...

    Wegen Performance würde ich mir aufjedenfall keine Sorgen machen, soll doch nur im Admin-Interface passieren.

    Auch sollte man nicht vergessen, dass sich diese Lösung sehr schlecht auf mehrere admin-user skalieren lässt


    synaptic: nicht zwangsweise, wie gesagt, man kann per Trigger Sachen direkt in ein File schreiben. Damit belastest du die DB nicht wirklich. Eine paar KB große .txt zu laden tut dem Provider garantiert nicht weh ;)

    @jojo: stimmt, müsste man halt etwas erweitern - wenn es auf mehrere User skalierbar sein soll - dann muss man den Stand der einzelnen User irgendwo speichern. Da kann man auch noch etwas tricksen. Aber ich glaube das geht irgendwann zu weit und lohnt einfach nicht^^, jenach Requirements ändert sich der Lösungsweg...

    Wenn die Änderungen nicht allzu oft passieren (nehm ich mal an bei einem status) sind lange Requests durchaus eine Option

    Das 1000 Request nicht gut für apache/mod_php sind ist klar aber hier bewegen wir uns ja in einem anderne Bereich
    1000 Request pro Sekunde wäre die andere Option, meist 999 unnötige versteht sich

    Wenn man db/sql verwendet braucht man nicht auf ein langsameres flatfile system zurückgreifen

    mfg