User Name Password Register
DaniWeb IT Discussion Community
All
What is DaniWeb IT Discussion Community?
You're currently browsing the Database Design section within the Web Development category of DaniWeb, a massive community of 426,139 software developers, web developers, Internet marketers, and tech gurus who are all enthusiastic about making contacts, networking, and learning from each other. In fact, there are 1,755 IT professionals currently interacting right now! Registration is free, only takes a minute and lets you enjoy all of the interactive features of the site.
Please support our Database Design advertiser: Programming Forums
Views: 1578 | Replies: 4
Reply
Join Date: May 2007
Posts: 35
Reputation: matale is an unknown quantity at this point 
Rep Power: 2
Solved Threads: 1
matale matale is offline Offline
Light Poster

Question DB diagram question

  #1  
May 14th, 2007
When drawing DB relationship diagrams, do you usually show all the relationships? Because I seem to have lots of them and my diagram is geting very messy.
Sample Pic attached, I didnt even fill in all of them in this diagram
Attached Images
File Type: jpg erd.JPG (54.4 KB, 13 views)
My current Project www.footystat.com
AddThis Social Bookmark Button
Reply With Quote  
Join Date: May 2007
Location: Warrington, England
Posts: 31
Reputation: SkinHead is an unknown quantity at this point 
Rep Power: 2
Solved Threads: 2
SkinHead SkinHead is offline Offline
Light Poster

Re: DB diagram question

  #2  
May 14th, 2007
No, Not Always. If The Diagram Is Getting Messy, Then It Points Towards The Database Design Needing A Look At.

I've Checked Out The Sample Pic & My Thought Is That There's A Lot Of Pairings Of Player_ID & Team_ID. Maybe A Seperate Table With These Two In Would Rationalise Things A Bit.

Good Luck With The Website
Reply With Quote  
Join Date: May 2007
Posts: 35
Reputation: matale is an unknown quantity at this point 
Rep Power: 2
Solved Threads: 1
matale matale is offline Offline
Light Poster

Re: DB diagram question

  #3  
May 15th, 2007
I though about that(New diagram attached), but this means that my SQL queries are going to be much more complex, becasue I cant for example look for total goals scored by a player using just the playerId value on the Goals table, I would have to join 2 or 3 different tables to do that.
Attached Images
File Type: jpg FootyStatDBsimple.jpg (69.1 KB, 9 views)
My current Project www.footystat.com
Reply With Quote  
Join Date: May 2007
Location: Warrington, England
Posts: 31
Reputation: SkinHead is an unknown quantity at this point 
Rep Power: 2
Solved Threads: 2
SkinHead SkinHead is offline Offline
Light Poster

Re: DB diagram question

  #4  
May 15th, 2007
I Think The New Layout Is Better.

I Wouldn't Worry Too Much About An Extra Join In The SQL Query. So Long As The PKs Are Integers & You Use Clustered Indexes (Assuming You're Using SQL Server / Oracle...)

A Couple Of Other Ideas :

The YellowCards/RedCards Could Be Made Into One Table With The Inclusion Of CardType Field.

The Player Table Is Really Just A Person Table. The Person Only Becomes A Player When Associated With A Team. If You Only Want To Include Players & Not Others Like Managers/Coaches etc, Then Why Not Put The Player Info Into The TeamPlayer Table. This Will Reduce The Table Joins By 1

I Know It's Still Eraly Days, But You Haven't Included The Score In The Matches Table.

Also, What About Own Goals In The Goals Table !
Reply With Quote  
Join Date: May 2007
Posts: 35
Reputation: matale is an unknown quantity at this point 
Rep Power: 2
Solved Threads: 1
matale matale is offline Offline
Light Poster

Re: DB diagram question

  #5  
May 15th, 2007
Originally Posted by SkinHead View Post
I Think The New Layout Is Better.

I Wouldn't Worry Too Much About An Extra Join In The SQL Query. So Long As The PKs Are Integers & You Use Clustered Indexes (Assuming You're Using SQL Server / Oracle...)

A Couple Of Other Ideas :

The YellowCards/RedCards Could Be Made Into One Table With The Inclusion Of CardType Field.

The Player Table Is Really Just A Person Table. The Person Only Becomes A Player When Associated With A Team. If You Only Want To Include Players & Not Others Like Managers/Coaches etc, Then Why Not Put The Player Info Into The TeamPlayer Table. This Will Reduce The Table Joins By 1

I Know It's Still Eraly Days, But You Haven't Included The Score In The Matches Table.

Also, What About Own Goals In The Goals Table !


Cool.
I was thinking the score would be calculated from the Goals Table, but it might be simpler to include it your right.
The own goal thing seriously never crossed my mind
My current Project www.footystat.com
Reply With Quote  
Reply

Only community members can participate in forum threads. You must register or log in to contribute.

DaniWeb Database Design Marketplace
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

 

Thread Tools Display Modes

Similar Threads
Other Threads in the Database Design Forum

All times are GMT -4. The time now is 4:51 am.
Forum system based on vBulletin Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
©2003 - 2008 DaniWeb® LLC