Which way is the 'best'?

[skulk]

I wanted to port a VB program of mine to PHP, and had a coupla doubts. The site will have a membership system, with a new line (or more) of data being associated with (nearly) every member on a daily basis. I was wondering how to go about storing that data (all the data since inception till current, would also need to be aggregated each time the user logs in):
1. I thought of having a table for every user, but i guess that would lead to a huge database, and slow the whole site down.
2. Have a single table and store every users info in that and parse the table each time, again as time goes by that table would be enormous and become slow again.
3. Store a separate file for every user and when the user logs on create a temp table and copy the csv contents to it and then proceed. According to me this would be the best, am I correct? If everything is stored in csv's, is ther a way to prevent a user from guessing the address and filename and accessing all the data?
Sorry about the long post, hope it makes sense.

[DarkX_Greece]

If your server is good in performance and your connection also then the sollution will be the 2nd!

"2. Have a single table and store every users info in that and parse the table each time, again as time goes by that table would be enormous and become slow again."

I have a project that works like these and I have more than 30000 members and the table's size is at about 150mb. It works very fast.

Also, check if the sql queries are fast. for example, at the login sql, you don't have to select all fields from the table, just only username and password.

If you need more help, ask for it.

[RudiVisser]

You should have a table of members, and have a seperate table for whatever these lines should be. Namely method 2, with 2 tables instead of 1.

For example, table 1:
USERS
-----
user_id
username
password
email
other_fields....

USER_LINES
----------
user_id
line_value

Obviously name USER_LINES whatever this line of text is going to be that is added on a daily basis...

[penagate]

As the others have suggested, a database is the best solution.
If you've not worked with a database before, I strongly advise you to invest a bit of time into studying basic relational database theory. This will help clarify how you should design the database schema, and save you time in the future when you need to make changes to the structure of the system in order to accommodate new requirements.