[SOLVED] How to avoid using database?

[fry2010]

Here is the situation:

 

10 users click into the page 'arena.php'.

I want to show a list of everyone on this page like so:

 

  1)User 1

  2)User 2

  3)User 3

  4)... etc ...

 

And I want this list to be viewable by everyone on that page.

When someone leaves the page I want to remove them from the list.

 

So normally for a situation like this using a MySQL database would do the job, you just insert the users name into the database, and show the database on the page. Plus using ajax this list could be updated on the fly.

 

But I want to avoid using a database with this.

 

The question:

 

Is it possible to have a php array visible to every user and use this as the database instead?

I think I already know the answer to this (No!), but I just want to check to see if there is a way to work around this problem.

 

The reason I dont want to use a database is because say I have 500 users, then my site is going to slow down with all the constant database updates, and deletes etc... not including all the other database connections going on elsewhere.

 

Anyone got any ideas?

[laffin]

serialize/unserialize/file_get_contents/file_put_contents.

 

remember to give the file read/write permissions.

[anupamsaha]

Here is the situation:

 

10 users click into the page 'arena.php'.

I want to show a list of everyone on this page like so:

 

  1)User 1

  2)User 2

  3)User 3

  4)... etc ...

 

And I want this list to be viewable by everyone on that page.

When someone leaves the page I want to remove them from the list.

 

So normally for a situation like this using a MySQL database would do the job, you just insert the users name into the database, and show the database on the page. Plus using ajax this list could be updated on the fly.

 

But I want to avoid using a database with this.

 

The question:

 

Is it possible to have a php array visible to every user and use this as the database instead?

I think I already know the answer to this (No!), but I just want to check to see if there is a way to work around this problem.

 

The reason I dont want to use a database is because say I have 500 users, then my site is going to slow down with all the constant database updates, and deletes etc... not including all the other database connections going on elsewhere.

 

Anyone got any ideas?

 

Create the array and store it in session(). Display the array from the session() in the pages.

 

[fry2010]

Laffin:

Ok so you are suggesting to put the data into a text file? This was a method I considered. Is it possible you can elaborate a little on serialize and unserialise? Thank you very much for the suggestion...

 

anupamsaha:

That method sounds interesting, but would it still not solve the problem because the session is created on the users end, not on the server? i.e. the arrays contents will not be available to everyone? Or am I wrong?

Again thank you very much for this suggestion.

 

Plus on second thought, using an array is probably not a good idea, im sure there is a limit on the size of an array, so I cant have a 500 plus array size, thats just silly. So I think I will have to avoid array.

[Ken2k7]

You're worried about DB usage but not about writing and deleting data from a file? Wouldn't it take more resource work to write and delete things from a file?

[Mark Baker]

Is it possible to have a php array visible to every user and use this as the database instead?

I think I already know the answer to this (No!), but I just want to check to see if there is a way to work around this problem.

APC

[fry2010]

ken you make a good point! I have no idea if its slower or faster... but if your saying that it could be im guessing that it is.

 

Mark Baker do you have some kind of magical answer for me with APC? If so can you ellaborate some more please?

[Ken2k7]

I assume Mark's talking about caching. Google PHP APC, which stands for Alternate PHP Cache

[fry2010]

amazing! that sounds like it will do the job. Am I right in thinking it will store information on the server that is accessible to all users?

 

The trouble is, you need PEAR and my attempt at installing PEAR failed HARD. I had a couple of missing components and some other crap so I didnt fully install. I guess I will have to get that to work.

 

If I try to install PEAR again and there is missing components can I just type in the command line:

pear-get install *missing component*

 

This is similair to what is described if you get missing stuff in the APC install?

 

Againt thank you mark and ken!

[laffin]

SQL will use more resources than a filebased system.

if done right, the filebased system can be faster as well.

 

Question is how to u plan on flagging online users.

and wut the deletion system is gonna be.

 

Options

FileBased, More Code

SQLite, Simple and effective, close to full SQL. FAST. Supports File/Memory Based Operations.

MySQL, using Memory tables. MySQL MEMORY/(heap)

 

 

It really depends on the operations required. and how insertion/update/deletion code will operate (more php or more sql)

 

SQLite is kinda nice alternative, uses a flat file DB, if your not using the memory model. Is fast, and comes with php 5.0>

 

[fry2010]

i am going to give this APC extension a go, but thanks for the tips.

finally a big thank you to everyone that has responded, the help on this forum is amazing and very fast. There seems to be a lot of respect to fellow coders, which makes a change from normal forums.

[roopurt18]

I'm really not sure why you're against using the database for this.  A single table with 500 to 1000 rows with one or two columns and no indexes should have decent enough performance; you don't need the index because on tables that small I think many database systems will just perform a full table scan anyways.  Plus with the database you don't have to worry about users fighting over a file.

 

Perhaps the APC solution will work for you; I don't know anything about it though.

 

Lastly, you could create a RAM disk, which works in both Windows and *nix.  This will eliminate the need to read and write from the HDD constantly so performance should be greater.  Also, since the disk lives in RAM, if the server goes down or is rebooted all of the files there will go away so you're not left with crap all over the place from a crashed system.

[fry2010]

well roopurt the thing is if I have several games with say roughly 300+ users and people always leaving the page, entering the page etc, plus with all other database connections not to do with game such as users registering, loggin in, loggin out, changing details, winning a game, loosing a game etc the list goes on. I just assume that all these database queries will pile up and cause slow performance. So I want to attack this part of it because it is likley to have the biggest effect of boosting performance.

So are you telling me know that none of this matters you can have lists of users and loads of queries and performance effected is minimal?

