performance

[chrissi11]

hi liebe leute,

ich mal wieder..diesmal hab ich ein anderes anliegen.
weiß garnicht so recht ob die rubrik hier richtig ist..naja..

da hab ich mal wieder ne mehr oder weniger gute idee..
für meine community wollte ich so eine art helpguide machen.
so wie man sie bei knuddels in etwa kennt.

nach gewissen erfahrungspunkten, bestimmten aktivitäten will ich so ein
hilfeguide aufrufen lassen.

da aber hierfür immer ein read/write benötigt wird stellt sich mir die frage ob
das nicht die datenbank sprengen könnte.

ich hätte jetzt zum beispiel folgende idee

eine tabelle mit folgenden inhalt:

1.)
firstlogin = 0
messagefirst = 0
profileviewfirst = 0
usw halt..

2.)
wenn punkt zwischen x und x dann folgender tipp usw..

jetzt wird ja ständig gelesen ob der user beispielsweise zum ersten mal eingeloggt ist oder nicht.
das gleiche immer wieder dann wenn er eine nachricht schreiben will.
genauso wie wenn er ein profil aufruft usw..

hier stellt sich mir die frage, da ich bei den first aufrufen den wert auf 1 setzen muss um diesen speziellen punkt auszuschließen ob sich das nicht auf die performance bemerkbar macht. gehen wir mal von 10000 aktiven usern aus, nru so als beispiel..oder mehr sogar.. dann liege ich rechnerisch bei 3 optionen bei 3x 10000 = 30000 einträge allein nur für die überprüfungen..

dan habe ich eine tabelle die an die denk ich mal gigabyte groß werden wird, oder irre ich mich?

gibt es vielleicht andere alternativen? wäre jetzt so erstmal mein gedanke gewesen das so umzusetzen..

viele grüße

[AmicaNoctis]

Hallo,

ich bin nicht sicher, ob ich alles zu 100% verstanden habe, aber alle Prüfungen musst du nicht noch einmal machen. Du kannst ja einige Daten in der Session ablegen.

Davon abgesehen kann man viele Prüfungen in einer Abfrage mit Joins und entsprechenden Where-Klauseln zusammenfassen. Die Abfrage braucht dann nur unwesentlich länger, aber dafür machst du nur einen Round-Trip zum DBMS statt mehrerer.

Gruß,

Amica

[chrissi11]

hi, danke für die antwort.

aber wieso soll ich das in einer session speichern?
sessions haben doch keine unendliche lebensdauer!?
beim nächsten login fängt das ganze dann ja von vorne an.

[AmicaNoctis]

beim nächsten login fängt das ganze dann ja von vorne an.

Das ist klar, aber wenigstens machst du es nur beim Login und nicht bei jedem einzelnen Aufruf innerhalb einer Sitzung.

[chrissi11]

ja, aber wie schließe ich dann in der nächsen sitzung ein ob der user z.b das erste mal auf der nachrichten seite ist? ohne in die db zu schaun?!

weißt du was ich meine?

achsoooo..jetzt weiß ich was du meinst..

du meinst also einmal alle daten auslesen und ab in sessions damit..?!

[AmicaNoctis]

Kannst du nicht. Das sind persistente Daten, für die du in die DB schauen musst und das ist auch gar nicht schlimm. Wofür hättest du denn sonst eine DB, wenn du sie nie benutzt?

Edit zu deinem Edit: Genau, beim Login die komplexen und transienten Daten (nicht wirklich alles) in der Session halten und verwalten. Daten, die aber dauerhaft gespeichert werden sollen, sofort in die DB schreiben. Da kommt es jetzt natürlich auf den konkreten Anwendungsfall an, wann was davon Sinn macht.

[chrissi11]

ja ok, das ist dann soweit klar..
aber, da sind wirklich viele dieser einstellungen die verwaltet werden müssten.
wenn es ca so an die 100 tipps sind, dann liege ich da jeweils bei 100 verschiedenen einstellungen.. und das mal nur auf 10 user betrachtet ist das eine enorme datenmenge die im laufe der zeit zusammenkommt..weil pro user sinds ja dann schließlich 100 einträge..

