Euh, waarom een random gesprek-id? Je kunt toch gewoon het eerstvolgende vrije id (auto_increment kolom) pakken?

Hoe luidt de definitie van een gesprek: is dit een conversatie met (exact) twee (verschillende) personen, of ook meer? Kan iemand de conversatie gaan bijwonen nadat deze is gestart, en verlaten voordat deze wordt beëindigd? Wanneer start een conversatie en wanneer is deze voorbij?

Pas als je deze regels hebt uitgewerkt (functionele spec) kun je dit omzetten naar een technische (database-)implementatie en pas als dat is gebeurd kun je dit vertalen naar een werkend stuk functionaliteit. Of je zou parallel al wat schermen kunnen ontwerpen als een soort van proof-of-concept.

Je zult dus eerst over de precieze vorm moeten nadenken, dit dan uitwerken, en dan gaan bouwen. In die volgorde.

Ik zou er zelf voor kiezen om een conversations tabel aan te maken. Deze heeft een id die wordt opgeteld via een auto increment.

Vervolgens voeg je aan iedere message een conversation_id toe. Zo kun je de gesprekken groeperen per conversatie.

Mja maar goed, wanneer start een conversatie, en wanneer stopt deze? Als die grens toch vaag is dan kun je net zo goed een berichtensysteem hebben waarbij je een bericht van A (verzender) naar B (ontvanger) stuurt. Je kunt dan berichten lezen wanneer jij A of B bent. En als je dit dus meer wilt onderverdelen dan zul je een soort van aparte "thread" moeten aanmaken (bijvoorbeeld zoals conversaties op deze website werken) zodat je een berichtenbundel als "gesprek" kunt behandelen.

En dan het volgende: is het echt interactief, dus een soort van AJAX-applicatie waarbij je met iemand chat? Of toch meer een soort van forum-formaat (langere tijd tussen reacties / geen rechtstreekse respons). In het laatste geval zal het denk ik toch vaker voorkomen dat je iemand af en toe een persoonlijk bericht stuurt, dus dat zal meer "af en aan" zijn dan dat je echt één op één een gesprek aan het voeren bent, de vraag is of er dan echt de noodzaak is om dingen te bundelen in gesprekken.