I'm designing a PHP/MySQL solution for my youth athletic organization that will display schedules and standings for the teams participating in any given season. Unfortunately, I'm just learning the ropes when it comes to database design and having a bit of a challenge wrapping my brain around what should be a relatively simple concept. Perhaps someone can step in and clarify a few points?
What I'm unclear on is how exactly to structure the database(s) and tables to get started correctly. This is what I will ultimately need to set-up:
We have approximately 50 member schools. Each will need their own log-in ID and password. I was thinking about storing these in their own separate database because the accounts will be re-used again each season to represent teams and allow the coaches to log-in and update their game results.
Each season has two different sports. For example, the upcoming fall season has a girls volleyball league and a boys flag football league. Each league then has multiple divisions (divided by geographic region) in which the schools play their regular-season schedule. I'm not sure if each season needs its own separate database, each league, etc.
Each division's regular-season will be imported from a scheduling program (via an Excel spreadsheet) and displayed on its own webpage where schools can view their upcoming games and log-in to update results.
As game results are updated, I'm going to need to find a way to have those results reflected on a separate webpage where that division's league standings are displayed.
For a clearer demonstration of what I'm trying to do, have a look at these two mock pages I created for the schedules and standings data, respectively:
http://www.712jefferson.org/pal/schedules.html
http://www.712jefferson.org/pal/standings.html
This is where I'm looking for your guidance. How exactly should I structure the MySQL framework for all of this data?
I'm thinking a separate database for the school log-in ID's and then a separate database for each seasonal sport (e.g. Boys Volleyball 2013) with separate tables for each division and x-number of columns to represent the schedules and standings therein.
Does that sound about right? Am I thinking about it all wrong? Any assistance or guidance to help flesh out this thought process would be MUCH appreciated!
Thank you so much!
Ouch. You have taken on a big job. Are you absolutely sure that nothing you are going to do cannot be done by something that is already available? Well, if you are sure, read on.
Firstly, the hardest part of what you want to do is managing your user access. I'd advise that you start off by writing your user management module before you go any further.
For what you want, it seems likely that Drupal or one of the other senior CMS systems would be a great way to bootstrap the system. Drupal will handle your user management right out of the box (or with minimal problems) and you could write the rest of your code as static nodes. This also makes it easy to add blogs, forums, news and to manage mailing lists etc.
As stated in the comments above, you do need to keep your data together. it would be good to keep data for historical comparisons too.
If not extending a CMS, after you have got back from the psychiatrist, you will need something along the lines of:
header file to access the db and check for user authentication.
footer file to display your data
individual page files to present or obtain your data.
Database structure for handling the users (at minimum) should be IRO:
Person - details of individual users
username - link person to a username
email - email addresses
club - sports club details
password - passwords
logon - record of logon attempts
role - record of role of individuals in your site
permissions - list of required permissions to access areas of the site
role_permissions - default permissions for each role
person_role - link person to role
person_permissions - link person to permissions (only needed if some individuals need extra permissions not given routinely by their role)
club_person; person_email; - link people to clubs and to their email addresses.
To handle the matches you will need:
team - team name, group and club reference
grouping - list of groups eg by age.
divisions. - list of divisions
venue - list of venues. Include GPS!!!
match - division, grouping, team1, team2, venue, date, time
result - team1 reported result, team 2 reported result, approved result (you may need to intervene!) match.
As you can see you need a fair few tables but YOU MUST NOT try to do the fun stuff with the actual teams UNTIL you have your user access working properly.
What I have sketched out for you is a db in normal form. No textual data is duplicated and the data is easy to retrieve, index and display. I do feel this question is too broad for SO as designing a database for you is a bit out of scope but I do think the general format is useful.
Each table should only contain unique necessary data eg:
Person: personid int, surname, forename, style, whenadded, whoadded, inuse
email: emailid, email, whenadded, whoadded, inuse
email_person: emailpersonid,emailid,personid, whenadded,whoadded,inuse
This allows multiple people to share one email and multiple emails to be applied to one person with no text duplication. IDs should be type INT AUTO_INCREMENT PRIMARY KEY rather than SERIAL as this saves a whole lot of storage space and you'll never fill an INT in this application.
The other tables should be created in the same way. The whoadded and whenadded columns are optional and quite storage hungry but can be very useful. inuse is essential set this to a BOOL and you can remove teams without deleting them - the data is not lost. A whenremoved and whoremoved is useful too for audit.
A word on passwords - please ensure you store these as a SALTED HASH. If you do this, when your site is hacked, no-one will have the password that they also use for their internet banking exposed. People are often idiots. You have to look after them.
As I said, a bit out of scope so I'll end the answer there - it gives you as requested the basic outline of a 4th Normal Form Db that will be robust and extendable but leaves you to do the work. Why not ask more questions if the problem turns out to be too hard.
Good luck.
ADDED:
DIY Framework:
If you don't want to learn to use one of the existing frameworks or CMS, you will need to write your own. Oddly, this is actually very easy.
header.php:
<?PHP
$mysqli=new mysqli(credentials....)//connect to database and present a mysqli or pdo object.
session_start(); //open a session
//you will need to authenticate your session here - see below
?>
footer.php:
<HTML>
<HEAD>
<TITLE>
<?PHP echo $pagetitle;?>
</TITLE>
</HEAD>
<BODY>
<?PHP echo $content;?>
</BODY>
</HTML>
These are used by mypage.php:
<?PHP
require("header.php");
//do some stuff that generates $content
$pagetitle="mypage.php";
require("footer.php:);
?>
It should be stressed that this is the bare minimum you will need and is truly sucky - it is just presented to show how this should be begun, not an exemplar of ideal code. It will work though.
The key is creating a header that presents the variables you will need, such as a db connection, username, user logon status etc. and a footer you can enter details into to present the data. The footer is the only place where you combine HTML and PHP.
Use your $_SESSION to store information that needs to persist between pages.
These files can be as simple or complex as you like - I created my own ages ago that do several checks on the user and session and can display scripts, custom CSS files and such in the footer. It's not hard to do if you start simple and build on as you need. SO will be here to help you.
One word of caution: although you can start very simple, what you are trying to do has legs and will get out of hand. Please audit your code after you have it up and running to make sure that you have not inadvertently included security flaws. It is very easy to include these as you get into a project and need a quick fix and they can be devlishly hard to spot later on unless you are looking for them.
I am in your shoes, and the best solution I found was to use Backend as a Service (Baas) providers such as Parse.com or Stackmob.com or many others. They do complete database hosting for you plus your user management (login/register/forgot_password etc) so you don't have to worry about it. You access them via REST API and they also have PHP libraries on the Github.
Since you are new to database management, which is a non-trivial task, this solution may save you some headache.
Of course, you still have to decide how to organise your tables (or 'classes' in Parse, 'schema' in Stackmob etc) but they also provide help with their relation APIs. They have a pre-defined User table specifically designed for storing users.
Surely their API is not as flexible as SQL but it also safe from SQL injection, a downside of that flexibility. On the other hand, they also offer custom code to enhance that flexibility.
Edit. Forgot to mention, those BaaS platforms also allow to store arrays as database fields, which can be really handy.
This can be a big build. You may want to try an existing service for league management. There's a few out there. I know a few friends who use Teamopolis and are very happy with the service, and I think it accomplishes everything you're looking for.