Det er jo bare at lave 2 tabeller, en til bruger og en til gæstebogs indlæg. Så gemmer du bare ejeren af gæstebogen's id i gæstebogstabellen. Sværre behøves det vel ikke at være :-)
--
Skal du bestille hos Servage.net? Brug dette link og få 25GB ekstra plads!!! http://www.servage.net[...]

#1 Så du siger alle brugere i én samme tabel. Og så én tabel til alle gæstebog indlæg? Men hvis hver brugere har sin egen gæstebog, men alle gæstebog indlæggene lægger i én samlet tabel, vil det ikke tage lang tid, når man på hjemmesiden går ind i en brugers tabel, og der så skal søges hele gæstebog tabellen igennem for kun at udvælge og vise denne specifikke brugers indlæg?
--
Hjælp, jeg vil ikke være nørd!

Det er jo bare SELECT * FROM guestbook WHERE member_id = id Du bør under alle omstændigheder ikke ændre på database design når du tilføjer nye brugere, så det er ikke noget mere create table guestbook_$id eller sådan noget fancy ;)
--
Skal du bestille hos Servage.net? Brug dette link og få 25GB ekstra plads!!! http://www.servage.net[...]

#3 Men tænkt hvis der er 1000 brugere, dvs. indlæg fra 1000 forskellige den skal sortere, vil det ikke tage båndbredde og søgetid:)? Altså jeg har ingen erfaring med databaser, så derfor jeg spørg hehe. Hvordan håndtere man så, hvis man vil se en liste over hvem som er online? Opretter man så en "Online"'-tabel, der så tilføjer id på den bruger, der logger på? og fjerner ham når han logger af? Denne liste kan man så hente ind på "liste over online brugere"-side?
--
Hjælp, jeg vil ikke være nørd!

Men hvis hver brugere har sin egen gæstebog, men alle gæstebog indlæggene lægger i én samlet tabel, vil det ikke tage lang tid, når man på hjemmesiden går ind i en brugers tabel, og der så skal søges hele gæstebog tabellen igennem for kun at udvælge og vise denne specifikke brugers indlæg? Nej, det tager ikke lang tid. Så vidt jeg ved er det klart den hurtigste måde at gøre det på. Jeg har lige en artikel som jeg synes du skal kigge lidt på. Det er godt nok om PHP, men afsnittet om database-design er helt grundlæggende, som kan bruges på alle platforme. Den forklarer lige præcis hvordan man opbygger sådan noget med at få flere tabeller til at arbejde sammen på: http://www.udvikleren.dk[...] Go arbejdslyst Jace
--
http://www.jacobworsoe.dk[...] Hvis man skal gøre noget, så skal man gøre det ordentligt, ellers skal man lade være...

Med hensyn til online brugere, så har jeg sørme også lige en artikel til hvordan den skal kringles :) Det er igen PHP, men tankegangen bag sådan et system er også her helt grundlæggende, som kan anvendes på alle platforme: http://www.udvikleren.dk[...] Mvh Jace
--
http://www.jacobworsoe.dk[...] Hvis man skal gøre noget, så skal man gøre det ordentligt, ellers skal man lade være...

#5 Ser godt ud, jeg kigger på det :).
--
Hjælp, jeg vil ikke være nørd!

#6 Ok så bliver det to tabeller :). Så håber jeg ikke der er tabel nedbrud pga. for mange gæstebogindlæg :). Hvordan håndteres så online brugere problemet?
--
Hjælp, jeg vil ikke være nørd!

#8 - Det skulle gerne være beskrevet i den artikel jeg smed link i #6. Jeg kunne forestille mig at samtlige af forum indlæggene her på hol ligger i en enkelt tabel, så den skal være meget stor for at der kommer tabel nedbrud :)
--
http://www.jacobworsoe.dk[...] Hvis man skal gøre noget, så skal man gøre det ordentligt, ellers skal man lade være...

Det med at opbygge database på en korrekt måde kan være lidt svært. Og hvis det ikke bliver gjort ordenligt fra start, så kan det få betydning på sigt. Bare se på hol.dk.. Så hvis du regner med at dit site vokser sig stort med mange brugere osv. Og databasen ikke skal voldtages, så vil jeg anbefale du sætte dig (lidt) ind i normalisering af databaser. Men omvendt så er det ikke altid lige hensigtmæssigt at bruge normalisering... Her er lige 2 links omkring emnet. Jeg har ikke lige tid til selv at skrive noget.. Men bare skriv hvis du har spørgsmål. http://www.troubleshooters.com[...] http://www.bkent.net[...]
--

