[database][mysql] hoe dit te op te lossen?

[Verwijderd]

Tja niet bijzonder duidelijke titel, maar kan niet echt iets bedenken waar het precies over gaat

Probleempje:
ik laat gebruikers binnen mijn site berichtjes sturen. Dit kan zijn naar andere gebruikers van de site (online opgeslagen in db) of naar emailadressen.

Dit wil ik echter wel opslaan zodat de verzender ziet dat hij naar wie hij bericht heeft gestuurd.

De ontvanger moet uit die tabel van verstuurde dingen berichtjes kunnen halen die aan hem zijn gemaild.

Als ik het zou maken zonder dat het naar emailadres kan zou ik het zo doen:
msg_id (bericht staat in andere tabel)
ontvanger_id (user_id, aan wie ie gemaild is)
status (read, unread,reply-ed)

De die-hards snappen me probleem wel denk ik Graag beetje advies...

Ik kan natuurlijk niet een varchar veld gaan gebruiken om een user_id of emailadres in op te slaan, das beetje waanzin

[Verwijderd]

fromid, toid gebruiken en dan de berichten met het juiste toid er uit vissen?

[drm]

woeitje:
Tja niet bijzonder duidelijke titel, maar kan niet echt iets bedenken waar het precies over gaat

Probleempje:
ik laat gebruikers binnen mijn site berichtjes sturen. Dit kan zijn naar andere gebruikers van de site (online opgeslagen in db) of naar emailadressen.

Dit wil ik echter wel opslaan zodat de verzender ziet dat hij naar wie hij bericht heeft gestuurd.

De ontvanger moet uit die tabel van verstuurde dingen berichtjes kunnen halen die aan hem zijn gemaild.

Als ik het zou maken zonder dat het naar emailadres kan zou ik het zo doen:
msg_id (bericht staat in andere tabel)
ontvanger_id (user_id, aan wie ie gemaild is)
status (read, unread,reply-ed)

De die-hards snappen me probleem wel denk ik Graag beetje advies...

Toch jammer dat ik nou geen die-hard ben

Ik kan natuurlijk niet een varchar veld gaan gebruiken om een user_id of emailadres in op te slaan, das beetje waanzin

Voeg een extra veld msg_type toe. Dan ben je toch klaar, of begrijp ik het dan verkeerd

En waarom heb je nog een tabel met de berichten

[Verwijderd]

oke 1 bericht kan aan meerdere ontvangers

ontvangers bestaan uit gebruikers online en emailadressen.

Waarom NOG een tabel? het is niet NOG een tabel, het is een tabel waar het bericht in staat en wie de OWNER is. Zodat ik niet naar iedere gebruiker het bericht weer op hoef te slaan DUH.

Als ik extra veld toevoeg om te zeggen wat voorn ontvanger het is heeft toch weinig zin, ik moet toch opslaan of user_id of emailadres.
Ik kan niet zeggen dat een veld de ene keer een integer is en andere keer varchar............

Snappen jullie het probleem niet of zit ik vandaag echt met me kop in een roze wolk?

[stekkel]

bij elk bericht dat je verstuurd wordt maak je dus een record aan met een message_id en het bericht. (message_table)

