Re: Maybe database tables aren't such great "objects," after all ...

[cavac]

When working with databases in general, in my mind the first question to ask is "how much data will i be working with".

Depending on the answer, a high level approach may make coding easier and/or it might kill the performance of the application.

Take your example of accounts (i assume money accounts, not the type you use for logging into a system). If you plan for a low number of entries, the high level approach will be benefitial. On the other hand, if you are coding for a bank, loading a gazillion of objects into your perl interpreter to do the daily sum may be.. suboptimal.

When dealing with a high volume of data, let the database do it's job. In all likelyhood, a few hundred developers spent the last decade or two optimizing the heck out of that database. Also, modern databases have optimized server side scripting - no need to send thousands of rows back and forth between database and perl just to check if the account holder still has enough money left to pay his/her electricity bill.

That said, having Perl classes that wrap all this SQL stuff into nice packages can be quite benefiting. But that also depends on how the various data subsystems interact - you may or not be forced to "break the rules" in certain cases to get the required performance. Or... your do some of the abstraction in whatever means you database gives you in terms of views, server side scripting and whatnot.

So, always more than one way to do it there is, Luke. ;-)

[sundialsvc4]

/me nods...

You are definitely correct on all these points.   Thank you.   Many sides to The Force there are, young Skywalker.   He who tries to wedge all of it into one basket, survive will he not, no matter what or how large the basket might be.