anpera.net
https://anpera.dyndns.org/phpbb3/

Accounts Tabelle & einbauen
https://anpera.dyndns.org/phpbb3/viewtopic.php?f=25&t=3666		 Seite 1 von 1
Autor:  Nightborn [ Sa 26 Mai, 2007 14:32 ]
Betreff des Beitrags:  Accounts Tabelle & einbauen
Okay, mir ist klar, es ist schönk, wenn man einfach $session['user']['plumpudding'] schreiben kann, anstatt einfach aus einer Tabelle Daten auszulesen.

Aber Fakt ist:

a) kracht es, und die accounts ist weg, backups sind nur halb da, dann darf man _jede_einzelne_einbauanleitung_nochmal_durchgehen
b) bei _jedem_ pagehit wird der ganze accounts eintrag eingelesen. wenn man jetzt hier fleißig dicke textfelder oder sonstiges "einbaut", dann kann man gleich dem Arbeitsspeicher seiner Kiste "adieu" sagen. wenn dann mal mehr als 2 online sind und fleißig klicken, schwitzt die kiste. die muß ja jedesmal den datensalat rumschubsen
c) leute können nicht einbauen. es ist so. viele führen stoisch einfach anweisungen aus. wenn ich sage "truncate accounts" in einer anleitung wird vielleicht einer bei der phpmyadmin warnung innehalten. vielleicht auch nicht.

okay, in 1.1.1 gibts module, wo das alles auch schon schnittstellen hat, und eigene tabellen.

ich *BITTE* daher, wie auch schon einige praktizieren, entweder ein "accounts_extra" oder ähnliches zu nehmen und DORT einfach "acctid" und die felder einzufügen...ODER
wie bei 1.x.x einfach "acctid - modname - feldname - wert" als felder/spalten zu nehmen, und dann so arbeiten...

man kann schnittstellen bauen um das mit funktionen immer abzugreifen.

JA, es kostet mehr abfragen ABER ihr verlagert aus der accounts.

wenn ihr irgendwas einbaut, wo in einem special ca in 0,1 % aller pagehits gebraucht wird, wird für *alle* spieler bei *jedem* pagehit *alles* geladen was ihr in der accounts dafür eingefügt habt.

*puh*
soviel zu meinem plädoyer.
Autor:  Harthas [ Sa 26 Mai, 2007 14:56 ]
Betreff des Beitrags: 
Diese Idee hatten wohl bereits einige hier. Ist nur nicht in der anpera.net-Version enthalten.

Ich bin momentan auch dabei, das ganze etwas zu verringern.
Unnötige Felder löschen, selten gebrauchte in extra Tabellen, Optimierung der jeweiligen Datentypen, u.ä.

Es bringt wirklich was. Und mich stört es ehrlich gesagt kaum, wenn ich immer wieder mal eine zusätzlich Abfrage einbringen muss. Okay, wenn es um Dinge wie Gold, Erfahrung, Level, Name oder solche geht (Hauptsache oft gebraucht), bin ich froh darüber, dass es in die Session gespeichert ist. Aber ansonsten kann vieles aus der originalen Accounts raus.

Finde ich zumindest *g*


Der Ansatz aus der 1.X.X klingt interessant. Werds mir auch mal etwas näher anschauen.
Autor:  Eliwood [ Sa 26 Mai, 2007 15:07 ]
Betreff des Beitrags: 
Ja, die Idee hatten wirklich schon einige hier. Das Problem ist, dass, wenn wir uns auf ne Schnittstelle einigen würden, die auch erst eingebaut werden müsste.. Und dann geht wieder das Chaos los (Ist nochmehr Chaos überhaupt möglich?).

Die Idee mit den "prefs" aus der >1.0 hatte ich schonmal in Silienta verwirklicht... Naja, das Problem war halt danach, dass wir vergassen, immer wieder die prefs zu löschen.

Alternativ gibts auch die Möglichkeit, nicht ständig "SELECT * FROM accounts" zu schreiben... Versteht einer, was ich meine? :D
Denn dann ist es egal. ^^ Wenn man den Select jeweils massschneidert.

Edit: 80 Spalten. Und dabei EINIGES gelöscht. o.o
Autor:  Harthas [ Sa 26 Mai, 2007 15:11 ]
Betreff des Beitrags: 
Man könnte in jeder Datei jeweils festlegen, welche Werte man abrufen möchte. Vielleicht über eine Funktion. Einige Werte könnte man fest notiert haben (Vielleicht in der Funktion selber, für Vitalinfo o.ä.) und den Rest dann jeweils bei Gebrauch rausholen?

Zumindest verstehe ich es so ^^
Autor:  Auric [ Sa 26 Mai, 2007 15:25 ]
Betreff des Beitrags: 
Ich für meinen Teil schaue derzeit auch, was sich beispielsweise in Objekte auslagern ließe, vor allem was den "user" angeht... hier könnte man vielleicht mit serialisierte übergabe der Daten durch die Session schon einiges reißen und standardmäßig nur die wichtigsten daten abruft und ansonsten eben get()-Funktionen zu verwenden. Das hätte zwar das problem, das es wohl einige unnötige querys gäbe, aber dem könnte man ja mit einer gesammelten Abfrage im Kopf des jeweiligen Scripts entgegenwirken..

