Hilfe zu Counter [Archiv] - 3DCenter Forum

Marcel

2002-11-24, 23:38:32

Originally posted by Crazy Aimer

1) Zugriffe heute
2) Zugriffe gestern
3) Zugriffe diesen Monat
4) Reloadsperre

Was brauch ich für Felder in meiner MYSQL-Tabelle ?
Wie realisier ich das mit der Reloadsperre am besten ?
Hat jemand eine Vorlage ?

Zum Zeitbezug brauchste ein Datums-Uhrzeit-Feld, und für die Reload-Sperre musst Du mitbekommen, dass der Aufruf in dieser Session schon war, sprich, beispielsweise ziehste 'ne PHP-Session auf und speicherst die Session-ID. Heuristische Alternative mit recht hoher Trefferquote wäre die IP statt der Session-ID.

Gruß,
Marcel

Kurgan

2002-11-24, 23:53:55

Originally posted by Marcel

Zum Zeitbezug brauchste ein Datums-Uhrzeit-Feld, und für die Reload-Sperre musst Du mitbekommen, dass der Aufruf in dieser Session schon war, sprich, beispielsweise ziehste 'ne PHP-Session auf und speicherst die Session-ID. Heuristische Alternative mit recht hoher Trefferquote wäre die IP statt der Session-ID.

Gruß,
Marcel

und leute mit fester ip werden nur einmal gezählt, auch wenn sie die seite jeden tag aufrufen :o

nene, seesion id mit verfallszeit is schon besser.
was die db angeht sag ich besser nix, da brech ich mir auch immer einen dran ab ..da gibts nicht umsonst fachleute für :D

Marcel

2002-11-25, 00:08:00

Originally posted by Kurgan
und leute mit fester ip werden nur einmal gezählt, auch wenn sie die seite jeden tag aufrufen :o

Deswegen auch: "heuristische Alternative". Hohe, aber nicht 100%ige Treffequote. Denn, so viele feste-IP-Surfer gibt's nu auch wieder nicht.
Man könnte, um das zu verbessern, noch 'n TimeOut für die IP mit rteinnehmen. An 'ne Session-ID kommt aber natürlich auch das nicht ran.

Kurgan

2002-11-25, 05:08:20

Originally posted by Marcel

Deswegen auch: "heuristische Alternative". Hohe, aber nicht 100%ige Treffequote. Denn, so viele feste-IP-Surfer gibt's nu auch wieder nicht.

das kommt wohl auf die site an ...hier im forum zb werden fest ip´s wohl die minderheit sein, aber bei einer firmenkundenseite ?

Originally posted by Marcel
Man könnte, um das zu verbessern, noch 'n TimeOut für die IP mit rteinnehmen. An 'ne Session-ID kommt aber natürlich auch das nicht ran.

ebent ..wozu die ip-hakelei (die nichtmal eindeutig ist wegen proxys etc) ..

so, jetzt macht der kurgie erstmal bubu ....
nacht zuschammen

Matthias2x

2002-11-25, 05:22:04

