Results 1 to 18 of 18
Jan 3, 2009, 17:59 #1
- Join Date
- Dec 2007
- 0 Post(s)
- 0 Thread(s)
Modeling and Designing a database
I'm trying to learn more about modeling and designing databases and I figured the best way would be to actually write some local apps for academic purposes only. The first app I'm going to write is going to be very simple, it's just going to store specific information for each specific user. The data I'm going to be storing is:
state - for a specific search, like find all users in California
email - for login
pass - for login
........ - the main "data" for each user, 10 hyperlinks to wherever.
My first question is, for something this simple, would having just one table be OK? Assume there could be lots of users and the DB might change down the road. Maybe the fictional boss wants users to have up to 25 links so an additional 15 links will need to be added to the table. Also, users might not actually provide 25 links (that's just their limit) so there could be a lot of null values being stored.
I've also broken this down into 3 possible tables (with this being the primary key) so this is my attempt at listing an entity relationship diagram here:
The cardinality I've come up with, which might be a bit hard to decipher is:
State 1-----(contains)-----M Users 1-----(has)-----M Links
1 State can have many Users, many Users can live in 1 State (Users -> State is M to 1 relationship).
1 User has many Links, many Links can belong to 1 user (Users -> Links is 1 to M relationship).
Does this look OK? Is this the better way to do this, even though it adds more complexity than the first example of just one table?