> As for SQL, I just wish people would expand their horizons a little and
> start doing a bit of reading. There are so many different ways to avoid
> embedding SQL in application code and I sincerely wish programmers would
> THINK before just coding... it's what differentiates scripters from
> engineers and I suggest everyone who embeds SQL in their perl for anything
> other than quick-and-dirty hacks start considering other options for the
> good of the programming community AND THE SANITY OF WHOMEVER HAS TO
MAINTAIN
> OR ALTER YOUR CODE.
>
> If you wish to see one enlightened approach, please read this:
>
>
http://developer.apple.com/techpubs/webobjects/DiscoveringWO/EOFArchitecture
> /index.html
I appreciate your kind words about my templating posts, but I don't agree
that an object-relational mapper is always the right answer for database
integration. Using objects to model your data, and having the objects
manage their own persistence through SQL calls is faster and easier for many
things, and it allows you to do things that can't be done with an O/R
mapper, like advanced SQL tuning (optimizer hints), aggregation of commonly
fetched data into one query, etc. You still get encapsulation of the SQL
behind the object interface, and your high-level logic doesn't need to use
any SQL directly.
It would really be nice if someone could write an overview of the O/R
mapping tools for Perl. I know Dave Rolsky was working on one, but it's a
big job and he's busy with Mason.
- Perrin