Ein Zugang über Proxy macht heutzutage aber auch nicht mehr allzuviel Sinn denn jede Menge HP`s setzen auf dynamische Inhalte.

Man läßt die IP einfach nach einer definierten Zeit verfallen, dann passt das schon denn ich glaube korrektes Sessionhandling ist nicht gerade etwas für einen Anfänger was er ja nach eignem Bekunden ist...

Crazy Aimer

2002-11-25, 14:04:33

Erstmal danke für eure Replys! :D

Ich hab jetzt mal folgendes probiert:
-hab in meiner DB eine Tabelle "counter" erstellt
-"counter" enthält zwei Felder: "ip" und "Zeit"
-wenn jemand auf meine Seite zugreift, dann speichere ich seine IP und die UNIX-Standartzeit in die Tabelle.
-Gesamtzugriffe sind dann alle Einträge in der Tabelle
-Zugriff heute sind alle von der aktuellen UNIX-Zeit - 24*3600

so mehr erstmal nich
Die frage, die ich mir stelle ist die, ob das so optimal wäre. Sicherlich kann die Tabelle fast unendlich lang werden und sooo viele Leuten kommen denk ich nicht auf der Seite ... ich frage mich daher, wie man das optimaler gestalten kann, ohne den Speicher zu startk zu belasten abgesehn davon, dass das Scripts dann den Server mehr und mehr belastet oder ?

Marcel

2002-11-25, 19:37:47

Originally posted by Matthias2x
[...] ich glaube korrektes Sessionhandling ist nicht gerade etwas für einen Anfänger was er ja nach eignem Bekunden ist...

Ich hab das Session-Zeug erst einmal programmiert, und erst habe ich nicht verstanden, weshalb es nicht funktionierte, und dann nicht, warum es nach einer kleinen Änderung funktionierte. Deswegen habe ich die IP-Lösung auch erwähnt, die müsste ziemlich geradeaus programmierbar sein.

Gruß,
Marcel

Marcel

2002-11-25, 19:41:57

Originally posted by Crazy Aimer
Erstmal danke für eure Replys! :D

Ich hab jetzt mal folgendes probiert:
-hab in meiner DB eine Tabelle "counter" erstellt
-"counter" enthält zwei Felder: "ip" und "Zeit"
-wenn jemand auf meine Seite zugreift, dann speichere ich seine IP und die UNIX-Standartzeit in die Tabelle.
-Gesamtzugriffe sind dann alle Einträge in der Tabelle
-Zugriff heute sind alle von der aktuellen UNIX-Zeit - 24*3600

... womit Du die der letzten 24h bekommst, nicht die von heute - ist aber auch sinnvoller, schließlich surfen machne Leute auch noch nach Mitternacht...

Originally posted by Crazy Aimer so mehr erstmal nich
Die frage, die ich mir stelle ist die, ob das so optimal wäre. Sicherlich kann die Tabelle fast unendlich lang werden und sooo viele Leuten kommen denk ich nicht auf der Seite ... ich frage mich daher, wie man das optimaler gestalten kann, ohne den Speicher zu startk zu belasten abgesehn davon, dass das Scripts dann den Server mehr und mehr belastet oder ?

Zwei Sachen fallen mir da ein: Zum einen eine vernünftige Abstimmung der Abfrageformulierung und der Erstellung von Indizes auf der Tabelle, zum anderen eine Löschquery, die vereinzelt aufgerufen wird (entweder über eine "Administrationsseite" oder eine Seite, die nicht ganz so oft, aber doch regelmäßig betrachtet wird) und alles, was älter als 24h ist, löscht.

Gruß,
Marcel

Crazy Aimer

2002-11-25, 20:54:13

Ja die Idee kam mir auch schon in den Sinn... die Frage iss nur, wie ich dann die Gesamtzugriff hinbekomm... extra Feld und dann die Anzahl der gelöschten immer dazurechnen?

Marcel

2002-11-25, 21:28:16

Ach ja, zählen wolltest Du ja auch noch...
Tststs, immer diese Jugend, kann den Hals nicht vollkriegen... ;-)

Bau 'ne zweite Tabelle, in der die Namen der einzelnen zu zählenden Seiten in der ersten und die Zähler davon in der zweiten Spalte stehen. Ach ja, die Seitennamen müssen natürlich auch in die erste Tabelle. Kannst, um die Geschwindigkeit zu optimieren, auch 'ne ID vom Typ Integer anstelle des Namens verwenden.

Crazy Aimer

2002-11-25, 21:43:34

Der macht aber dann kein Unterschied zwischen den Seiten, wenn ich alles per include() einfüge oder ?
Ich mein wenn ich nur hinbekomm würd, dass der alle Zugriffe speichert ohne den SQL-Server zu belasten.
Also nehmen wir an:
Ich speichere alle zugreifenden IPs der letzten 24*3600 Sekunden in einer Tabelle. In einem Extrafeld oder -tabelle speichere ich dann die Anzahl der Gesamtzugriffe und lasse die Zahl hochzählen, sollte ein neuer Eintrag in die erste Tabelle erfelgen, was nur dann passiert, sollt die IP nicht in der List stehen. Da das Script ja bei jedem neuen Query in der index.php aufgerufen wird, kann ich da ja gleich zu Beginn die Funktion einbinden, die alle "zu alten" Einträge aus der Tabelle löscht.

Hab ich das jetzt richtig kapiert??

Wuzel

2002-11-27, 14:31:26

Ohhh Mannnnn,
Reload Sperre die funzt ...

edit : OK ich stecks, nachdem man in diesem forum nicht den Code gescheit reingeschrieben kriegt : http://home.arcor.de/shak/cou.txt

Ist halt nen Code schnippsel, funzt famos , hier mit 1h reload sperre.

Happy bauing ..
©Wuzel

Crazy Aimer

2002-11-27, 16:52:54

danke @wuzel
ich probiers mal aus :D

Wuzel

2002-11-27, 17:13:49

Wichtig ist halt bloss das time() format und das die tables 'relativ' klein bleiben ( Sonst schnauft die DB ).
Einen Table pro tag anzulegen ereicht man hiermit

$query="CREATE TABLE IF NOT EXISTS $table (id INT NOT NULL AUTO_INCREMENT,
ipaddress VARCHAR(30) NOT NULL,
visit INT(11) NOT NULL,
refer VARCHAR(70) NOT NULL,
agent VARCHAR(100)NOT NULL,
host VARCHAR (100) NOT NULL,
PRIMARY KEY (id))";

$table = date(d_m_Y);

Damit kriegt man tables in form von 27_11_2002 für jeden tag ;)

Der Rest dürfte klar sein, ACHTUNG ! ich verwende eigene error Handles ( schickt mir mail wenn was nich haut ) -> die entsprechenden Stellen halt umschreiben -> sonst ERROR :)

Crazy Aimer

2002-11-27, 18:09:36

ahja ... hab mich schon gefragt, was das für funktionen sind :D
ja also diese einzelnen tables wären auch eine lösung ... man könnte ja die tables, die älter als einen tag sind löschen und vorher die anzahl der einträge in einer externen db speichern ... sozusagen als gesamtzähler ... das prob iss nämlich, dass mein webspaceanbieter 1) arschlahm ist und 2) ich nich weiß, wo der datenlimit der sql-datenbank liegt :)
aber ich probier mal rum... thx nochmals :D

Marcel

2002-11-27, 23:24:17

Originally posted by Wuzel
Wichtig ist halt bloss das time() format und das die tables 'relativ' klein bleiben ( Sonst schnauft die DB ).
Einen Table pro tag anzulegen ereicht man hiermit

$query="CREATE TABLE IF NOT EXISTS $table (id INT NOT NULL AUTO_INCREMENT,
ipaddress VARCHAR(30) NOT NULL,
visit INT(11) NOT NULL,
refer VARCHAR(70) NOT NULL,
agent VARCHAR(100)NOT NULL,
host VARCHAR (100) NOT NULL,
PRIMARY KEY (id))";

$table = date(d_m_Y);

Damit kriegt man tables in form von 27_11_2002 für jeden tag ;)

Der Rest dürfte klar sein, ACHTUNG ! ich verwende eigene error Handles ( schickt mir mail wenn was nich haut ) -> die entsprechenden Stellen halt umschreiben -> sonst ERROR :)

Hm, für jeden Tag eine Tabelle, um das DBMS nicht an's Schnaufen zu kriegen? Das heißt also, dass man, um zu prüfen, ob von der jeweiligen IP innerhalb der letzten 24h ein Zugriff erfolgte, muss man auf jeden Fall auf zwei Tabellen zugreifen. Bin da doch mehr der Verfechter von einer laufenden Tabelle, in der alle IPs der letzten 24h drin sind (nach Löschen muss die Tabelle natürlich auch per OPTIMIZE TABLE wieder kleingestampft werden). Mit je einem Sekundärschlüssel auf IP (für den Use Case "Eine IP ruft eine Seite auf"), auf ein Feld VisitedAt vom Typ DateTime (für den Use Case "lösche alle Besuche, die mehr als 24h her sind) und auf ein Feld CountForPage, welches das zu bezählende Objekt betitelt (für den Use Case "summiere alle Zugriffe, die in der laufenden Tabelle drin stehen und mehr als 24h her sind, also im nächsten Schritt gelöscht werden, gruppiert nach dem zu bezählenden Objekt"). Dieser Tabelle müsste dann eine Tabelle zur Seite stehen, in der für jedes zu bezählende Objekt eine Summe steht, mit Primärschlüssel auf CountForPage.
Btw: Ein Use Case Diagram is nie nich wech.
Und für die IP würde zum einen ein INT UNSIGNED reichen (32 Bit), zum anderen ist sie nicht mit einem Sekundärschlüssel belegt. Schnauf.

Gruß,
Marcel

Wuzel

2002-11-28, 00:57:21

Originally posted by Marcel

Hm, für jeden Tag eine Tabelle, um das DBMS nicht an's Schnaufen zu kriegen? Das heißt also, dass man, um zu prüfen, ob von der jeweiligen IP innerhalb der letzten 24h ein Zugriff erfolgte, muss man auf jeden Fall auf zwei Tabellen zugreifen. Bin da doch mehr der Verfechter von einer laufenden Tabelle, in der alle IPs der letzten 24h drin sind (nach Löschen muss die Tabelle natürlich auch per OPTIMIZE TABLE wieder kleingestampft werden). Mit je einem Sekundärschlüssel auf IP (für den Use Case "Eine IP ruft eine Seite auf"), auf ein Feld VisitedAt vom Typ DateTime (für den Use Case "lösche alle Besuche, die mehr als 24h her sind) und auf ein Feld CountForPage, welches das zu bezählende Objekt betitelt (für den Use Case "summiere alle Zugriffe, die in der laufenden Tabelle drin stehen und mehr als 24h her sind, also im nächsten Schritt gelöscht werden, gruppiert nach dem zu bezählenden Objekt"). Dieser Tabelle müsste dann eine Tabelle zur Seite stehen, in der für jedes zu bezählende Objekt eine Summe steht, mit Primärschlüssel auf CountForPage.
Btw: Ein Use Case Diagram is nie nich wech.
Und für die IP würde zum einen ein INT UNSIGNED reichen (32 Bit), zum anderen ist sie nicht mit einem Sekundärschlüssel belegt. Schnauf.

Gruß,
Marcel

NÖ man muss auf eine tab nicht mehr und nicht weniger -> zugreifen ;)
Klar kann man da noch optimieren, ist ja bloss ein schnipsel den ich so 0 8 15 like hingestellt hab ( funzt aber, hab ich vorher getestet, naja für 2 Minuten hingeschreibsel isses ok ;).
Es geht hier viel mehr ums prinzip und glaube mir, eine reload sperre mit weniger 'last' wirste nicht kriegen, zumal die sache mit den cookies nicht das wahre ist ( nicht jeder hat cookies an, last).
Natürlich kannste auch alles in einem einzigen table schmeissen.
Das funzt sogar gut wenn man ein aufräum script einsetzt.
Für jeden tag einen table einzusetzen macht Sinn, je nachdem wie gross die zugriffe sind und wie du die Sache auswerten willst.
Und zu guter letzt kann man immer die Sache komplizierter machen als sie ist ;)

Marcel

2002-11-28, 01:17:40

Vorsicht: Habe 'ne halbe Flasche Wein auf, also alles ohne Gewähr... :)

Originally posted by Wuzel
NÖ man muss auf eine tab nicht mehr und nicht weniger -> zugreifen ;)

In der Tabelle 27_11_2002 sind alle Zugriffe des Tages 27.11.2002.
In der Tabelle 26_11_2002 sind alle Zugriffe des Tages 26.11.2002.
Jetzt will ich am 27.11.2002 um 13.00 Uhr alle Zugriffe herausfinden, die in den letzten 24h stattfanden. Also alle, die ab 26.11.2002, 13.00 Uhr kamen. Da muss ich auf zwei Tabellen zugreifen.

Originally posted by Wuzel
Klar kann man da noch optimieren, ist ja bloss ein schnipsel den ich so 0 8 15 like hingestellt hab ( funzt aber, hab ich vorher getestet, naja für 2 Minuten hingeschreibsel isses ok ;).

Naja.... =) Nee, schon klar, dann sollte es aber auch als optimierungswürdig gekennzeichnet werden, zumal Du gleichzeitig davon sprachst, dass die Tabellen nicht zu fett werden dürfen.

Originally posted by Wuzel
Es geht hier viel mehr ums prinzip und glaube mir, eine reload sperre mit weniger 'last' wirste nicht kriegen, zumal die sache mit den cookies nicht das wahre ist ( nicht jeder hat cookies an, last).

Nunja, sofern eine saubere Indizierung möglich ist, kann man damit viel Last klein kriegen und auch fette Tabellen handlen.
Das darfst Du mir glauben ;-)

Originally posted by Wuzel
Natürlich kannste auch alles in einem einzigen table schmeissen.
Das funzt sogar gut wenn man ein aufräum script einsetzt.
Für jeden tag einen table einzusetzen macht Sinn, je nachdem wie gross die zugriffe sind und wie du die Sache auswerten willst.

Vorteil der TabPerDay-Methode ist, dass man nicht so oft aufräumen muss (erst, wenn man gegen die Platzbeschränkung des Providers läuft). Nachteil ist der umfangreichere Zugriff auf zwei Tabellen (s.o.).

Originally posted by Wuzel
Und zu guter letzt kann man immer die Sache komplizierter machen als sie ist ;)

Richtig. Ich hab nur versucht, sie zu optimieren, ohne sie komplizierter zu machen. Kompliziert erscheint sie nur dirch meine Beschreibung; ich neige dazu, es so unmissverständlich wie möglich zu definieren. Dabei schieße ich oft über's Ziel hinaus...

Gruß,
Marcel

Wuzel

2002-11-28, 11:52:01

Naja, es geht mir hier nur um die Reload Sperre.
Und die hat sich in der Form in der praxis bewährt.
Wie du dann deine Daten Strukturierst, ist da relativ wurscht.
Da das ganze aber auf Grund des Aufbaus bei einer etwas, mir unbekannten, 'schwachbrünnstigen standart Hoster' DB laufen soll, ist mir noch flugs eine Idee von nem Kumpel gekommen, für den ich mal so nen Counter/Tracker gebaut hab.
Hier hat die DB nähmlich bei so ca. 20 MB grossen tb ( die man schnell erhält bei sowas ) angefangen zu schnarchen, deshalb die primitivste aller primitiven speed optimierungen -> TB klein halten ;)
Zumal man aufräumaktionen a) Händisch ( was unangenehm ist jeden tag zu säubern ) oder b) über Crown ( was bei 0 8 15 Space unmöglich ist ) regeln müsste oder ???

Ich hoffe jetzt ist geklärt wie ich das denn alles gemeint habe.

Und die Reload Sperre an sich ist wie gesagt 1 a, das Prinzip ist sehr effektiv.

Crazy Aimer

2002-11-28, 13:01:56

ey leute ganz ruhig! hier wird sich nich gestritten! :D
also ich versuch da mal ein mittelweg zu finden und teste das mal aus ... wer nun welchen weg nimmt ist ja jedem selbst überlassen..

Marcel

2002-11-28, 13:15:01

Originally posted by Crazy Aimer
ey leute ganz ruhig! hier wird sich nich gestritten! :D
also ich versuch da mal ein mittelweg zu finden und teste das mal aus ... wer nun welchen weg nimmt ist ja jedem selbst überlassen..

Na, ich sehe das weniger als Streit denn als fachliche Diskussion. Aus einer solchen lernen nämlich alle Teilnehmer. Ich versuchte, die Vor- und Nachteile der beiden Möglichkeiten darzustellen, und vielleicht Wuzel die Vorteile geschickter Verteilung von Sekundärindizes derartig einzuhämmern, dass er wochenlang im Schlaf "create index schnellermacher on table grossetabelle (haeufigzugegriffenesfeld);" spricht, nein, schreit, ja geradezu brüllt.=)
Denn, Indizes sind
a) kleiner als die Tabelle
b) sortiert
c) in B-Bäumen abgelegt.
Punkt c) bedeutet, dass auch bei mittelgroßen Tabellen (5stellige oder kleine 6stellige Anzahlen von Datensätzen) die Anzahl der Zugriffe, bis ein Datensatz gefunden wurde, mit wenigen Händen abzählbar ist.
Wer Indizes mag, wird B-Bäume lieben.
(Die Sache mit den B-Bäumen gilt so direkt nur für eindimensionale Indizes, bei mehrdimensionalen ist das eine etwas andere, sehr komplizierte Geschichte, in der noch immer eifrig geforscht wird.)

Gruß,
Marcel

Crazy Aimer

2002-11-28, 13:29:02

na wenn du das so siehste ... okay ... aber für manchen terminie bin ich noch zu noobie-haft ... also versucht mal plz den ball etwas tiefer zu halten ... also ich hab mir folgende überlegung gemacht:
der counter wird in einer extra datei verarbeitet ... dann per include an die richtige stelle gebracht ... das bedeutet aber auch, dass er ständig neu aufgerufen wird...
nehmen wir an, wir hätten 2 tabellen ... die erste enthält eine list der referer der letzten 24h ... bei jedem neuen starten des scriptes wird die list um den ips die länger drinne stehen verkürzt ... vorher wird aber die anzahl der ips, die gelöscht werden ausgelesen und in der zweiten tabelle gespeichert ... praktisch als zusammenfassung der statistik, die ich dann nur auslesen brauch... den einzigen nachteil, den ich dabei sehe iss, dass ich dann ständig kontrollieren muss, ob die erste tabelle noch "alte" daten enthält und diese löschen muss ... ich mein ich kenn mich nich so doll aus ... aber so auf dem ersten blick sieht das nach performancefresserei aus oder ?
ansonsten müsste der algo ansich so hinhauen oder was meint ihr ?

Marcel

2002-11-28, 13:37:59

Originally posted by Crazy Aimer
na wenn du das so siehste ... okay ... aber für manchen terminie bin ich noch zu noobie-haft ... also versucht mal plz den ball etwas tiefer zu halten ...

Wenn Du einen Begriff nicht kennst: Einfach nachfragen, dafür sind wir ja hier...

Originally posted by Crazy Aimer
also ich hab mir folgende überlegung gemacht:
der counter wird in einer extra datei verarbeitet ... dann per include an die richtige stelle gebracht ... das bedeutet aber auch, dass er ständig neu aufgerufen wird...
nehmen wir an, wir hätten 2 tabellen ... die erste enthält eine list der referer der letzten 24h ... bei jedem neuen starten des scriptes wird die list um den ips die länger drinne stehen verkürzt ... vorher wird aber die anzahl der ips, die gelöscht werden ausgelesen und in der zweiten tabelle gespeichert ... praktisch als zusammenfassung der statistik, die ich dann nur auslesen brauch... den einzigen nachteil, den ich dabei sehe iss, dass ich dann ständig kontrollieren muss, ob die erste tabelle noch "alte" daten enthält und diese löschen muss ... ich mein ich kenn mich nich so doll aus ... aber so auf dem ersten blick sieht das nach performancefresserei aus oder ?
ansonsten müsste der algo ansich so hinhauen oder was meint ihr ?
Performancekritisch ist der ZuL(Zusammenfassen-und-Löschen)-Teil. Neben sauberer Optimierung kann man da etwas Lochfraß rausnehmen, indem dieser Teil nicht immer durchgeführt wird, wenn das Skript ausgeführt wird. Nutz einfach den Zufallsgenerator von PHP, z.B. in jedem 7. Ei ist ZuL mit dabei... Wenn nur jeder n-te Seitenaufruf 'ne Sekunde länger dauert, fällt das viel weniger auf, als bei jedem Seitenaufruf.
Ansonsten hört sich der Algorithmus sauber an.

Gruß,
Marcel

Wuzel

2002-11-28, 13:38:14

Hmm, Marcel bei aller liebe, hier geht es nich um mich ;)
Crazy Aimer hat das Prob, er braucht Hilfe, und er ist warscheins kein DB Spezi.
Deswegen : man kann immer alles komplizierter machen ....
Wenn ich jetzt mit meinem 'Tracker' , -> mehrdimensionalen Oracle Cluster, auf dem ein TLAN gemanagt wird ( ok ein bischen WWS is au drinne ) ankomme, könnt ich protzen biss nach Jericho, aber Crazy Aimer hätte nischt davon, ausser das wissen wie man 48 000 Zugriffe per minute managt :)

Deswegen hab ich gaaaaaaaaaaaaaaaaanz primitiv ein kleinen Schnipsel angefertigt, der so in der praxis , auch ohne fundierteres wissen, funktionieren könnte -> AMEN

Marcel

2002-11-28, 13:51:00

Originally posted by Wuzel
Hmm, Marcel bei aller liebe, hier geht es nich um mich ;)

Och mensch, wollte grade einen Kuchen backen, nur für Dich... :D
Originally posted by Wuzel
Crazy Aimer hat das Prob, er braucht Hilfe, und er ist warscheins kein DB Spezi.

Deswegen : man kann immer alles komplizierter machen ....

Hm, meine Posts scheinen wohl arg fachchinesisch geworden zu sein...

Originally posted by Wuzel
Wenn ich jetzt mit meinem 'Tracker' , -> mehrdimensionalen Oracle Cluster, auf dem ein TLAN gemanagt wird ( ok ein bischen WWS is au drinne ) ankomme, könnt ich protzen biss nach Jericho, aber Crazy Aimer hätte nischt davon, ausser das wissen wie man 48 000 Zugriffe per minute managt :)

Deswegen hab ich gaaaaaaaaaaaaaaaaanz primitiv ein kleinen Schnipsel angefertigt, der so in der praxis , auch ohne fundierteres wissen, funktionieren könnte -> AMEN

Naja, und genau darum ging es mir. Dass eine Lösung herauskommt, die funktioniert und nicht wegen der geringen DB-Power seitens des Providers irrsinnig lahme Seitenaufrufe verursacht.
Ich leide immer ein wenig unter dem Drang, den Leuten das, was sie tun, so zu erklären, dass sie es verstehen, und bei DB-Sachen führt das nunmal zu sowas wie oben.

Jetzt lass mich doch optimieren!!!;D

Gruß,
Marcel

Wuzel

2002-11-28, 14:01:42

Originally posted by Marcel

Ich leide immer ein wenig unter dem Drang, den Leuten das, was sie tun, so zu erklären, dass sie es verstehen, und bei DB-Sachen führt das nunmal zu sowas wie oben.

Jetzt lass mich doch optimieren!!!;D

Gruß,
Marcel

Ja ich lass dich doch, wollte aber trotzdem den versuch starten die auf dem Boden der tatsachen zurückzuholen ... ;)

Hmmm, vieleicht sollten wir auch die MyIsam TB's links liegen lassen und auf INO DB umsteigen ... das müsste pfeffern
:D
Ähhh Edit : natürlich mit hash Indexes -> wenn dann richtig

Marcel

2002-11-28, 14:06:18

Originally posted by Wuzel

Ja ich lass dich doch, wollte aber trotzdem den versuch starten die auf dem Boden der tatsachen zurückzuholen ... ;)

Hmmm, vieleicht sollten wir auch die MyIsam TB's links liegen lassen und auf INO DB umsteigen ... das müsste pfeffern
:D

*lach* und ich wollte grade damit anfangen, dass der ZuL-Teil eigentlich in einer Transaktion gekapselt werden müsste....
Nur, um mal mit Spatzen auf Kanonen zu scheissen...

Also, Crazy Aimer, Du siehst, man kann hier endlos dran rumschrauben, einige Sachen sind sinnvoll, einige Sachen theoretisch ein Muss, in der Praxis jedoch völlig überflüssig, weil, lohnt den Aufwand nicht.

Gruß,
Marcel (der sich eigentlich nur die ganze Zeit davor drückt, was für's Studium zu tun...)

Marcel

2002-11-28, 14:12:55

Originally posted by Wuzel

Ähhh Edit : natürlich mit hash Indexes -> wenn dann richtig

Mein Lieblingskapitel im DB-Buch von Vossen: Hash-Join... Als ich das aufschlug, lag ich am Strand der griechischen Insel Korfu, musste mich spontan kaputtlachen, Buch landete im Sand (wer das Buch in der Uni-Leih-Bib in Münster ausleiht und das Exemplar mit Sand hinter der Schutzfolie erwischt: Das war ich!) und wurde nur noch für ergebnisarme Reinigungsversuche geöffnet...
In der Klausur bei Vossen, ein halbes Jahr später, war ich dann auch nicht so erfolgreich wie erhofft...

Crazy Aimer

2002-11-28, 14:17:07

hehe lol also mit den mehreren möglichkeiten iss mir das schon klar ... fakt iss aber: ich hab eine mysql-db und 50mb webspace ... hmm... was kann man damit schon anfangen ... oder besser: was steckt man nicht alles weg um es kostenlos zu haben :D
naja ich versuch den algo mal vernünftig umzusetzen ... sollte ich probs kriegen meld ich mich wieder :)
ansonsten nochmals danke euch beiden! <--- ich bin einfach zu freundlich ;)

Wuzel

2002-11-28, 15:01:02

Originally posted by Marcel

Mein Lieblingskapitel im DB-Buch von Vossen: Hash-Join... Als ich das aufschlug, lag ich am Strand der griechischen Insel Korfu, musste mich spontan kaputtlachen, Buch landete im Sand (wer das Buch in der Uni-Leih-Bib in Münster ausleiht und das Exemplar mit Sand hinter der Schutzfolie erwischt: Das war ich!) und wurde nur noch für ergebnisarme Reinigungsversuche geöffnet...
In der Klausur bei Vossen, ein halbes Jahr später, war ich dann auch nicht so erfolgreich wie erhofft...

Eyyy nichts gegen hash indexes -> sowas von nem speed/kompliziert fanatiker 'pfff' :D
Naja, ich mag die , haben schon oft so manchen tick eingespart, hmmmmmm obs bei ner mysql DB sinn macht ist alerdings echt mehr als fraglich :D

Genrell, schon mal angekuckt wie sehr Mysql Indexes liebt ??
Also grade die beim Counter wichtige Insert Geschichte kannste dann wegschnallen, 'schnarch'.
Bei anderen DB's leidets zwar au nen weng, aber lang nich so krass wie bei Mysql ( naja iss ja au keine richtige DB wie manche zu sagen pflegen ).
Also bei 'einschneidigeren' optimierungen lass ich zu alererst die Finger von Mysql -> da ist nähmlich Hopf und Malz verloren ;)