txt oder sql ?

[cheeby]

streber

[teriax]

Nochmals danke ;-)

... jetzt habe ich nur nch die Hoffnung das meine SQL-Datenbank bei 1000 genutzten Gästebuchern, sagen wir mal mit jeweils 150 Einträgen noch anständig läuft , 150000 Einträge sind nunmal nicht "mal eben" durchgeforstet.....!

[Abraxax]

du wirst ja auf keinen fall alle 150 einträge pro user gleichzeitig zeigen wollen.

verwende LIMIT in der SELECT anweisung. das beschränk schon die ausgabe und du solltest keine probleme bekommen.

wenn noch was ist. einfach posten. du kennst das ja ...

[teriax]

Ja,... Danke ;-)

Ich wollte eh nur 10 Einträge pro Seite zeigen lassen, dann kommt es nur
darauf an wieviele Gästebücher gleichzeitig aufgerufen werden....

Aktuell habe ich natürlich wieder ein anderes Problem :
Die Einträge sind durchgehend nummeriert, das kommt davon wenn man
eine Tabelle für alle Einträge nutzt, und unterschieden durch die
User-ID....
Gibt es eine Möglichkeit die Einträge beim auslesen durch zu nummerieren,
oder muss in der Tabelle ein zusätzliches Feld vorhanden sein in dem eine
zusätzliche ID gespeichert wird?

Folgende Idee bekam ich beim schreiben des Textes:
Könnte man nicht eine weitere Tabelle anlegen in der ein Index geschrieben wird?
Beispiel: id|eintraege
Mit Daten: id|1,4,7,345,642

Somit hat man doch direkten zugriff auf die jeweiligen Einträge, man muss
nur die "eintraege" nach dem auslesen splitten....

korrekt?!

[MelloPie]

Und wo ist das Problem mit der durchnumerierten ID?

[teriax]

Macht kein Problem mehr ;-))

[martin_de]

Re: txt oder sql ?

Original geschrieben von teriax
Hallo!

Welche Datenbank könntet Ihr mir für ein Multi-Gästebuch empfehlen?
...einfach Text-Datein oder eine MySQL-Datenbank?

Welche ist schneller, sicherer, resourcen-schonender?

danke für die Antwort ;-)

Gruss
René

weder mysql noch einfache textdateien.

mysql ist kostenlos verfügbar und weit verbreitet - das ist das einzig positive daran.
wenn du ein script veröffentlichen willst, ist mysql der *kleinste gemeinsame nenner* auf den man setzen kann wenn man anwendungen mit datenbankunterstützung schreibt.

für dein vorhaben ist ein leistungsfähigeres datenbanksystem aber empfehlenswerter.
mit mysql würde es zwar funktionieren - theoretisch verkraftet es auch noch viel mehr - aber für eine solche belastung ist mysql nicht konzipiert und arbeitet wenig effizient.

als kostenlose alternative bietet sich hier postgresql an. www.postgresql.com
ansonsten kann ich dir empfehlen mal einen blick auf sybase zu werfen. www.sybase.com

Folgende Idee bekam ich beim schreiben des Textes:
Könnte man nicht eine weitere Tabelle anlegen in der ein Index geschrieben wird?
Beispiel: id|eintraege
Mit Daten: id|1,4,7,345,642

Somit hat man doch direkten zugriff auf die jeweiligen Einträge, man muss
nur die "eintraege" nach dem auslesen splitten....

ich bin mir nicht ganz sicher, ob ich deinem gedankengang richtig folgen kann.
wozu willst du das tun?

du legst eine tabelle 'eintraege' an (oder wie auch immer du die nennen willst) mit den spalten:

id - userid - eintrag - email - homepage - XYZ

und liest das mit

mysql_query("SELECT * FROM eintraege WHERE userid=[b]welche_userid_auch_immer[/b] "); 

aus.

ich verstehe nun nicht was du dort noch durchnummerieren möchtest.


und etwas ganz wichtiges:

wenn du in queries mit variablen arbeitest z.b.

("SELECT * from eintraege WHERE userid='$userid' ");
oder soetwas in der art, ist es ganz wichtig, dass du die variable vorher auf ihren korreten wert überprüfst.
oder anders ausgedrückt:

man darf niemals irgendwelche werte die vom user übergeben werden ungeprüft in queries verwenden! sonst bricht die hölle für dich auf, da sich solche queries über die variable beliebig manipulieren lassen.
sowas kann sich von kleinen manipulationen bis zur möglichkeit die komplette datenbank zu löschen erstrecken.
wenn du bei google mal "sql injection vulnerable" suchst, wirst du *milliarden* treffer zu diesem thema erzielen.
das ganze ist ist ziemlich großes problem und der überwiegende teil der php/mysql scripte die man auf diversen script-sammelseiten findet ist dafür anfällig.
es gibt leider leute, denen kann man tausend mal sagen, dass alles was vom user übergeben wird nicht vertrauenswürdig ist, denen man erzählen kann, dass register_globals tot ist und nicht verwendet werden sollte, die werden das nie kapieren...
das ist zwar erstmal nur ein persönliches problem, aber wenn man solche scripte veröffentlicht, dann wird die eigene "dummheit" auch zu einem problem für andere. und da ist es wirklich nichtmehr lustig...

wie kann man sich vor solchen attacken schützen?

die einfachste möglichkeit ist, um alle variablen in queries ein addslashes() zu setzen. das kann man direkt im query tun oder auch schon vorher.

beispiel:

$userid = addslashes($userid);
mysql_query("SELECT * FROM eintraege WHERE userid='$userid' "); 

das würde die möglichkeit, das query über die variable zu manipulieren, ausschließen.
addslashes verwendet man ausserdem um syntaxfehler zu vermeiden.
in deinem fall beim abspeichern eines neuen eintrags.
auch hier muss um alle variables ein addslashes herum.

ich hab im moment keine zeit das ausführlich zu erklären, aber unter http://www.php.net/manual/de/function.addslashes.php wirst du im zweifelsfall weitere infos finden.
vielleicht find ich heut abend oder morgen noch etwas zeit um da ausführlicher drauf einzugehen.
aber das addslahes() ist das wichtigste an deinem ganzen script, du solltest also genau verstanden haben wozu das verwendet wird.

[mtforce]

SELECT * FROM user U LEFT OUTER JOIN eintraege E USING(userid) WHERE U.userid = 'die nummer' ORDER BY E.postdatum DESC

Hi. kannst du mir mal erklären, was dieser Teil hier bedeutet (und wie man darauf kommt?) :

U LEFT OUTER JOIN eintraege 

Was sollen die komischen Abkürzungen wie U und E ??
Ich kann mir zwar vorstellen, dass es den Tabellen entsprechen soll, aber muss man das nicht vorher definieren?

[Abraxax]

U und E sind die kurzbeschreibungen der tabellen User und Einträge . definiert sind diese werte bei der anfrage. es wird jeweils nach dem tabellennamen definiert.

was das LEFT OUTER JOIN betrifft, solltest du dich mal selber schlau machen....

http://www.mysql.com/doc/en/JOIN.html

http://www.mysql.com/doc/en/LEFT_JOIN_optimisation.html