[Philip]

From what it sounds like, you need to use a database not flat files.

 

If you're worried about high traffic loads, 300 users really isn't that much - but optimize your queries and ultimately use a cache to store frequently used data. I use memcache just because its more expandable for larger sites, but APC should work find for you.

[fry2010]

well i am talking about in the future, obvoisly it will not start at 300 users, but eventually it *could* go beyond this, so I want to do the hassle of solving the problem now rather than later.

Lets say I have about 8 games, and 300 users on the game page, per game. So thats roughly 2400 users. Ok so most of these will not be effecting the database until they do something, but there will be other things going on. I am also probably going to be doing something within the games themselves to do with the database.

 

When you say cache data with the database, is this what APC will do? From what I read breifly in the docs it stores data intermediatly, which I assume meant on the server? So how is this connected to the database? I didnt think it would require a database?

 

Im more confused now, if you experts think that database is the way to go and the performance will be fine, this will make my life a lot easier. But if not then I dont mind the hassle of doing this caching thing on the server side.

[Daniel0]

I'll assure you that databases can take a high load. That is of course if you designed the schema well and optimized your queries.

[fry2010]

how do you go about optimising queries and the schema?

 

I will only be making minimal requests on each user that loads the page or sends a challenge request. Also it will be using ajax.

 

So a query to update the list might look like this:

 

"INSERT INTO game_arena1 (players) VALUES ('$user')"; 

 

Then to display the list something like this:

"SELECT players FROM game_arena1"

 

Then when a user leaves the page somthing like this:

"DELETE FROM game_arena1 WHERE players = '$user'";

 

As to the schema there is not a lot of give really with the way I have set out structure, i think its quite optimized as it is...

but then i might have the wrong end of the stick.

 

Im going to mark this as solved I think there is enough help from you guys to do it now, but still keep the suggestions comming if you think it  is better, thank you.

[roopurt18]

I just assume

 

There's your problem right there.  You're "optimizing" without any evidence that it's necessary; I surround optimizing with quotes because you aren't even sure the performance gains will be worth it in your case.

 

You should just write it now with the database as the solution and use it that way until it breaks, which may never happen.  And when it does you may be able to fix it by adjusting some configuration parameters somewhere, a small hardware upgrade, or something else.

 

If you're worried that fixing it later will require a code rewrite, then this is where encapsulation is your friend.  Write a PHP class to encapsulate the storage mechanism of this page, call it UsersOnXYZPage.  Then in your xyz.php page, whenever you need to know which users are online, edit which users are online, or delete users online, you use methods exposed by your UsersOnXYZPage class.  Your UsersOnXYZPage class will handle the storage mechanism, be it database, file system, RAM disk, cache, telekinesis, or fibble-fobbles.

 

Should you later need to rewrite the storage mechanism, just rewrite the underlying structure of your UsersOnXYZPage class to no longer use the database, but to use whatever storage solution is deemed most appropriate at that time.  Since your xyz.php page only access data through the UsersOnXYZPage class and the methods in UsersOnXYZPage don't change (i.e. the interface remains constant), then everything else should just keep working.

 

That's how I'd do it anyways.  You could spend endless hours optimizing or adding features that you don't even know are necessary.  Or you could write flexible and expandable code and only work on what's necessary to get the job done knowing you can easily modify it later.

[laffin]

How do u perform login/logout detection?

 

[Daniel0]

"U" is a letter, not a word. Just saying.

[fry2010]

lol daniel, if you mean what I think you mean then yeah ill do that. Just use letters and digits to signify on or off etc. I already implement that for logging user in and out with a 1 for logged in and 0 for logged out. If thats what you meant...

 

Roopurt I suppose that makes sense, I probably wouldnt even need to create a class to be able to change it. tbh though there is only so much one person can do, if I keep making everything expandable and portable id never get finished. As it is I only have the bear template html so I can start to piece together this site. I find doing large sites tend to take forever because of loads of little issues slowing me down. nevermind.

 

Anyway mysql it is with ultra optimised queries and data. thanks all.

 

edit: laffin sorry I dont understand fully, I havnt actually got the main structure going yet, most of it is on paper, with just bare html. But i intend to log user in and out by assigning it to their username in the database with either 1 for logged in, or 0 for logged off.

[Daniel0]

fry2010, no, I was referring to laffin's post above mine.

[roopurt18]

I'm pretty sure daniel was just picking on laffin's lazy typing skillzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.

 

What laffin meant is how do you intend to know when a user has logged out?  It's easy when they actually click a Logout link, but what if they just walk away from the computer and their session expires?  You have to detect that.

 

if I keep making everything expandable and portable id never get finished.

Likewise if you keep adding features or optimizations that you have not found to be necessary.  The rule in software design is add only what is necessary and if a certain feature may need to be changed later, then encapsulate it's functionality so that when you do change it, the rest of your code keeps working on top of it.

[Mark Baker]

If you're worried about high traffic loads, 300 users really isn't that much - but optimize your queries and ultimately use a cache to store frequently used data. I use memcache just because its more expandable for larger sites, but APC should work find for you.

APC is faster than memcache, and quite capable of handling large data volumes (dependent on how you configure it). The drawback is when you need to start distributing across multiple servers because each server can only access its own local APC cache, and using memcache comes into its own because it is common across all your web servers.

 

[fry2010]

roopurt, well if i need to change it that is easy to do, as I would just test it first before uploading the new code. Doesnt need to be complicated, because using ajax will ensure the changeover is smooth anyway.

So how would you detect when a user just leaves? thats a good point i hadnt thought of that.

I felt that avoiding the use of a database was neccessary tbh, which is why I asked the question.