Verder moet je een tabel hebben met een to_id, een from_id, status_id, message_id. (tracking_table

wanneer je dan een bericht naar bijv 3 mensen stuurd dan krijg je 1 record in de message_table en 3 records in tracking_table.

om bijv de status op te vragen van je verzonden berichten doe je gewoon een select * from tracking_table where message_id=xxx en from_id=xxx.

volgens mij kan je met deze 2 tabellen alle mogelijke informatie opvragen. (to_id en from_id wijzen ook naar tables)

Je kan mysql trouwens zelf unieke id's laten aanmaken voor de message_table. de from_id en to_id wijst naar de tabel met gebruikersinformatie. hier kan je je eigen gebruikers in opslaan.
Om de externe e-mailadressen op te slaan zou je nog een tabel kunnen maken met een id en het mailadres. in de tracking_table moet je dan een extra veld opnemen (boolean) die aangeeft of de to_id wijst naar de interne user_table of naar de externe emailadres_table.

Is het nog te volgen?

resumerend: 4 tabellen: message_table, user_table, tracking_table, extern_table.

[Verwijderd]

Nou, dan zweven we samen

Moet je de ene keer een varchar opslaan, en de andere keer een Integer ?

Misschien is het dan handig om 2 velden te gebruiken ?

Als de variabele dan een integer is laat je hem in het integer veld opslaan, en anders in de andere ? Je kunt daarna altijd checken welke van die velden gevuld is, en die je dus moet gebruiken ?

Of snap ik het probleem nu echt zo slecht als ik denk

Greetz

[Verwijderd]

ARGH!

Ik kan wel tegen de muur lopen, waarom kom ik nou niet op het idee hoe dit goed op te lossen.

De oplossing van piriah is opzich, als je naar de principes van DB kijkt niet zo netjes, omdat hij elke keer extra ruimte voor niks reserveerd.

Maar die andere oplossingen zou ik dus gewoon een aparte tabel moeten maken voor berichtjes die naar email zijn gegaan. Denk dat ik dat maar eens ga testen...

[stekkel]

het idee achter id's gebruiken (longint) is dat je zo een relationele database kan opzetten waar de tabellen verbonden zijn dmv de id's. Hierdoor kan je dus 1-n relaties maken wat met 1 tabel niet echt netjes kan. De totale hoeveelheid wordt ook minder groot. Het verzonden bericht sla je maar 1 x op en dat terwijl het naar 3 mensen is verzonden. Daarnaast kan het ook nog snelheidswinst opleveren omdat mysql trager wordt naarmate het aantal velden per tabel toeneemt.
Let er wel op dat je indexen aanmaakt voor de tabellen. bij de trackingtable zal er een index moeten komen op to_id en from_id. bij de message_table gebruik je gewoon de primary_index.

[Verwijderd]

Op dinsdag 11 december 2001 16:21 schreef stekkel het volgende:
het idee achter id's gebruiken (longint) is dat je zo een relationele database kan opzetten waar de tabellen verbonden zijn dmv de id's. Hierdoor kan je dus 1-n relaties maken wat met 1 tabel niet echt netjes kan. De totale hoeveelheid wordt ook minder groot. Het verzonden bericht sla je maar 1 x op en dat terwijl het naar 3 mensen is verzonden. Daarnaast kan het ook nog snelheidswinst opleveren omdat mysql trager wordt naarmate het aantal velden per tabel toeneemt.
Let er wel op dat je indexen aanmaakt voor de tabellen. bij de trackingtable zal er een index moeten komen op to_id en from_id. bij de message_table gebruik je gewoon de primary_index.

hihi ja dankje, ik weet wel 'iets' over databases
alleen zat ff met, of dit 'probleempje' misschien nog anders opgelost kon worden.

[stekkel]

Op dinsdag 11 december 2001 16:24 schreef woeitje het volgende:

[..]

hihi ja dankje, ik weet wel 'iets' over databases
alleen zat ff met, of dit 'probleempje' misschien nog anders opgelost kon worden.

gelukkig maar

er zullen overigens vast meer mogelijkheden zijn en het is aan jou om de beste te kiezen

suc6

[drm]

Waarom NOG een tabel? het is niet NOG een tabel, het is een tabel waar het bericht in staat en wie de OWNER is. Zodat ik niet naar iedere gebruiker het bericht weer op hoef te slaan DUH.

DUH yourself
</flauw>

Mijn idee:

code:

usertabel
- userID     PK
- emailadres
- rest van de gegegevens

koppelentiteit berichten:
- msgID   \
- fromID   } samengestelde PK
- toID    /
- type    email of local (ENUM)
- misschien nog meer velden die per bericht specifiek zijn

berichtentabel:
- msgID   PK
- content

Dan heb je wat je nodig hebt, toch

[Verwijderd]

Op dinsdag 11 december 2001 16:31 schreef drm het volgende:
Mijn idee:

code:

usertabel
- userID     PK
- emailadres
- rest van de gegegevens

koppelentiteit berichten:
- msgID   \
- fromID   } samengestelde PK
- toID    /
- type    email of local (ENUM)
- misschien nog meer velden die per bericht specifiek zijn

berichtentabel:
- msgID   PK
- content

Dan heb je wat je nodig hebt, toch

nee

In jou geval weet ik alleen of het nu naar een emailadres is gegaan of niet. Maar toch moet ik een user_id erin zetten. En dat kan niet want als iemand naar emailadres mailt kan het voorkomen dat die ontvanger niet lid is van de site, dus geen user_id heeft.
Snappie het?

