SQL vs. PHP Session

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • SQL vs. PHP Session

    Hola,

    ich arbeite gerade an einem CMS. Für jede Funktionaität wird bisher in einer MySQL DB geschaut ob der User das entsprechende Recht hat. Das erzeugt natürlich unmenga an Queries. Bei einer kleinen DB und wenig Nutzern mag das noch nicht so wild sein aber sobald die Last größer wird leidet die Performance doch recht stark.
    Ist es vielleicht sinnvoller alle Rechte eines Users nur beim Login einmal in seine Session zu schreiben und dann nur noch zu überprüfen ob diese Session Variable gesetzt ist oder nicht?
    Wie verhält es sich wenn die Session recht groß wird und viele User gleichzeitig eingeloggt sind?
    Werden Sessions im RAM gespeichert oder wo genau liegen sie?
    Macht es von der Performance her Sinn Queries einzusparen indem man die Daten in der Session speichert?

    Fragen über Fragen. Leider habe ich dazu sogut wie nichts gefunden.

    Vielen Dank.

    gruß
    dan

  • #2
    Re: SQL vs. PHP Session

    Standartmäßig werden die Session in einem Cookie des Benutzers gespeichert der deine Seite besucht.

    Wobei du ja in der php.ini selbst noch bestimmen kannst ob die Session zwingend über die URI (mit) übergeben wird, was ich aber pers. nie machen würde.

    Ergo würde ich auf die Session bauen, ausser man bearbeitet Benutzerdaten beim Laufenden Besuch der Seite, dann bemerkt der angemeldete Benutzer erst die Veränderungen wenn seine Session abgelaufen/beendet wurde und für ihn eine neue gestartet wird.




    Sers
    Der Boris

    Kommentar


    • #3
      ich kann boris nur zustimmen.

      meine progs laufen auf session basierten rank-systemen und es geht super
      2 meiner pages:

      Kommentar


      • #4
        Ich kann da absolut nicht zustimmen, weil es absoluter unfug ist. Sessions werden NICHT im Cookie gespeichert. Lediglich die ID wird dort (oder eben in der URL , wo sie nur vorhanden sein sollte, wenn cookies nicht möglich sind) gespeichert um eine Identifikaton des Users zu ermöglichen.

        Kommentar


        • #5
          in dem punkt hast du recht. trotzdem ist es sinnvoller den rank in der session abzuspeichern (die ja LOGISCHERWEISE auf dem server ligt)
          2 meiner pages:

          Kommentar


          • #6
            ja klar.

            Kommentar


            • #7
              @Tobias

              findest Du es nicht besser die aktuellen Daten in der Session
              zu speichern und erst am Schluß (wenn definitiv klar ist, was wie
              geändert wird) die Daten in der db bzw. in den Dateien zu speichern?

              Kommentar


              • #8
                ok... wenn ich bezig auf ältere posts nehme werde ich ab sofort präsiser sein
                2 meiner pages:

                Kommentar


                • #9
                  Original geschrieben von TobiaZ
                  Sessions werden NICHT im Cookie gespeichert. Lediglich die ID wird dort (oder eben in der URL , wo sie nur vorhanden sein sollte, wenn cookies nicht möglich sind) gespeichert um eine Identifikaton des Users zu ermöglichen.
                  Hatte mich etwas unverständlich ausgedrückt

                  Trotzalledem halte ich daran fest bei einem CMS mit Sessions zu arbeiten.
                  Bei veränderungen kann man ja dann auch einfach die alten Sessionwerte mit den neuen veränderten Daten füttern, zb. wenn man seine Email Adresse ändert etc.



                  Sers
                  Der Boris

                  Kommentar


                  • #10
                    naja.. wie auch immer.. aber wenigstens sind wir was die topic-frage angeht einer meinung ;-)
                    2 meiner pages:

                    Kommentar


                    • #11
                      Re: SQL vs. PHP Session

                      Original geschrieben von dionysos
                      Werden Sessions im RAM gespeichert oder wo genau liegen sie?
                      Macht es von der Performance her Sinn Queries einzusparen indem man die Daten in der Session speichert?
                      Zu 1.) Sie werden als Dateien gespeichert. Sessions sind Arrays die einfach serialisiert (vgl. serialize) in ner Datei abgelegt werden.
                      2.) Ja definitiv.
                      Für alle die Fehler suchen, gibts gratis tolle Debuggingmöglichkeiten:
                      var_dump(), print_r(), debug_backtrace und echo.
                      Außerdem gibt es für unsere Neueinsteiger ein hervorragendes PHP Tutorial zu PHP 4 und PHP 5 (OOP)
                      Es heißt $array['index'] und nicht $array[index]! Und nein, das ist nicht egal!
                      Dieses Thema lesen, um Ärger im Forum und verzögerte Hilfen zu vermeiden.

                      Kommentar


                      • #12
                        Danke für die Antworten.

                        Die Session-Datei zu öffnen und den Wert auszulesen geht also schneller als ein SQL Query? Gilt das generell oder darf die Session eine gewisse Größe nicht überschreiten?

                        Kommentar


                        • #13
                          hmmm... wenn ich mal langeweile hab schreib ich ein benchmark... ;-)

                          aber bis dahin nimm mal ganz ruhig die sessions (ist auch weniger schreibarbeit)
                          2 meiner pages:

                          Kommentar


                          • #14
                            Die Session-Datei zu öffnen und den Wert auszulesen geht also schneller als ein SQL Query? Gilt das generell oder darf die Session eine gewisse Größe nicht überschreiten?
                            das möchte ich so pauschal nicht sagen.

                            ist natürlich auch eine frage der größe. ich geh einfach mal davon aus, dass du nicht auf jeder seite alle daten brauchst. ab einem bestimmten punkt macht es auf jeden fall sinn, bei der DB-variante zu bleiben, weil da nur die benötigten daten gezogen werden. eine query kostet schließlich nicht sooo viel performance.

                            zuletzt bleibt noch die möglichkeit eines eigenen handlers (der dann idr. auf die DB zu greift).

                            Kommentar

                            Lädt...
                            X