macht das wirklich sinn? oder gibts da keine bessere lösung? ich will mir ned unbedingt nen extra server mit 10 x 10 terrabyte nur für diese sache zulegen um es mal zu übertreiben..aber ich komm schon auf eine große datenmenge oder nicht?

[AmicaNoctis]

Das klingt, als wäre das nicht wirklich sinnvoll normalisiert. Diese 100 Tipps liegen in einer DB-Tabelle und die 10 User in einer anderen. Eine dritte Tabelle verwaltet die Zuordnungen. Wenn jedem der User alle Tipps zugeordnet sind (worst case), sind das zwar 1000 Datensätze in dieser dritten (Zuordnungs- oder n:m-Relation), aber da stehen dann nur Zahlen drin, also brauchst du keinen Terrabyte-Server.

[onemorenerd]

Genügt nicht auch ein Bitfeld in der Usertabelle?

[AmicaNoctis]

Genügt nicht auch ein Bitfeld in der Usertabelle?

100bit Breite? Das passt ja nicht einmal in bigint unsigned rein und ein varchar-Feld dafür wäre auch Blödsinn. Dazu kommt, dass es nicht vernünftig erweiterbar ist. Mit Normalisierung hätte das dann nichts zu tun.

[onemorenerd]

Warum denn nicht mit varchar?

User loggt sich ein, Bitfeld wird aus der Usertabelle in die Session geladen.
Applikation will wissen, ob User sich zum ersten Mal einloggt: Steht firstlogin Bit im Bitfeld auf 0, ist es der erste Login. Ganz ohne Query!
Bit für firstlogin wird auf 1 gesetzt und entweder direkt in die Usertabelle zurück geschrieben oder beim Session-Destroy.

In der Applikation muss es für jede Aktion eine Konstante geben, die auf die zugehörige Position im Bitfeld zeigt. Das ist erweiterbar und eine sinnvolle Abweichung von der Normalisierung nach Lehrbuch.
Dass die Applikation irgendeine Zuordnung enthält, lässt sich nicht vermeiden. Entweder sind es Bitfeldpositionen oder IDs in einer Tabelle. Das nimmt sich nichts.

[AmicaNoctis]

Warum denn nicht mit varchar?

In diesem Fall ja, aber ich dachte, es geht um die Tipps. Dahingehend ist mir die ganze Anfrage nicht vollends klar geworden.

[chrissi11]

naja, es geht ja auch um die fragen..so wie du beschrieben hast mit dem tabellenaufbau hatte ich es auch vor, davon mal abgesehn.
mir gehts ja nur um die 1 und die nullen.so ganze fragen werden da nicht reinkommen. das handle ich dann mit smarty aus.
gut, ich werde es mal so probieren und berichten wie groß die tabelle nach einem monat ist. probieren geht über studieren.

danke euch fürs mitdenken

achso..das feld werd ich mit binäry belegen? oder werden da bytes statt bits gespeichert?

[onemorenerd]

Welche Fragen? Welches Feld? Beschreibe deine Gedanken halbwegs nachvollziehbar!

[Quetschi]

@onemorenerd

obwohl ich eine Schwäche für derartige Vorgehensweisen(*) habe muss ich sagen, dass im hier gezeigten Fall ganz klar die Vorteile der klassischen "Lehre" überwiegen. Weiß man heute wirklich ob es bei 100 Tipps bleibt? Was ist wenn die Anzahl der Tipps irgendwann die Möglichkeiten von VarChar übersteigt? Zusätzliches VarChar? Dann muss wieder der Code angepasst werden. Einfach sauber normalisieren und muss keine Gedanken mehr daran verschwenden was in 5 Jahren ist.

*)
Die logischste Umsetzung dieser Vorgehensweise stellt in meinen Augen ein SET-Feld dar, da ich damit auch mal bequem mit FIND_IN_SET abfragen kann und mich nicht um Sachen wie z.B. korrekte Position des gesuchten Bits kümmern muss, 255 Kombinationsmöglichkeiten hat man damit ebenso, ich kann die Bits sozusagen "frei benennen" und weniger Speicher braucht es auch (max. 8 Byte vs. max. 256 Byte bei VarChar).
In meinen Augen spricht da nichts dafür sich mit VarChar das Leben schwer zu machen.