[stekkel]

Op dinsdag 11 december 2001 16:31 schreef drm het volgende:

[..]
Mijn idee:

code:

usertabel
- userID     PK
- emailadres
- rest van de gegegevens

koppelentiteit berichten:
- msgID   \
- fromID   } samengestelde PK
- toID    /
- type    email of local (ENUM)
- misschien nog meer velden die per bericht specifiek zijn

berichtentabel:
- msgID   PK
- content

Dan heb je wat je nodig hebt, toch

Zoiets was mijn idee ook. koppelidentiteit was bij mij tracking_table.
Dus alle oplossingen zullen wel deze richting opgaan anders is het probleemtje niet oplosbaar

[ATS]

Err...
Je gebruikt twee tabellen omdat een berichtje naar meer dan 1 persoon verstuurd kan worden, en je het niet dubbel op wil slaan. Naast deze oplossing zie ik zelfs een voorstel om 4(!)|:( tabellen te gebruiken. Hoewel deze oplossingen misschien in verband met normalisatie van de data erg handig zijn, wordt er een belangrijk item vergeten:
Om de data die verspreid is over meerdere tabellen weer bij elkaar te krijgen, heb je joins nodig. Joins vragen nogal wat verwerkingskracht, zowel in CPU als in (tijdelijk) diskgebruik. Daarom moet je je afvragen hoevaak het voor zal komen dat een bericht naar meerdere afzenders gaat, en of dat opweegt tegen de zwaardere serverbelasting van je systeem door altijd joins te gebruiken. Ik verwacht dat het niet zo heel vaak voor zal komen, maar dat is natuurlijk afhankelijk van waar je het systeem voor gaat gebruiken.

Om je vraag te beantwoorden binnen je gekozen structuur: ik zou gewoon een veld toevoegen in de tabel die je beschrijft voor het emailadres. Een leeg veld neemt (bijna) geen ruimte in in je database, dus echt in de weg zit hij niet.

[Verwijderd]

Op dinsdag 11 december 2001 16:38 schreef ATS het volgende:
Om je vraag te beantwoorden binnen je gekozen structuur: ik zou gewoon een veld toevoegen in de tabel die je beschrijft voor het emailadres. Een leeg veld neemt (bijna) geen ruimte in in je database, dus echt in de weg zit hij niet.

Jep daar zat ik dus aan te denken, en het idee weegt wel op tegen de performance, MAAR als er veel naar emailadressen word gemaild sla je dus heel vaak een integer veld op voor jan met de korte achternaam, en je gebruikt ook nog eens een variable kolom, waardoor die tabel dynamisch word, en dat maakt hem ook weer iets minder snel. Dus ik denk dat 2 tabellen wel sneller werkt aangezien ik de tabel om te zien naar welke mailadressen een bericht is gegaan alleen zal gebruiken om uit te lezen als iemand een verzonden berichtje nog een keer bekijkt...
Dat zal niet zovaak voorkomen denk ik

[drm]

woeitje: Dat zal niet zovaak voorkomen denk ik

In dat geval is het misschien beter om je mailtjes in de database gewoon op te slaan als normale mailtjes met Headers etc.

Dat je dan een soort parsertje schrijft die uit dat mailtje leest naar wie hij toegegaan is. En bij interne mail gewoon het mailadres van de user waarnaar het toegegaan is in de To: header zetten.

[Goodielover]

Ik heb het voorstel van DRM iets aangeapst:

Mijn idee:

code:

usertabel
- userID     PK
- emailadres
- rest van de gegegevens

koppelentiteit berichten:
- msgID
- role (to/from/cc/bcc)
- adres (als type=local is dit een FK naar usertabel)
- type_adres    email of local (ENUM)
- misschien nog meer velden die per bericht specifiek zijn

berichtentabel:
- msgID   PK
- content

Je hebt eigenlijk bericht-participanten die een verschillende rol kunnen spelen en die daarnaast van twee subtypes kunnen zijn (inter/extern) Deze twee subtypes zijn in mijn tabel op elkaar gemapt en met het vlaggetje type_adres) weer uit elkaar te halen.

Voordeel van deze constructie is dat je met 1 snelle query alle berichten van 1 user (verzonden als ontvangen) kan opvragen)