1

Here's my app:

When a user tries to access X from my site he is served it and his request is logged (his username). He can have only 10 requests/servings per day.

Now i can open, read, write to the mysql db without a problem but i was thinking of something that uses less resources, here's my idea:

Instead of connecting to the DB i create a local file for the user named <date>_<username>.txt, so for example that would be: 2011-06-16_stackoverflow.txt

Then simply do a file exists, if yes, open the file, read the accesses and if <10, allow, and ++1. (Everyday i do a cron job to delete the last days files based on their date)

Wont this be a less resources solution than using the database for ~40,000 people?

Or is it still recommended to use a DB?

Thanks!

Paul Dixon
  • 295,876
  • 54
  • 310
  • 348
Ryan
  • 9,821
  • 22
  • 66
  • 101
  • 2
    What you are suggesting is still a DB. It is just not an SQL database. It is a flat-file database. Look into NoSQL if you are interested, rather than reinvent the wheel, although right now I'd go with SQL. – Andrew Curioso Jun 15 '11 at 22:55

5 Answers5

4

Premature optimization fail. The most valuable resource is your time.

Use a database. It will be simpler, more consistent, and easier to maintain or extend. Remember: There is no problem until there is a problem.

Happy coding.

  • 1
    "Premature optimization fail" for the win. – Problematic Jun 15 '11 at 22:46
  • 1
    Partially, I agree. Do the database integration, and if concerned about optimization, test it against another implementation. On the other hand, the method he suggested isn't outrageous. He didn't ask if it was simpler, more consistent, and easier to maintain. He asked which option would be faster, which you did not address. – brack Jun 15 '11 at 22:51
  • @brack You're correct. It was written tongue-in-cheek. All functional requirements should be verified with analysis. I didn't particularly feel like getting into the details of why the performance here is likely "just fine" for a RDMBS (assuming appropriate lock control) or why a file-based system isn't inherently better (does not reduce the number of physical writes, requires more time to open resource, etc) or how it introduces race conditions, etc. –  Jun 15 '11 at 22:57
  • @pst I hear ya, and I do agree with you, which is why I commented at all; I just get chafed a little by tongue-in-cheek responses that don't provide an answer to the actual question, when you could have just left your original comment instead of creating an answer :D – brack Jun 15 '11 at 23:10
  • The filesystem *is* a database. – hakre Jun 16 '11 at 00:40
  • @hakre A filesystem can be used to model a ["database"](http://en.wikipedia.org/wiki/Database) (using the term somewhat loosely), sure. However a database -- be it an RDBMS or KVS or EAV -- is more than a bunch of data. –  Jun 16 '11 at 03:53
3

Honestly, if you're only checking requests in a single day, I'd say Memcached. Probably faster than both options you've suggested, and it's not very hard to set up. All operations performed in O(1) time.

Alternatively, a DB is fine too. Personally I'd avoid doing this with files in the way that you've outlined - the overhead of checking the file, opening the file, reading the file, rewriting the file, closing the file... All much more complicated and probably more overhead-intensive than just hitting a db.

brack
  • 659
  • 7
  • 14
  • Thank you, will check out memcached. Never used it so is it hard to do what I outlined though? – Ryan Jun 15 '11 at 23:01
  • if you have a memcached server running, it's super easy. Using a unique key, like a hash of the user name (assuming that's unique as well), you just add/replace/delete entries with the key. This might help as well: http://php.net/manual/en/book.memcache.php – brack Jun 15 '11 at 23:05
  • 1
    +1 However, one issue (which may not be an issue) with memcached is that it is *not* a reliable/persistent store -- only a caching layer (and *eviction* may be an issue). If you do use memcached, be sure to configure it to be as resilient as possible for this purpose and use compare-and-swap to avoid race conditions. Then keep in mind that it still might "forget" a users count, depending upon a whole host of configuration and run-time interactions; is this okay if it happens (infrequently)? –  Jun 15 '11 at 23:07
  • Yes, @pst brings up a very valid point- I should have mentioned that things may fall out of cache depending on configuration and the amount of data stored. As others have posted, using a DB is probably the best way to go. – brack Jun 15 '11 at 23:15
3

It is an interesting question. But as you know or will know, disk access is the most costly element of an application. In both cases, the server/application will have disk access but in the case of the database server, it will have severe optimizations involved.

In the beginning, using your own system will prove much faster than the database system but building an application requires large vision.

Structured data

What if someday, your application will offer more acess for paying users? Wouldn't it be very interesting to know which users use your service the most? To have data to define commercial offers? In that case having informations about logging that is queryable will help you a lot.

Scalabilty

What if tomorrow a lot af users start using your application, your I/O wil get saturated. Once again, the database server has several things to prevent that kind of behaviour, cache for example. Or imagine, your application is deployed on multiple servers, how are you going to do that?

Server migration

Another reason could be server migration. You will have to move the files during progres also. But hey, wait, going from a linux/unix server to a windows server is going to be a really fun task. (Ironic)

...

There are manys reasons out there. Do as you wish. It's your application. Both are viable, one is standard, the other is homemade. No one can tell you what to do. Just be sure, you're doing it for the right reasons! ;)

i.am.michiel
  • 10,281
  • 7
  • 50
  • 86
  • I know i can do as I wish in the end, but the fact I came here asking for advise should tell you I am looking for help from wiser minds... like you :) Thanks for your input! – Ryan Jun 15 '11 at 23:04
2

I'd suggest using a database, since it will allow you to easily create reports without any PHP code. There won't be any noticeable performance between file and db for what you're doing.

Tudor
  • 98
  • 1
  • 7
1

You should definitely use a Database. It is a simpler and more intuitive solution, and performance won't be an issue until you have thousands of users online at the same time.

Dan Simon
  • 12,891
  • 3
  • 49
  • 55