Online marketing & salg på webshops & websites

Svar: Database model over udsendelse af nyhedsbrev.

Lone71 — Sat, 21 Feb 2009 09:33:56 GMT

Hej igen :)

Det er mysql jeg bruger og phpmyadmin.

Ja, det skal helst være lavet efter bogen, men jeg synes jeg bliver mere og mere forvirret.

Brugerne skal ikke nødvendigvis være i databasen når de afmelder sig.

Jeg er i første omgang ude efter at kunne lave en logisk model / ER-diagram, med de forskellige entiteter, attributter, og forbindelserne imellem dem, og dernæst en fysisk datamodel, over én af entiteterne,

Men vil også meget gerne komme ind på sql kommandoerne for at kunne se hvem der er tilmeldt. osv.

Det skal helst være så simpelt som muligt, så jeg kan forsvare det, så kan jeg altid komme ind på, hvordan den kunne blive udbygget i fremtiden med de funktioner du nævner.

Svar: Database model over udsendelse af nyhedsbrev.

Jesper F — Sat, 21 Feb 2009 09:13:24 GMT

Nu er det jo et eksamensprojekt, så jeg forestiller mig at censorerne evt. kan være krakilske med at det er gjort helt efter bogen.

For øvrigt - hvilken type databasen bruger du?

Måske misforstod jeg dig lidt. Du ønsker et brugerkartotek hvor brugerne eventuelt kan være tilmeldt nyhedsbrevet.

Men hvis de framelder sig skal brugerens navn og email stadigvæk forefindes i kartoteket - er det korrekt?

Om de aktuelt skal modtage nyhedsbrevet synes jeg er lettest at styre med et simpelt felt, de angiver om de skal have nyhedsbrev eller ej:

brugerID (autonumber, primærnøgle), fornavn (tekst), efternavn (tekst), email (tekst), tilmeldt (ja/nej elle true/false)

Hvis du bare ønsker at se hvornår de blev tilmeldt og frameldt kunne tabellen laves sådan:

brugerID (autonumber, primærnøgle), fornavn (tekst), efternavn (tekst), email (tekst), tilmeldt (dato, frameldt (dato)

og dine modtagere til denne rundes nyhedsbrev findes så med noget i stil med:

SELECT * FROM tblBrugere WHERE not [tilmeldt] Is Null AND [frameldt] Is Null

(eller lidt andeledes afhængig af hvilket program du bruger).

Dog skal vi lige tænke på - skal du have en historik over tilmeldinger og frameldinger? Altså bagud i tiden kunne se hvornår en bruger har været tilmeldt og frameldt? Det kan i nogle tilfælde være overkill, men hvis du ønsker oversigt over dette skal du nok have en ekstra tabel:

tblTilmeldingFramelding

ID (autonumber, nøgle), brugerID (long/int), tilmeldt (dato, frameldt (dato).

Så kunne man indsætte en dato i feltet "tilmeldt" når en bruger tilmelde sig og indsætte dags dato i "frameldt" når de framelder sig.

Alternativ kun "tblTilmeldingFramelding" laves således:

ID (autonumber, nøgle), brugerID (long/int), tilmeldframeld (int, fx 1=tilmeld, 2=frameld), dato (dato)

hvorved du får det hele i 3 kolonner i stedet for 4.

Jeg synes dog at når man designer databasetabeller skal det også være praktisk anvendligt dvs det skal ikke for bøvlet at udtrække data på en fornuftig måde. Nogle gange er det sådan, at hvis man normaliserer databasen til atomer, bliver queires osv. mere besværlige at lave. Så jeg synes man skal finde et godt mix af god, tilstrækkelig normalisering og så stadig have mulighed for ikke alt for avancerede queries.

Svar: Database model over udsendelse af nyhedsbrev.

Lone71 — Sat, 21 Feb 2009 08:28:55 GMT

dobbeltpost.

Svar: Database model over udsendelse af nyhedsbrev.

Lone71 — Sat, 21 Feb 2009 08:27:57 GMT

Hov jeg vrøvelde lige der:

Jeg mente nyhedsbrev tinyint(1),

Svar: Database model over udsendelse af nyhedsbrev.

Lone71 — Sat, 21 Feb 2009 08:24:23 GMT

Takker jesper.

Skal jeg dog ikke have, en tilmeldt og afmeldt et eller andet sted?

Kan ikke helt gennemskue hvordan man kan se, at brugeren er enten tilmeldt eller afmeldt et nyhedsbrev nemlig, eller er det mig der vrøvler? :)

Eller er det det du mener med aktiv?

Jeg kunne vel også have en tilmeldt_dato i brugere og så lave en tinyint(1) ?

Svar: Database model over udsendelse af nyhedsbrev.

Jesper F — Fri, 20 Feb 2009 22:31:15 GMT

Hvad med disse tabeller.

tblBrugere

brugerID (autonumber, primærnøgle), fornavn (tekst), efternavn (tekst), email (tekst)

tblNyhedsbreve

nyhedsbrevID (autonumber, nøgle), datosendt (dato), emne (tekst), indhold (tekst/memo)

tblBrugereNyhedsbreve

ID, brugerID, nyhedsbrevID

Her kan nøgle enten være ID eller være en kombination af brugerID og nyhedsbrevID. Ved at bruge sidstnævnte kan du sikre at samme bruger ikke kan stå opført som at have modtaget sammen nyhedsbrev 2 gange.

Du kan også have et datosendt i denne tabe, hvis du kunne tænkes at udsende over flere dage. Men det er nok mest relevant at have datosendt i tblNyhedsbreve

Ang registrering og afmelding.

1) Du kan slette brugeren og deres historik når en bruger afmelde.

2) hvis du mener at have lov kan du have et felt "aktiv" i tblBrugere som kan være en boolean true/false og så kan de blive sat til false når de afmelder. Så har du stadig historikken, men jeg synes egentlig at det er mest korrekt at slette dem, hvis de afmelder sig.

Database model over udsendelse af nyhedsbrev.

Lone71 — Thu, 19 Feb 2009 12:23:40 GMT

Hej, jeg skal til at lave min database til udesendelse af nyhedsbreve, og er gået i stå!

Jeg har svært ved at lave dataModel og E/R diagram, er der nogen herinde, der har forstand på dette?

Det er til mit eksamensprojekt på Multimediedesigner uddannelsen, hvor jeg laver mit eget firmasite, som tilbyder boligindretning til private kunder i København.

Jeg er kommet frem til, at der må være en entitet, der hedder bruger, hvor der er følgende attributter:

bruger_id, fornavn, efternavn, email

Men resten er jeg i tvivl om, for skal hvert nyhedsbrev have en tabel/entitet? Med et id-nr. ?

Så skal jeg også have en registrering_dato og en afmeld_dato.

Og samler jeg det så i en ny tabel, hvor jeg samler bruger_id med brev_id?

Ja jeg roder lidt rundt i det her....

Hvis der var en venlig sjæl, der måske selv havde rodet med datamodelering af nyhedsbrev udsendelse, så ville jeg blive glad for lidt hjælp.....