Darren Henderson <darren@bmv.state.me.us> wrote... :
> > 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.
I meant a file to write and store the data. A configuration file, for
example.
> > 2. Dynamically modifying your configuration files.
>
> File locks? Not a hard or complicated thing.
But isn't a RDBMS easier and safer at that point? A very big point,
actually.
> > 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.
Yes, if you never have to touch individual user's data from within an
admin area. But, if you want to do more things than just loading
variables - you need "querying" each file :)
> > 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.
I didn't talk about sessions and multy-key/foreign-key staff yet. All I
want to mention is that, creating a logic between Flat Files is not a
simple thing, and, often, SQL usage will be easier. Unless one doesn't
know SQL at all and take really long time to start using it. Files are
more intuitive, true, but less complex than SQL.
Consider this for displaying an item out:
<?php
$link = mysql_connect("mysql_host", "mysql_user", "mysql_password"));
mysql_select_db("my_shop");
$result = mysql_query("SELECT * FROM products WHERE product_id = $id");
$product = mysql_fetch_array($result, MYSQL_ASSOC))
?>
Againsts this:
<?php
include("/a/huge/file.php");
$product = $data[$id];
?>
Easier with files, no? But, soooo limited... for a shopping cart is not
optimal at all. You will have to be quite experienced to write data in
PHP syntax with a solid logic and locking files. If you are, then your
experience will tell you - just get a DB, it's better.
> So.... if you've written your applications correctly
Let me cut it here: if one writes an application correctly - it means it
will write it with a DB, not flat files for a shopping cart.
> I would much rather worry about that then worry about backing up data bases,
every RDBMS has such utility.
> checking to make sure I can talk to the db
What about checking to make sure file is still writable (by anything on
the server?)
> dealing with network outages
Not always a need.
> dealing with speed issues,
RDBMS is faster in most cases, and, even if not then the downgrade
rarely goes over 1-10 milliseconds for things accomplishable also with
Flat Files.
> especially in a heavily shared environment as
> exists in most/many hosting companies.
believe me, files are worth in these cases :)
> 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.
Data integrity is not only everything we hear about Oracle and what
mySQL only now is trying to implement. Data Integrity is also knowing
that the data is controlled by an application specialized in that.
If you need a real data integrity look for PostgreSQL that is Open
Source (or expensive Oracle which is the maximum of Data Integrity
logistics).
> 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.
You are right about this. But, theoretically, it is still easier to
steal a folder than a DB.
> 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.
If you ever write files, then at least write PHP files that can be
simply included and referred by array keys. Then yes - files are faster.
But, if data is big than not.
Database is also portable, and portability is VERY important in
programming.
> > 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.
But truly, the one that knows to handle files well normally has no
problems writing SQL either and/or keeping a DB server up. Be reasonable.
> My contention is that the statement "always use a database" is not the best
> advice.
My contention is: "always use a database as the base for your data"
or
"Always use 'files' to store the things to include in files"
--
Maxim Maletsky
maxim@php.net
www.PHPBeginner.com // PHP for Beginners
www.maxim.cx // my Home
// my Wish List: ( Get me something! )
http://www.amazon.com/exec/obidos/registry/2IXE7SMI5EDI3
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