#10 Jeg regner med et sted mellem 1000-2000 brugere. Jeg har læst den ene og skimtet den anden artikel igennem, jeg forstår godt hovedideen i det. Mange tak, det er godt at have det i baghoved :). Det giver også god mening.
--
Hjælp, jeg vil ikke være nørd!

#6, tja, det kan ikke laves på andre måder...Hvorfor lader du ikke bare databasen gøre det den er bygget til ? VÆRE en database...den er bygget til den slags ;)
--
Skal du bestille hos Servage.net? Brug dette link og få 25GB ekstra plads!!! http://www.servage.net[...]

#11 - Okay, det var da et rimelig stort site. Må man spørge hvad sitet skal handle om? #12 - Hvordan skal det forståes? At man skal lade en database være en database? :)
--
http://www.jacobworsoe.dk[...] Hvis man skal gøre noget, så skal man gøre det ordentligt, ellers skal man lade være...

Lav et schema til at begynde med og post det her, så er det lettere at kommentere, hvad du gør rigtigt/forkert. Du er velkommen til at smide mig en mail, hvis du render ind i problemer eller bare har spørgsmål.
--

#14 Hvad menes præcis med en schema? Et oversigt i tabellerne og indhold i noteblok? Det kan jeg godt gøre. #13 Et asiatisk community i stil med den svenske, http://www.friedrice.se[...] .
--
Hjælp, jeg vil ikke være nørd!

#8 Den største tabel i det system jeg arbejder på til hverdag, indeholder helt præcist 8.172.865 rækker og vokser med et par tusinde om dagen (og så er det ikke engang voldstort). Du skal ikke være bange for mange data... men du skal tage dig i agt for at bruge dem forkert. Hvis du laver en gæstebogs- og en brugertabel, og så begynder at spørge på tekstbaserede felter som navn eller email, istedet for at bruge id-numre ... så er det at du skal blive bange :) Hvis du f.eks. vil vælge navn, email og indlæg fra alle gæstebogsindlæg, så husk at bruge talbaserede ID numre a la (hvor iBrugerID er et fortløbende, unikt ID i tBruger) SELECT tBruger.vNavn, tBruger.vEmail, tGaestebog.vIndlaeg FROM tBruger INNER JOIN tGaestebog ON tBruger.iBrugerID = tGaestebog.iBrugerID_FK og ikke dødssynden med tekstfelter (hvor du benytter brugerens navn til at pege på brugeren, og ikke hans ID) SELECT tBruger.vNavn, tBruger.vEmail, tGaestebog.vIndlaeg FROM tBruger INNER JOIN tGaestebog ON tBruger.vNavn = tGaestebog.vNavn_FK Sidstnævnte bruges her på HOL flere steder og... ja, det mærkes jo :D
--
Bevar naturen - sylt et egern http://uvorn.dk[...] http://uvorn.dk[...]

Mit bud: Tabel "Brugere" BrugerID Brugernavn Køn Fornavn Efternavn Fødselsdagsdato Email SenestLogin Tabel "Relationer" BrugerID GæstebogID Tabel "GæstebogIndhold" GæstebogID ForfatterBrugerID (personen der skriver i gæstebogen) GæstebogIndlæg Dato Privat/Offentlig (om indlægget skal kunne ses af andre brugere udover den som har skrevet indlægget, og den som ejer gæstebogen). Jeg forestiller, hver bruger er repræsenteret i tabellen "Brugere", hver bruger er knyttet til en gæstebogID gennem "Relationer", mens alle gæstebøgers indlæg gemmes i tabellen "GæstebogIndhold", hver række i "GæstebogIndhold" repræsentere således et indlæg, som man kan identificere hvis gæstebog den tilhøre vha. GæstebogID, samt hvem der har skrevet indlægget gennem "ForfatterBrugerID".
--
Hjælp, jeg vil ikke være nørd!

#16 OK, men hvad synes du om mine tabeller #17? Ser det ok ud?
--
Hjælp, jeg vil ikke være nørd!

Du behøver ikke relationstabellen, du peger allerede på en bruger fra et gæstebogsindlæg med din ForfatterBrugerID - det er det som hedder en foreign key, fordi den peger på en anden tabels primære nøgle, Brugere.BrugerID. Med dit nuværende setup hvor ét gæstebogsindlæg peger på én bruger, er relationstabellen overflødig. Ellers ser det fint ud. Hvis hver gæstebogsindlæg kunne hver skrevet af flere brugere, og hver bruger kunne skrive flere gæstebogsindlæg, skulle du bruge en relationstabel - man bruger dem når det er mange-til-mange relation. Når du har en mange-til-én relation, er det nok med at pege fra mange (gæstebogsindlæg) til én (brugeren). Håber du kan følge mig. Derudover er det altid en god idé at bruge en navngivningsstandard som angiver hvilken datatype der ligger i et givent felt ... f.eks. at kalde Navn for vNavn fordi det indeholder varchar, eller BrugerID for iBrugerID, fordi det indeholder en integer.
--
Bevar naturen - sylt et egern http://uvorn.dk[...] http://uvorn.dk[...]

