2 løsninger til forum - hvilken er bedst?

Umiddelbart ville jeg skyde på at løsning 1 er hurtigst, men den "korrekte" måde at lave det på (relationelle databaser, dataintegritet, normalisering osv.)

Men...at trække 20 poster ud er en langsommere proces end at trække en post ud og dele den op i 20 bidder.

Mht. til arrays i databaser ville jeg bare gemme brugerID's kommasepareret, og så explode ved udtræk.

Hvad hvis en person slettes/afmelder sig selv? Skal han/hun så også slettes fra id listen som abbonnent?

Hej El_barto. Perfekt at du svare :)

Godt at vi er enige. Det er netop det billede jeg har haft, at ét udtræk må være hurtigere end ét, hvorefter man explode'r. Og det er netop hertil jeg får brug for lidt hjælp. Så enten opretter jeg et spørgsmål til, eller afsætter lidt flere points, hvis du gider hjælpe :)

Der vil være en funktion tilsvarende Ekspertens, hvor man kan fjerne fluebenet i "Abonnér". Herefter fjernes brugerens ID.

----------------------

Mit første problem består i, hvordan jeg indsætter brugerens id. Er det blot noget i retning af (jeg går her ud fra, at der bruges et VARCHAR/Text-felt) :

$UpdateSQL = mysql_query("UPDATE posts SET `mail` = `mail`+$userid WHERE `postid` = '$postid'") or die (mysql_error());

Altså noget i retning af, at brugerens id smides oven i de eksisterende værdier - dog med et komma (eller bedre: | ) imellem.

Er der forresten en måde hvorpå man kan sørge for, at den første post ikke får et , eller | foran? Indholdet skal jo ikke se sådan ud : ,1,4,5,54,204

Det skal se sådan ud : 1,4,5,54,204

Næste problem bliver, at fjerne et ID. Hvordan gøres det? Jeg skal fjerne et ID + et komma eller en | efter et komma - more or less :)

Endnu et problem bliver så, at danne et array ved udtræk af dataet. Hertil går jeg så ud fra, at jeg blot skal bruge explode - og det tror jeg vist nok jeg kan klare - kigger i hvertfald lige på det :)

Jeg vil holde på #2. Hvis du tager 1'eren, kan du ikke få din database på 3. normalform. Desuden, vil det blive en del mere bøvlet at administrerer. (når du skal slette/tilføje).

Din database bør snildt kunne klarer 20.000 poster og især hvis det bare er et par felter (id'er). Forstil dig at du har to eller flere brugere der afmelder/tilmelder sig samtidigt. Så skal du passe på at de ikke overskriver hinandens "arrays" .. For at undgå det, skal du låse hele tabellen - og det er noget rigtig skidt for performance.. Hvis du vælger #2, så vil du få en mere simpel løsning - også kodemæssigt.

Desuden, hvis du har et array .. 1,2,3,4,5 .. skal skal du explode, løbe igennem array'et - finde den rigtige.. og sætte det sammen igen..  Ikke godt performance-mæssigt. .. Hvad hvis der pludselig ikke er plads til array'et.  Vil du så bruge text-felter? Så ryger performance meget ned iforhold til fx to*integers.

At have en tabel med variable-længde arrays (fx varchar/text), er langsommere at søge i, end at have en tabel som løsning 2. Her kan mysql nemlig lave indexes, for at hurtigt at finde rækken/rækkerne, da en integer fylder et bestemt antal tegn (så een rækker fylder x bytes - så er det nemt for databasen at spring/beregne sig frem til hvor de rigtige rækker ligger. Variable-længde på rækkerne, besværliggøre processen, da mysql så skal se på alle rækkerne for at se for at springe rundt) ..

Dette er lidt firkantet og forsimplet stillet op.

.. og derfor ikke 100% korrekt..

Men det var lige hvad jeg havde på hjertet :)

Hej Dennis.

Mange tak for dit input. Kanon at du lige gav mig mulighed for at se på det fra en anden vinkel. Rent kodemæssigt har du ret. Det bliver mange gange simplere at gøre det som i eks. 2. Så det gør mig jo glad. Jeg havde dog troet, at det ville være bedre, performance-mæssigt, at lave eks. 1. Men hvis du mener at MySQL er "powerfull" nok til at kunne magte opgaven, så er det jo det oplagte valg. Specielt hvis MySQL er hurtigere end PHPs fortolker

