Dynamic website sportsbook project
I would like to use this thread to outline my project and gather any possible design advice. I want to create a website that is very similar to an online sportsbook only without any actual money involved. I want to list dynamic, current betting odds on sporting events, and allow users to place bets. Although there will not be real money involved, each player's bets will be tracked and recorded.
Some notes:
- The source of my dynamic betting odds will come from an XML feed. I have already written a php script that will scrape this XML and insert the data into a MySQL database.
- I will need users to be able to create accounts that they log into.
- Users will choose which bets what bets they want to make and for what amounts.This data will also be inserted into a database.
- I will have to devise a way to then manually grade the bets.
- Based on how I grade the bets, the users will have their balance updated.
- I will want to be able to create customizable reports for specific users to summarize their bets/trends.
Not sure if I'm missing anything but to me this is a pretty large project. Here is some background on my knowledge.
- Novice/learning MySQL, php. It took me about a month to learn enough php to scrape an XML feed and insert the data into a MySQL database. (I'm learning this stuff casually)
- I know enough HTML, css, php, and SQL to see some code and probably figure out what it's doing. But writing it is much more difficult for me, which is why I'm looking for web design software help.
- I've never created a website of this scale before.
I'm not even sure what kind of advice I'm looking for. I guess I'm just getting my thoughts down and seeing if anyone has any tips or ideas or warnings that I haven't thought of yet. I may add more notes as I think of them.
Some notes:
- The source of my dynamic betting odds will come from an XML feed. I have already written a php script that will scrape this XML and insert the data into a MySQL database.
- I will need users to be able to create accounts that they log into.
- Users will choose which bets what bets they want to make and for what amounts.This data will also be inserted into a database.
- I will have to devise a way to then manually grade the bets.
- Based on how I grade the bets, the users will have their balance updated.
- I will want to be able to create customizable reports for specific users to summarize their bets/trends.
Not sure if I'm missing anything but to me this is a pretty large project. Here is some background on my knowledge.
- Novice/learning MySQL, php. It took me about a month to learn enough php to scrape an XML feed and insert the data into a MySQL database. (I'm learning this stuff casually)
- I know enough HTML, css, php, and SQL to see some code and probably figure out what it's doing. But writing it is much more difficult for me, which is why I'm looking for web design software help.
- I've never created a website of this scale before.
I'm not even sure what kind of advice I'm looking for. I guess I'm just getting my thoughts down and seeing if anyone has any tips or ideas or warnings that I haven't thought of yet. I may add more notes as I think of them.
I guess my first question is why scrape the XML feed and store the data in a database?
Why not simply parse the XML feed on the fly this would ultimately reduce server load, database load and databases ultimate size.
I would also assume that user credentials would be stored in the DB. Before you start coding anything you really need to sit-down and design your entire DB then normalize it. I'm guessing that you'll need a table that holds the following username (this could be the unique PID key), password, and account balance. You'll at a minimum also need an additional table that will hold username, amount wagered, date, spread, game (i.e. Buffalo Vs Scranton), and pick. This is at a minimum, best normalization practices would have a separate table for games, picks, etc. that were linked. If your DB is properly designed then most of the function should be SQL, triggered by the user(s), amin, or code/scripts.
It is a very common mistake to not let the DB engine take on its fair share of the work load. Remember that your DB is already using server resources, depending on your hosting scenario a dedicated separate machine, so whenever possible let the resources already allocated to the DB do as much of the data processing as possible.
Why not simply parse the XML feed on the fly this would ultimately reduce server load, database load and databases ultimate size.
I would also assume that user credentials would be stored in the DB. Before you start coding anything you really need to sit-down and design your entire DB then normalize it. I'm guessing that you'll need a table that holds the following username (this could be the unique PID key), password, and account balance. You'll at a minimum also need an additional table that will hold username, amount wagered, date, spread, game (i.e. Buffalo Vs Scranton), and pick. This is at a minimum, best normalization practices would have a separate table for games, picks, etc. that were linked. If your DB is properly designed then most of the function should be SQL, triggered by the user(s), amin, or code/scripts.
It is a very common mistake to not let the DB engine take on its fair share of the work load. Remember that your DB is already using server resources, depending on your hosting scenario a dedicated separate machine, so whenever possible let the resources already allocated to the DB do as much of the data processing as possible.
Visit <a href="http://leviabbott.com" target="_blank">LeviAbbott.com</a>!
Hmm, I guess I don't know why I'm storing the XML data in a database. Just that it would be nice to have a database of all the lines from all the sports that I could later play around with and analyze. Also I guess my assumption was that querying a database is less of a load on the server than running a script to parse the XML every time I need the data. Is that a bad assumption?
Putting the XML data into a database also addresses your second point a little. I would then have a games/line table. Each game would have a unique ID which will be referenced whenever a bet is placed. I would have a table for user credentials with unique user IDs. And finally I would have a table for bets placed which would have user id, game id, date, amount wagered, side picked, result, net, etc.
Thanks for your thoughts. Once I have the database designed properly, what CC products would you recommend for the rest of the website design?
Putting the XML data into a database also addresses your second point a little. I would then have a games/line table. Each game would have a unique ID which will be referenced whenever a bet is placed. I would have a table for user credentials with unique user IDs. And finally I would have a table for bets placed which would have user id, game id, date, amount wagered, side picked, result, net, etc.
Thanks for your thoughts. Once I have the database designed properly, what CC products would you recommend for the rest of the website design?
First without sitting down and looking through the XML feed this is all theoretical but generally the feed would be very compact i.e. only recent data, not a record spanning multiple years for example. So because everything you place in the database will be stored essentially forever over time it will expand. The larger the DB the more resources required, especially if you access tables that aren't indexed.
Another reason to parse the XML and only store the information that users demand is that the XML source and structure may change in the future. If you build even one DB table around the current XML's structure you'll essentially need to start over from scratch if the XML structure or source is changed. By simply parsing the feed on the fly you get real-time info with future extensibility.
I could be wrong here but from your table descriptions you might do some quick research into DB normalization. A normalized database will really reduce your load.
Your second paragraph has me ask one question will you actually ever need the entire contents of the XML or just the games, etc. that users actually "bet" on. Will you want to extend from say only darts now to say rugby, and football in the future which would require a different XML feed?
CoffeeCup's HTML editor works great for the HTML/CSS needed for the website interface and most of your PHP and javascript components can also be done in Coffee Cup as well. Unfortunately, you are now moving away from website design and development and into the world of computer software programming. Technology advancements have blurred the line for end-users but basically aside from the end-user platform in this case a website most of what you are doing is a software application. PHP is actually executable code and not a script (like ASP or javascript) which is one of the reasons why it is so popular as a back-end for websites with dynamic content. I'd start with the HTML Editor but if you find that it is lacking you will need to begin looking around for an IDE that is more geared to your needs. The truth is you could actually write this with the tools built-into the command line of any OS I can think of, off the top of my head, but I find certain tools such as stepping in an out of code during debugging to greatly speed application development.
It really sounds like a fun project and you will definitely learn a lot! Just have fun I have never completed a project yet that when it was finished that was perfect. And neither has anyone else this the reason for software updates and upgrades. Everyone that you ask will have some suggestions for improvement, and you should consider them but eventually you will just have to bite the bullet and go with what you have and/or know.
Another reason to parse the XML and only store the information that users demand is that the XML source and structure may change in the future. If you build even one DB table around the current XML's structure you'll essentially need to start over from scratch if the XML structure or source is changed. By simply parsing the feed on the fly you get real-time info with future extensibility.
I could be wrong here but from your table descriptions you might do some quick research into DB normalization. A normalized database will really reduce your load.
Your second paragraph has me ask one question will you actually ever need the entire contents of the XML or just the games, etc. that users actually "bet" on. Will you want to extend from say only darts now to say rugby, and football in the future which would require a different XML feed?
CoffeeCup's HTML editor works great for the HTML/CSS needed for the website interface and most of your PHP and javascript components can also be done in Coffee Cup as well. Unfortunately, you are now moving away from website design and development and into the world of computer software programming. Technology advancements have blurred the line for end-users but basically aside from the end-user platform in this case a website most of what you are doing is a software application. PHP is actually executable code and not a script (like ASP or javascript) which is one of the reasons why it is so popular as a back-end for websites with dynamic content. I'd start with the HTML Editor but if you find that it is lacking you will need to begin looking around for an IDE that is more geared to your needs. The truth is you could actually write this with the tools built-into the command line of any OS I can think of, off the top of my head, but I find certain tools such as stepping in an out of code during debugging to greatly speed application development.
It really sounds like a fun project and you will definitely learn a lot! Just have fun I have never completed a project yet that when it was finished that was perfect. And neither has anyone else this the reason for software updates and upgrades. Everyone that you ask will have some suggestions for improvement, and you should consider them but eventually you will just have to bite the bullet and go with what you have and/or know.
Visit <a href="http://leviabbott.com" target="_blank">LeviAbbott.com</a>!
Have something to add? We’d love to hear it!
You must have an account to participate. Please Sign In Here, then join the conversation.