[MarZim]

Håller med, det är inte helt trivialt att designa en databas. Visst går det att skapa en databas på några minuter, men är det ett system som ska användas någon längre tid skulle åtminstone jag lägga betydligt mer tid.

Nu till frågan; Det beror i mångt och mycket på hur annonseringssystemet ska användas. Hur många annonsörer pratar vi om? Det är en viss skillnad att bygga ett system för ett 100-tal annonsörer och ett par miljoner annonsörer

Andra saker som kan vara bra att fundera igenom är om det är möjligt för en annonsör att ha flera annonser? Vad jag kan se så finns det ingen information om vilken tidsperiod eller antal klick som annonsören köpt, men det spelar kanske ingen roll?

När jag designar databaser brukar jag först lista all information som jag vill ha med och därefter dela upp informationen i olika tabeller baserat på hur informationen hör ihop. Efter det är det dags att normalisera tabellen för att undvika redundanta värden då det kan ställa till en hel del bekymmer.

Om samma värde finns på flera ställen i databasen är det t ex väldigt lätt att missa att uppdatera det på något ställe, dessutom tar det onödigt med utrymme... Du verkar dock ha tänkt på det, åtminstone till viss del, om man tittar på namnen; category_id, province_id, region_id...

För en grundkurs i relationsdatabaser kan jag rekommendera http://www.databasteknik.se/webbkursen/

För övrigt hade jag lagt till information om när varje post skapades samt senaste uppdateringen. Om en annonsör tar bort sin annons behöver du fortfarande spara informationen? I så fall kan det vara smidigt med någon form av "raderad"-kolumn, gärna med tidsstämpel.

[zilveer]

tack för alla svar,
självklart har jag tänkt på relationerna.. just det, datum kolumn för när annonsen skapades och för när den uppdateras skall och implementeras.

jag vill väldigt gärna ha liknande annonssystem som blocket har. någon som har förslag på hur annonsdatabasen kan förbättras?

jayzee:
datatypen som jag skall använda är inte väsentlig just nu med tanke på att ja bara vill ha hjälp med strukturen.

eliatson:
visst vet jag hur den ska se ut, dock vill jag ha lite kommentarer på det jag gjort så databasen kan förbättras.

[MarZim]

Som ett första steg skulle jag göra en kravbeskrivning/funktionsbeskrivning där man i ord beskriver hur systemet ska användas och listar alla krav som finns. Det blir betydligt enklare att strukturera databasen på ett bra sätt.

Om du ändå ska skilja ut användarna med tabellen "users" så finns det kanske fler värden som går att flytta dit. T ex skulle jag fundera på att bland annat lägga "zipcode", "name", "phone_number", "phone_number_hide", "province_id", "region_id" (finns säkert fler) i tabellen users eftersom det känns som att dessa värden är hårdare kopplade till användaren än till annonsen...

[Robert]

Jag ser att du har kopplingar både till län och kommun. Jag personligen skulle ha gått andra vägen; koppla annonsen till en stad och sedan om jag behöver länsinformation tex så gör jag joins för att få in den till annonsen. Enda anledningen till detta är att kommuner och dess gränser är inte satta i sten. De ändras dock inte så jäkla ofta, men när du ändå har en kolumn för stad så kan du lika gärna peka ut den i en annan tabell.

Jag förstår ju att län och kommun är helt olika typer av arealer, för att inte prata om postens egna postorter. Hugga!