• Jetzt anmelden. Es dauert nur 2 Minuten und ist kostenlos!

PHP MySQL chat

Mad Dog

Mitglied
Hallo liebe Community!

Ich habe mal wieder eine Frage bzw suche einen Lösungsvorschlag.
Hier das Problem:
Frucht und Ich wollen einen Chat erstellen.
Dazu stellt sich uns die Frage, wie wir den Inhalt des Gespraeches speichern.

Wir hatten dazu 2 Ideen:

Idee Nummer 1:
Jeder User erhaelt eine eindeutige Identifikation(die erhaelt jeder so oder so). Wenn nun ein Gespraech gestartet wird, wird in einer Tabelle, nennen wir sie einfach mal A, eine neue Spalte erstellt. Die ersten beiden Felder enthalten die eindeutigen Identifikationen der beiden Gespraechspartnern. Weitere Felder dienen z.b. zur protokolieren der Zeit und andere Infos.
Worauf es aber in der Spalte ankommt, ist das Feld in dem der Inhalt des Gespraeches gespeichert wird. Das Feld wird sehr groß sein, da der komplette Text darin gespeichert wird. Das heisst bei jeden Klick auf den Senden Knopf wird der neue Text in dem Feld gespeichert.
In diesem Fall stellt sich die Frage wie viele Zeichen so ein Feld besitzten darf? Wie trennt man am besten den Gespraechsstoff um zu wissen wer was gesagt hat? Wie schnell ist so eine Methode? Macht es Sinn, nach z.b. 30k Zeichen das Feld zu reseten? (Jedoch sollen Beleidigungen etc gemeldet werden koennen)

Idee Nummer 2:
Wenn ein Gespraech gestartet wird, wird eine neue Tabelle angelegt. In der ersten Spalte stehen Infos z.b. Indentifikation etc.
Wenn jetzt einer der beiden Gespraechsteilnehmer auf senden klickt, wird eine neue Spalte erstellt und darin der Text gespeichert.
Wenn das Gespraech beendet ist, wird die komplette Tabelle z.b. nach 1nem Tag geloescht (oder sofort, jetzt nur wirkuerlich gewaehlt).
Der offensichtliche Nachteil darin ist natuerlich, dass es zu sehr vielen Tabellen kommen kann, wenn pro gespraech eine neue Tabelle erstellt wird, jedoch kommt uns diese Methode uebersichtlicher vor.

Nun unsere Frage, ob ihr noch andere Ideen besitzt oder Bemerkungen zu machen habt?

Kritik willkommen

mfg
mad dog
 
Werbung:
Ich würds wie folgt machen:

Tabelle: user_said_something
Feld 1: userID
Feld 2: toUserID
Feld 3: date
Feld 4: text

Jede einzelne Nachricht wird somit in einem Datensatz gespeichert. Wenn beide Gesprächspartner nix mehr schreiben, kann das ja nach einer gewissen Zeit gelöscht werden. Oder wenn meinetwegen beide Partner dem Server nicht mehr mitteilen (hier würde Ajax ins Spiel kommen), dass sie noch da sind.

Ich denke so, oder so ähnlich machen es auch Seiten wie omegle.com
 
also meinst du variante 2?
fuer jedes gespraech eine tabelle und jede spalte ist das was das der eine zum anderen sagt?
 
Werbung:
Nein. Wozu mehrere Tabellen? Eine Tabelle langt doch vollkommen.

UserID 1; toUserID 2; date 25.2.; hier ist mein text
UserID 2; toUserID 1; date 25.2.; super, text ist angekommen
UserID 3; toUserID 83; date 25.2.; hey, ich bin nun auch hier

Die ersten 2 Zeilen sehen nur User 1 und 2 und die dritte Zeile ist eben ein Gespräch zwischen User 3 und User 83. Alles in einer Tabelle. Mit dem WHERE Befehl von MySQL kannst du doch nun ganz einfach das Gespräch zwischen entsprechenden Usern abfragen.
 
Faustregel: Ein Datenbankschema, das das Hinzufügen von Spalten und Tabellen als normalen Vorgang integriert, ist so gut wie immer falsch. Es sollten im Betrieb nur Zeilen hinzugefügt, verändert oder gelöscht werden.
 
Ich glaube wenn Mad Dog von Spalten spricht, dann meint er eigentlich Zeilen/Datensätze.

Gruß thuemmy
 
Werbung:
Er meinte aber auch, dass er pro Gespräch ne eigene Tabelle erstellt und unter Tabelle kann man meiner Meinung nicht wirklich was falsch verstehen.
 
japp das fuer jedes neue gespraech eine neue tabelle erstellt wird ist variante 2 :)
und mit spalte meine ich zeile/datensatz :D

okay also sieht es eher nach variante 2 aus, abgeaenderte version von Sn0opy