Allgemein wäre eine überprüfung der Daten, die überhaupt gelsen werden sollten aber durchaus eine nützliche Lösung für alle - bleibt nur die Frage, wie sich das Realisieren ließe...
Autor:  Eliwood [ Sa 26 Mai, 2007 15:36 ]
Betreff des Beitrags: 
Auric hat geschrieben:
Allgemein wäre eine überprüfung der Daten, die überhaupt gelsen werden sollten aber durchaus eine nützliche Lösung für alle - bleibt nur die Frage, wie sich das Realisieren ließe...


Mit Disziplin und Konstanten oder Arrays.

[php]define('USER_SELECT_FIELDS', USER_FIELDS_SPECIALTYS | USER_FIELDS_SEENMASTER);

#...]

#Oder:
$user_select = array(
'specialty' => true,
'darkarts' => true,
'darkartuse' => true,
'seenmaster' => true,
);[/php]
Autor:  Harthas [ Sa 26 Mai, 2007 16:16 ]
Betreff des Beitrags: 
:EDIT:

Funktioniert leider doch nicht so, wie ich es mir gedacht hatte.
Autor:  Nightborn [ Sa 26 Mai, 2007 19:48 ]
Betreff des Beitrags: 
Problem bei der "wenn ich es brauche hole ich es" ... ist, daß einfach der $session['user'] immer mit "SELECT * " geholt wird... da müsste man dann tief bohren, und ich kenn Leute, die vergessen dann beim Einbauen von alten mods, daß sie ja da vorselektiert haben, und schon geht nix mehr.

Kompatibilitätsprobleme würde man damit schaffen.

Da eher wie Eli da schon gemacht hat so ein System.

Warum funktioniert es bei 1.x.x?
-> wird ein User gelöscht, kommt der hook delete_user... und da werden dann alle module prefs von dem gelöscht (bzw. bei mir dank modul in eine sicherskopie verpackt, man kann den user mit allen prefs in sekunden wieder herstellen - Modul charrestore von Eric)
-> brauche ich eine pref, rufe ich einfach get_module_pref("welche","welchesmodul") auf. Basta. Gibts auch mit set.

ich denke schon, daß es Sinn macht, da auch etwas zu programmieren.
Die delete user ist ja schon da, und einen Hook braucht man nicht notwendig, kann man sicher auch so lösen.

Dann hätte man beides: einbauen + flexibel mit Schnittstellen.

"was man braucht selektieren" ... müsste man *vor* dem Aufruf seines Codes wissen ,damit der das weiß... weil ein $session['user']['nochnichtgeladen'] bringt ja garnichts... ist array und war array. Das ist keine Funktion wo ich schauen kann "bist Du denn schon geladen"? - was übrigens bei 1.x.x gemacht wird (caching))
Autor:  Tidus [ Sa 09 Jun, 2007 14:55 ]
Betreff des Beitrags: 
Das hört sich alles für mich etwas verwirrend an, doch wäre es schon praktisch da es ja auch recht bequem ist alles per session user bazurufen von den befehlen her, wenn man das dann irgendwie aussuchen könnte was es nur laden soll oder was nicht wäre cool,

oder könnte man es so machen, das man es irgendwie einteilt in abschnitte ? für den wald usw. das man das dann z.b. nur diesen abschnitt auswählt oder ähnliches.. weis ich nciht ob das geht kam mir nur grad in den sinn..
Autor:  Nightborn [ Sa 09 Jun, 2007 16:46 ]
Betreff des Beitrags: 
Ja, so in der Art meinte ich.
Autor:  dragonslayer [ Mo 25 Jun, 2007 22:03 ]
Betreff des Beitrags: 
In Atrahor benutzen wir für diese Art der ja/nein settings ein Bitflag. Ein DB Feld mit int (32bit) wird immer mit dem bitwise & Operator ausgelesen und dem | Operator gesetzt.

Somit kann man 32 dieser Werte in einem DB Feld speichern.

Definiert werden die werte mit Konstanten
define ('janein_wert_1',2^0); //1
define ('janein_wert_2',2^1); //2
define ('janein_wert_1',2^2); //4
define ('janein_wert_1',2^3); //8
...
und dann
$session['user']['bitflag'] = $session['user']['bitflag'] | janein_wert_1
zum speichern und zum lesen
$bool_wert_1 = $session['user']['bitflag'] & janein_wert_1
Autor:  Nightborn [ Mi 27 Jun, 2007 08:31 ]
Betreff des Beitrags: 
bitflags sind auch nicht schlecht.

etwas schwer verständlich, da man die position wissen muß.
und ein << macht lustige ergebnisse =)

ich denke, accounts sollte eine klasse sein.
Seite 1 von 1 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/