Using an engine to create content with PHP - but how should it happen?

Question

I need to create an engine that will allow me to add content to a website. The website is a browser-based game. This is a verbose engine that should be able to handle many different aspects of the project.

For an example, I want the developers to be able to insert "dreams" into the game. A dream is called each night for the player, and upon login they will see the dream they had. A developer will write up a cool dream for the game and insert it... but to where?

That's what I'm struggling with. Naturally, I think to myself that all content for the game will enter a database once a developer is done with it. However, the amount of content could be potentially very high, and it may be too hard on the server's resources once the game grows bigger - userbase included. The other way to do it to simply hardcode everything in: a simple "dreams" file that a developer would append their dream to. I cannot have such a system, however, if this project were to have five casual developers that don't know how to even open a PHP tag! ;)

Presently the best way I can imagine a player receiving a dream is to have a developer write it and then the database pulls the dream the player receives from the database. It seems unnecessarily arduous and I'm hoping that if I still must use a database, that you folks can steer me into the right direction for how to execute this efficiently.

Answer 1

From reading your question and comments, I get the sense that you don't quite understand relational databases. So I guess my biggest recommendation to you, is for you to make sure you understand their strengths; the concepts of a primary key and a foreign key are especially important.

It is also difficult to discern exactly the question here - I think you're not even sure exactly what you are asking. Your actual question is "how should it happen?" and from the description you seem to be weighing the use of a database against hardcoding these dreams. And somewhere in there you seem to have a notion that a database won't be able to handle a large amount of data - which, I mean, isn't that sort of the point of a database? So if you think a database somehow can't handle some magnitude of data, you must not have much experience in the corporate world. Let me tell you, databases handle ungodly amounts of data and they retrieve it faster than you would think possible. They're made for that kind of thing.

Anyway, all of the above is subjective, and if you're dead set on storing these dreams in files, by all means do so. Just make sure you know your reasons, and that they are true, measured reasons. To guess that a database is slower is simply unfounded (or I'd like to know where you got that idea).

So go read about relational databases, know what a primary key and a foreign key are, and then look at this simple schema that I think is basically what you need:

table 'users'
  id int primary key
  ...

table 'dreams'
  id int primary key
  description text
  ...

table 'userdreams'
  id int primary key
  userid int foreign key on users.id
  dreamid int foreign key on dreams.id
  ... (maybe some data about whether the user has read the dream, or a timestamp)

(the above is, of course, pseudocode)

So the users table is where user details are stored - username, hashed password, etc. The dreams table is added to by the designers, and you can make a nice designer-friendly form that lets them write dreams and submit them into this table. And then the userdreams table is what ties the two together; each night you insert one row into this table per user, which has their userid and the id of the dream the user has (or more likely, when an user logs in you check if they haven't logged in since the previous day, and if not then assign them a dream and pretend as if the dream had been given to them overnight - but that's an answer to a different question).

Does this sound like the appropriate answer to your question? If not, please try to clarify a bit more. As I said, it's difficult to tell exactly what needs answering.

Answer 2

However, the amount of content could be potentially very high, and it may be too hard on the server's resources once the game grows bigger - userbase included. The other way to do it to simply hardcode everything in:

What makes you think that a system can cope with it in hardcoded form, but not when it's stored in a database? Databases are designed to store far, far, FAR more information than you would find in any typical code base.

Most online games, and indeed most sites, use a database these days. It shouldn't be arduous if you use a reasonable database API for it.

Answer 3

I would like to introduce you to this neat concept we call a content management system.

Also, listen to Kylotan.