vielen dank
 
ein Chatsystem so aufzubauen ist unsinnig. Php ist für sowas nicht gebaut.

ich beschäftige mich intensiv mit Netzwerkkommunikation und verspreche dir, du unterschätzt das!

was sinnvolles könntet ihr mit Flash (Sockets) und Erlang bauen.
 
Werbung:
PHP eignet sich grundsätzlich (je nach Anforderung) schon als Serverbackend. (Siehe etwa hier, vor allem ab #7.) Interessanter ist erstmal die Umsetzung auf Clientseite, denke ich. (Bzw. das gewünschte Ergebnis generell. "Wir wollen einen Chat machen" ist doch extrem vage.)

[google]php chat[/google] oder [google]ajax chat[/google] kann auch nicht schaden.

Ich glaube wenn Mad Dog von Spalten spricht, dann meint er eigentlich Zeilen/Datensätze.

Ja, habe ich mir auch gedacht. Die Faustregel ist trotzdem nicht verkehrt. :)

Ich würde übrigens jeden neu empfangenen Chateintrag als einzelne Zeile speichern, so wie Sn0opy das vorgestellt hat.
 
Php eignet sich ab einem gewissen Level dafür nicht mehr. z. B. ist keine Nebenläufigkeit möglich, alle Daten müssten über eine Datenbank (vielleicht sogar memcache oder etc.) transferiert werden. man könnte mehrere "Server"-Tasks starten die sich versuchen irgendwie die Kommunikation untereinander zu zu schieben, hier sehe ich einen Graus an Chaos.

die Clientseite ist verhältnismäßig einfach implementiert, ich würde dafür eine JS zu Flash Kommunikation nutzen um dann mit Sockets mit dem Server zu kommunizieren.

Ich würde bei der Serverimplementation zu einer funktionalen Sprache raten z.B. Erlang, Lisp oder F#.


ich habe angefangen in C# einen Chatserver zu implementieren, selbst C# ist mir hierfür nicht ausreichend. Ich habe mich für den ganz harten Weg entschieden und lernen nun C++.

Sicher kannst du mit PHP einen Socketserver programmieren der ein paar User mit Daten füttert (Achtung Memoryleak Gefahr), wenn du jedoch wirklich auf Nutzbarkeit aus bist, ist dies unsinn.
 
Werbung:
ja fuer das eigentlich chat interface werden wir vermutlich ajax nutzen.
php und mysql war nur der teil gedacht zum speichern des gespraechsinhaltes :)
 
hip hop ist noch garnicht veröffentlicht, zudem löst es auch keinerlei der problematik in richtung skalierbarkeit und parallelität.

php ist und bleibt die falsch sprache für solche spielereien wenn man es ordentlich lösen möchte. ein paar daten via ajax hin und her zu schicken ist kein großes problem. ein "chat" ist jedoch in meinen augen eine andere klasse ....

die kommunikation via mysql zu lösen halte ich für schwachsinnig, bei einer echtzeitkommunikation macht es keinen sinn daten permanent zu speichern, sollten diese im ram des servers liegen reicht dies dicke .... ein kompromiss um es quick & dirty zu realisieren wären memory tabellen mit einem event die sich eigenständig regelmäßig löschen. es bleibt jedoch weiterhin das problem bestehen, dass php nicht für endlosskripte konzipiert ist, sollte man dies nicht via sockets lösen müsste man den server unnötig mit clientseitigen requests belasten.

baut ne nette shoutbox mit ajax funktion oder wie auch immer, aber chat? ahje ...
 
Werbung:
Ich denke, das ein Chat mit PHP viel zu ressourcenaufwendig ist...
Überleg mal, was passiert, wenn 50 Leute gleichzeitig chatten!
Allein mit PHP würde ich das nicht machen..
 
Leute, jetzt hört doch mal bitte mit diesen unbegründeten Aussagen auf. :p Ich habe oben einen Thread verlinkt, in dem jemand davon spricht, mit einem PHP-Skript die 10-fache Anzahl an Clients verwaltet zu haben. (Was auch noch nicht viele sind.) Das heißt nicht, wie freak131 bereits wunderbar erklärt hat, dass das die schlaueste (oder überhaupt eine schlaue) Idee wäre, das heißt nur, dass es prinzipiell möglich ist. PHP unterstützt diese Art der Client-Server-Kommunikation wie zig andere Sprache. Zu den definitiven Nachteilen siehe freak131s Posts. Wer also nicht gleich Java oder so lernen will, der kann auch erstmal 30 Zeilen PHP-Code als Server laufen lassen. Für ein paar Clients reicht das.

Und zum ca. dritten Mal: Darum geht es hier im Thread vermutlich überhaupt nicht. :wink:
 
Zurück
Oben