1

I am planning on creating a database to track teams and players in a soccer league. The stats I wish to track are as follows...

goals scored/conceded(gk), assists, minutes played, cards received and leading scorers.

As well as overall standings and fixtures and results. I have created an ER diagram and I think I have all the required tables but have some m:n relationships which I know shouldn't exist so am hoping my relationships are correct

Update updated er diagram enter image description here

I may or may not include the second tire of this league otherwise I don't think I actually need the league table.

will it cause me any problems if i implement it as is. i am not sure if it is ok to have 2 cols in the fixtures table that are referencing one column from the teams table. And my goals_scored table has the same two fk's as my player_match table.

Am I anywhere near the right track? Any help would be appreciated.

3
  • 1
    have some m:n relationships which I know shouldn't exist - WHY do you think m:n relationships shouldn't exist?!?!?!?! Those are just a fact of life! Nothing wrong with that! Where did you "learn" that???
    – marc_s
    Jan 30 '15 at 16:44
  • my understanding is many to many relationships should be worked into a new table. Jan 31 '15 at 16:28
  • Yes, it's called a joining table - perfect for implementing m:n. Consider "flight" and "flight_crew" tables. Each flight will have many crew and each crew member will fly many flights. To be able to tell which crew member flew on which flight, you have a joining table "roster" - with (flight_id, crew_id) both foreign keys into their respective tables. @marc_s is perfectly correct when he says they're just a fact of life, as I hope I've illustrated above. P.s. thanks for the "correct answer".
    – Vérace
    Feb 2 '15 at 16:27
0

Do a Google of "open source soccer league software" and you will find a plethora of offerings already on the "market". My advice to you is to download a few of these, play with them (use last year's results).

See which ones come closest to what you want to do. Then take a look at their database schemas (and code if it's written in something you can read) and adopt and adapt the bits that suit you and leave the rest.

Unless you're planning to do this as a hobby project (and even then), but if you want to get up and running quickly, this is probably a good strategy.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.