All the Perl that's Practical to Extract and Report
use Perl Log In
gnat (29)
(email not shown publicly)
More on the changing face of databases
Cookbook 1ed definitely had the mindset that you only use SQL databases for high-end high-complexity applications. But these days, if you have data then you probably have an RDBMS somewhere. It used to be that most people didn't know SQL, but these days it's almost a given. Now that SQL knowledge is ubiquitous, everyone wants their favourite data source to be SQL-queryable. And it ends up being easier to just throw data at an RDBMS than design your own DBM/MLDBM/flatfile/etc homegrown storage tricks.
So for a lot of the applications where MySQL is replacing a homebrewed pile of DBM and flat files, of course you don't need stored procedures and triggers and whatever other buzzword they're chasing today. That's the "MySQL rocks" point of view. The other side, "MySQL sucks", is where you have a large complex database with lots of activity--if you don't have stored procedures, triggers, and transactions, you'll find yourself losing data or having to reimplement their functionality in the client. And that almost always ends up being a lot of work with a painfully kludgy feel to it.
More philosophical thoughts on DBI and databases after I have some sleep
--Nat
--Larry Wall in stab.c from the perl source code
Transactions (Score:2)
In my experience MySQL only comes short when you have Oracle DBAs designing your database schema.
(okay, so that's slightly simplified).
- ask
-- ask bjoern hansen [askbjoernhansen.com], !try; do();
Oracle platform (Score:1)
He renamed it Orapig because it thrashed its way through massive swapping, even on the high-end system that had TWO memory boards (1 Meg each - for comparison, PC's of the day were still fighting to get past 1 Meg design limit).
Our tech support person went out to a number of sales calls at the time and returned with a tidbit of information (obviously dated):
Q: "What platform runs Oracle