On Tue, 3 Feb 2004, Bill Stephenson wrote:
> If I am building a web app from the ground up, what's the best way to
> deal with storing/retrieving data?
It's not by accident that databases have come to be popular for this kind
of work. Pick one -- MySQL, PostgreSQL, SQLite, or something "real" -- and
let it do as much work for you as it can. In the end, you'll be happy.
IMO, XML is good for certain kinds of data portability. Exchanging
information between different systems -- via XML-RPC, for instance --
would be one example, but things like config files can also make sense, in
that you can write code in different languages to talk to the XML files.
On the other hand, XML isn't a panacea, and it doesn't make all problems
go away. Flexibility, for example, isn't promised; databases tend to run
circles around XML if you want flexibility </overgeneralizing>.
I think that keeping data in XML makese less sense than keeping it in a
simple database like MySQL -- really, it's not very hard -- and writing
code to wrap the results in XML if some other application needs to share
your data. A good template library (Perl has gobs of 'em) can make doing
that easy -- I hear there's a new O'Reilly book _Perl Template Toolkit_
that even has an XML chapter </hint> </bias> :)
> I hear MySQL is speedy, but it seems to me that it adds complexity to
> such a degree that it may not be an even trade off. I could store data
> in an XML format in a single field in a MySQL database, but I'd still
> have to parse it.
Nah, you may be overthinking this:
use DBI;
$dbh = DBI->connect("dbi:SQLite:dbname=~/salaries.sqlt", "", "",
{ RaiseError => 1, AutoCommit => 0 });
eval {
$dbh->do("INSERT INTO people VALUES (29, 'Nat', 1973)");
$dbh->do("INSERT INTO people VALUES (30, 'William', 1999)");
$dbh->do("INSERT INTO father_of VALUES (29, 30)");
$dbh->commit( );
};
if ($@) {
eval { $dbh->rollback( ) };
die "Couldn't roll back transaction" if $@;
}
There's your data in a SQLite non-database. Easy so far.
Here's a subroutine to take a database handle & a data token and use that
token to look for it in the database, formatting it as XML in the process:
sub get_token_from_db {
# Arguments: database handle, person ID number
my ($dbh, $id) = @_;
my $sth = $dbh->prepare('SELECT age FROM people WHERE id = ?')
or die "Couldn't prepare statement: " . $dbh->errstr;
$sth->execute($id)
or die "Couldn't execute statement: " . $sth->errstr;
my ($age) = $sth->fetchrow_array();
return qq[<person id="$id"><age>$age</age></person>];
}
So, if you're looking for the age of person $id, this will return, say:
<person id="42"><age>28</age></person>
Edit as needed. Or do it the right way, and abstract the XML you need out
into a template engine of some kind. Either way, the database isn't really
the hard part here once you get started.
> As computers keep getting faster, and memory and storage cheaper, isn't
> it beneficial to program in the most simple, human readable, least
> learning required, method?
*meh*
There's something to be said for keeping things in a format that's easy to
access, but computers aren't yet so advanced that software efficiency
doesn't matter any more. An efficient to store and manage format with a
clean access layer probably makes at least as much sense as a plain ASCII,
Unicode, XML, etc format that doesn't come with the management tools.
> In short, I'm lazy. I'd rather code this all in perl. Do I really need
> to learn about and use MySQL or will computers get fast enough that it
> won't matter anyway.
No, you don't need to, but honestly, IMO the plan your considering is
workable but unlikely to be as easy in the long run if you just go with
some kind of database approach now.
Databases have become pretty well entrenched in the past 30 years or so;
XML has been a big buzzword for about 5.
I don't think databases are going to go away any time soon;
I'm not yet convinced that XML isn't a flash in the pan.
--
Chris Devers