Grundet tabellen "Relationer", er at jeg senere kan knytte en brugerID til fx. fotoalbum osv., og så giver det lidt bedre overblik? I tabellen "GæstebogIndhold" GæstebogID ForfatterBrugerID (personen der skriver i gæstebogen) GæstebogIndlæg Dato Privat/Offentlig (om indlægget skal kunne ses af andre brugere udover den som har skrevet indlægget, og den som ejer gæstebogen). GæstebogID knytter gennem "Relationer" til en brugerID, altså den person som ejer gæstebogen, mens ForfatterBrugerID, er personen som har skrevet i gæstebogen. Men som du siger, istedet for GæstebogID, kunne jeg bare bruge BrugerID. Et andet spørgsmål, hvordan opretter jeg en database i VS 2005? Når jeg vælger "New File" og "SQL database", så får jeg en fejlmeddelse? Jeg har ikke så meget forstand på databaser oprettelse i VS 2005, jeg har bare tænkt mig at oprette en, så jeg kan simulere hjemmeside og database på min computer, og når den skal online, så skal det jo op på en webhost på nettet. Mangler jeg nogle opsætning i SQL server før at det virker eller hvad? Et tredje spørgsmål: Når jeg endelig har lavet databsen og hjemmesiden på min computer, og jeg vil uploade det til en webhost. Hvordan foregår database implementeringen? Uploader jeg også bare .mdf filen, eller skal man på en "online" database side og oprette tabellerne igen, som man vist gør med MySQL?
--
Hjælp, jeg vil ikke være nørd!

Hm nu kan jeg vist oprette databasen :).
--
Hjælp, jeg vil ikke være nørd!

Hvad hedder hedder "string" i database sprog, er det bare "text"? Skal vælge datatype til brugernavn. Nu vil jeg have, at brugerID automatisk tæller op, når en bruger oprettes, hvordan aktivere jeg det i SQLserver? Sorry for alle mine spørgsmål :).
--
Hjælp, jeg vil ikke være nørd!

Jeg forstår stadig ikke meningen med din relationstabel (som du i øvrigt bør omdøbe til uanset hvad, relationstabel er et for generelt navn - hvis den relaterer Bruger og Gæstebog, så kald den BrugerGaestebog - men det er for mig uklart hvad den gør) Hvis du ønsker at lave et fotoalbum senere, sørger du blot for at Fotoalbum tabellen indeholder en reference til din Bruger tabel, f.eks. Fotoalbum.iBrugerID_FK som angiver hvilken bruger der ejer fotoalbummet.
--
Bevar naturen - sylt et egern http://uvorn.dk[...] http://uvorn.dk[...]

For at få et ID felt til automatisk at tælle op, skal du slå Identify til på feltet under design view. Jeg vil i øvrigt anbefale dig at du kun bruger din udbyders database, også til at udvikle på fra din egen maskine - det er lidt trælst at flytte en SQL Server database.
--
Bevar naturen - sylt et egern http://uvorn.dk[...] http://uvorn.dk[...]

#22 Så vidt jeg husker hedder tekst data (N)CHAR eller (N)VARCHAR i SQL-server. (N)TEXT bruges som uendelige strenge af tekst, men er langsomme i brug. N betyder at der er tale om UNICODE tekst. Hvis du skal have et INT/BIGINT felt til at automatisk at forhøje i værdi, så skal du sætte det til at være "INDENTITY SEED".
--
DS4/E6600/2GB_6400_CL4/7900GT Min rekord: Det tog [71,7968800000] sekunder at generere denne side HUSK at sige "Tak for hjælpen", når du får hjælp!

Tak jeg prøver med ad... Tak for rådene alle. Under Identity kan jeg kun vælge YES/NO og ikke SEED.
--
Hjælp, jeg vil ikke være nørd!

Det skal bare på yes hehe. TAK
--
Hjælp, jeg vil ikke være nørd!

#27 SEED er det som IDENTITY skal forhøjes med hver gang en ny post oprettes- så vidt jeg husker :o) Held og lykke med projektet...
--
DS4/E6600/2GB_6400_CL4/7900GT Min rekord: Det tog [71,7968800000] sekunder at generere denne side HUSK at sige "Tak for hjælpen", når du får hjælp!