Re: PHP and databases? ...without MySQL and such

On Wed, 23 Oct 2002, Maxim Maletsky wrote: > Yes, for configuration purposes it is more clever using flat files. BUT, > for as long as you don't need (and know you'll never need) any of the > following three things: > > 1. Anything more than just one single PHP file made in your text editor. Not sure what you mean by this. If I write a single suite of data handling routines then it doesn't matter if I have one or 10,000 pages using it. > 2. Dynamically modifying your configuration files. File locks? Not a hard or complicated thing. > 3. Per-user based configurations like to store things for later, > frequent use. ndbm type solution is much better suited to this unless you have complicated querying requirements. And unless you are dealing with many users a simple unix type password table or user configuration files is perfectly sufficient. > > > or a low volume shopping cart system, > > Completely wrong. Normally, (at 90% at least) when you think of running > a shopping cart, even of a low volume but with use of PHP, you'd think > of database as it is: > > 1. Simpler developing a database in SQL than in some Flat Files logic. > This means investment saving. Sessions are ideal. SQL buys nothing at all but complexity. A shopping cart is a list of items - you do not need to do multi-key/foreign key look ups to deal with it. > 2. Having the possibility of an unpredicted business growth. For > instance, some inexperienced developers not know that a Linux system So.... if you've written your applications correctly and you see that the file based session version of your shopping cart is having problems (though frankly I can't imagine at what point this would happen)...you change the one or two lines needed to switch to ndbm based storage of sessions or if you must, mysql based sessions. > Agreed and disagreed: Yes, it may sound that it is easier to access a > file than a database, but at the same time there are less worries > maintaining that file.Remember, you'll need to be locking AND unlocking > a self-updating file as there is a risk of corrupting and lose all your > data, besides getting errors all the time, on multi-threaded web servers > if the file happens to be saved simultaneously within different > requests. Very possible to happen with even 100 visits per day. File locking is trivial. I would much rather worry about that then worry about backing up data bases, checking to make sure I can talk to the db, dealing with network outages dealing with speed issues, especially in a heavily shared environment as exists in most/many hosting companies. > Plus, you forgot to mention the three most important things: > > 1. Data Integrity: > Something that needs to be taken care of in order not to mess the > data the data. Similar to above. Until recently MySQL didn't have transaction protection. In many hosting environements it isn't offered. If you are not using the roll back capabilities of the latest versions of MySQL then you do not have data integrity. > 2. Security: > A file can be read by anything within the server while DB needs a > password. Few that think a DB is "expensive" own their dedicated > servers. The password needs to be stored somewhere on the file system - there is no advantage here. I wold hope you are protecting accounts and files with appropriate file permissions. > 3. Performance: > Just store a few variables will work with a flat file, but doing a > little search within the data will decrease site's response times > tremendously. If you have complicated searches over a lot of data then yes, a data base is appropriate. I didn't say it was never the way to go. But - I would take issue with this statement. "a little search" on a few variables is almost always going to be faster in a flat file unless you are refering to finding a few records based on a key. > > Using a db to store php hashes in can be remarkably simple and effective in > > the right situations. > > Indeed it is. I was refering to an ndbm type db here. > Conclusion: > > 1. Flat files - for site configurations > 2. Database - for data manipulations Databases are suitable for situations where you have a large amount of complex data that you must do complex operations on. The trade off will be the extra maintenace you must do and the additional potential points of failure you must contend with. You did leave out the one reason that would make the use of a database for even simple data potentially the right way to go: if you are dealing with a more robust environment where there are multiple machines that need to access to the same data (ie load balancing a group of web servers for a single application). However, even this isn't an absolute as I can see situations where an NFS mount would serve. My contention is that the statement "always use a database" is not the best advice.