MySQL har flere muligheder, da den selv styrer hvordan data'erne skal lagres - og der er forsket meget i databaser igennem tiderne - så mon ikke de har fulgt lidt med der :). MySQL kan jo også cache ting - den kan smide en masse data i hukommelsen så opslag går hurtigerer hvis den ved at det sker tit.

At lave det samme med PHP ret svært.

MySQL er lavet i c (så vidt jeg husker) .. sprog der er meget tæt på computerens "naturlige sprog". Sammenlignet med at PHP fortolkes (PHP'en læser linje for linje og ser hvad den nu skal gøre. Slår op i tabeller når du bruger variabler og funktioner - laver tjek så du ikke får det til at gå ned osv) - så kan du ikke rigtig sammenligne de to ting. :-)

PHP er jo designet til, at dødelige kan programmerer det :) c/c++ stiller højere krav - men er så også hurtigerer. Men til web er PHP jo godt, fordi der er flaskehalsen hovedsageligt forbindelsen - så selvom PHP er "langsomt" - så er forbindelsen tit flaskehalsen.

Men hvis du ikke ved hvad der er bedst, så lav det nemmest først. (Færrefejl, mindre kodetid) .. Så kan du altid senere begynde og se om det er langsomt. Herefter, finder du ud af, hvilke dele af koden er problemet.. Og SÅ begynder du at bekymre dig om hvad der kan gøres. Det er jo lidt surt, hvis du får implementeret en voldsom hurtig løsning iløbet af en uge - for at finde ud af, at det måske slet ikke er et problem. At fx problemet er måske, at webhotellet siger at du får for mange hits (forstået på den måde, at den "billige" løsning, måske først bliver et problem, når sitet er så stor at det giver andre problemer - måske endda alvorligerer.).

Jeg koder altid, hvad der er "rigtigst".. Derefter optimerer man, hvis det er for sløvt. Man kan godt sige, at jeg er en optimist :)

Jeg er til som dennismp, formuleret på en anden måde?????

Jeg ville lave en "mail_table", hvor brugerens brugernavn og email lå i to felter som begger er af typen unique
Når en tråd oprettes, laves en kolonne med "spm_id" som pr. default har værdien 0
Når en bruger så opretter/dropper et indlæg, opdateres feltet til 1 for den bruger.

På den måde kan man hente hvem skal ha' en email, og samtidigt nemt slette.

Og når en bruger ser siden, (evt. tjek med cookies? så man IKKE behøver at logge ind, evt.), så sættes værdien til 0.
Evt. også et "kun en mail" felt, (1 eller 0 som værdi), for at kun sende en mail, uanset antal kommentarer siden brugeren sidst har besøgt siden.

hmm, hvor mange kolonner kan Mysql ta'?

Hej igen.

Mange tak for de gode forklaringer. Jeg tror helt bestemt jeg holder mig til SQL løsningen, når i nu begge understreger, at det er den bedste løsning :)

Sukos > Jeg tror det kan laves lidt smartere mht. mail_table. Der er vel ingen grund til, at oprette en post i DB, for hver post brugeren har oprettet i forummet. Det smarteste ville jo være, kun at lave posten i mail_table, hvis brugeren ønskede en mail, og senere fjerne posten igen, hvis han/hun ikke ønsker at abonnére mere.

Herefter er det bare at SELECT'e sig frem til de personer, som skal have en e-mail :)

hmm, men for at finde alle dem som deltager i tråden? Hvis posten er slettet?
Jeg mener...

Èn table, som fra start kun har brugernavn og email

Når der oprettes en tråd, oprettes en kolonne referende til oprettede tråd.
For alle brugere er standardværdien 0
Men den kan så opdateres til 1 jo, når der smides et indlæg af brugeren, eller 0 når indlægget er set

Well, jeg tror jeg har styr på det nu - ellers siger jeg i hvertfald til :)

Smider i nogle svar ? :)

Jahhh, når den færdige kode vises! (evt.?)
Og jeg ved hvor mange kolonner der kan laves o.s.v. ......

(har aldrig selv prøvet det af)

anyway, det er noget af det fede ved PHP, at det næsten kun er din fantasi som sætter begrænsning!

Yep, masser af spillerum :))

Jeg håber du fik lidt input og inspiration webcreator.