hjælp til og designe database

Hvad er fejlen? Skal jeg oprette en profil før jeg kan se den?

venter også på feebback...

jeg skal havde lavet tabellerne der til men kan ikke finde ud af om jeg skal dele dem op eller jeg skal lave det hele i samen

Du skal naturligvis have en tabel der indeholder brugernes stamoplysninger, den ville jag kalde Bruger. Den skal have et felt for hver box på tilmeldingen PÅ NÆR Fagområderne!!. Desuden skal den have en Primær nøgle som jeg vil lave som autoincrement (hedder det vist, er ikke så hjemme i mySql, som jeg går udfra er databasen)

Fagområderne er noget helt specielt, og dem vil jeg registrere med en mange-til-mange relation: Lav en tabel der hedder Fagomraade, med to felter:

FagomraadeID int, auto-increment, primær nøgle
Navn varchar(50)

lav så en tabel der hedder Bruger_Har_Fagomraade, med to felter:

BrugerID int
FagomraadeID int

Hvis du kan skal du lave en Primær nøgle der består af BEGGE felter, ellers skal du lave et tredje felt, Bruger_Har_FagomraadeID int auto-increment, og bruge det til primær nøgle.

Fagomraader skal blot udfyldes med alle de fagområder der "tilbydes".

Når en bruger vælger et fagområde skal du så oprette en post i Bruger_Har_Fagomraade med det relevante BrugerID og FagomraadeID.

Når du derefter skal have oplyst en brugers Fagområder bruger du

"SELECT Fagomraade.Navn FROM Fagomraade INNER JOIN Bruger_Har_Fagomraade ON Fagomraade.FagomraadeID = Bruger_Har_Fagomraade.FagomraadeID WHERE Bruger_Har_Fagomraade.BrugerID = $BrugerID"

Okay hvad skal jeg så gøre men links da de kun skal virke hvis brugerne har betalt burdte jeg ikke lave en der hedder link

men

id
links
linksnavn
betalt

næ, jeg synes du skal lægge den logik et andes sted. Lad evt. brugeren udfylde felterne under alle omstændigheder, men sørg for at de kun virker hvis han har betalt. Marker tydeligt at de ikke virker hvis der ikke er betalt.

Betalingen kan registreres med et felt i tabellen Bruger, men det var måske bedre at lave en tabel Betaling, med et felt BrugerID, i den kan du så skrive en linie når betalingen falder, og gemme alle relevante oplysninger; betalingsdato, betalingsform beløb m.m.

Skal der være mulighed for flere end to links? Det skal der nok, så jeg synes at du skal lave en tabel der hedder Link (men af en ande grund end det du havde tænkt):

LinkID int auto-increment
BrugerID int
Navn varchar(50)
URL varchar(255)

Så kan hver bruger (evt.) have så mange links som det skal være. Det skal du styre via logikken på siderne.

Som du ser bliver der hurtigt mange tabeller, så jeg håber du har godt styr på JOINS.

Sådan kan du fx. se om en bruger har betalt, samtidig med at du henter andre oplysninger om ham:

SELECT Bruger.Email, Bruger.Navn, Betaling.BetalingsDato FROM Bruger LEFT OUTER JOIN Betaling ON Bruger.BrugerID = Betaling.BrugerID WHERE Bruger.BrugerID = $BrugerID"

Hvis han har ikke har betalt vil Betaling.BetalingsDato være NULL

hmm jeg må indrømme at jeg ikke har så meget styr på JOINS er det noget du kan forklare lidt mere om da det ser spændene ud

Jeg forstår ikke helt den her

Hvis du kan skal du lave en Primær nøgle der består af BEGGE felter, ellers skal du lave et tredje felt, Bruger_Har_FagomraadeID int auto-increment, og bruge det til primær nøgle.

Alle tabeller SKAL have en primær nøgle, OK? Den skal være unik, og derfor bruger man ofte et auto-increment felt til det, typisk navngiver man det noget med ID.

I Bruger_Har_Fagomraade har man en mulighed for at definere primær nøgle til at være begge felter i kombination (Det kan man i mange databaser), da dette altid vil være unikt. En bruger kan jo ikke være tilknyttet samme fagområde to gange.

Joins er en måde at koble to tabeller sammen i ét sql-udtryk. Man fortæller blot at en bestemt kolonne i tabel1 skal være lig med en bestemt kolonne i tabel2.

Du kan vælge at du kun vil se poster hvis der findes matchende poster i begge tabeller (INNER JOIN), eller du kan vælge at se alle poster fra den ene tabel, og data fra den anden tabel hvis der findes et match (OUTER JOIN).

Du vil sikkert ofte have gjort det på denne måde: Først henter du nogle data i databasen. Blandt de data finder du nogle oplysninger som du skal bruge for at hente yderligere data der er relaterede til de første.

JOINS er en måde at hente relaterede data på én gang, hvilket i reglen vil være meget mindre ressourcekrævende.

JOINS er selve kernen i relationelle databaser. Jeg vil meget anbefale at du læser noget om grundlæggende databasedesign, og SQL.

tak for hjælpn idanilsen