The stupid question is the question not asked | |
PerlMonks |
Re: algorithm help for determining efficient db data retrievalby dragonchild (Archbishop) |
on Apr 06, 2004 at 03:00 UTC ( [id://342821]=note: print w/replies, xml ) | Need Help?? |
I'm confused. This seriously sounds like you're having a bad case of premature optimization. Write the code in the easiest way you have to code it. If that means pulling all the properties for a given object from the database, then do it! If that means pulling entire objects from the database one at a time, then do it! Later, if stuff is slow, then optimize it. But, you don't even know that it will be slow, let alone where!
As a second note ... your database design sucks. I haven't seen it, I have no idea what it's for, but I know it sucks rocks. How do I know this? Because you have objects and you want to store them in the database. No No NO! This is a "Bad Plan"(tm). Objects are for using. Databases are for storage with referential integrity. They are completely unrelated things. Sure, you may have an INVOICE table and an Invoice object, and they may look like they're 1-1, but this is the exception, not the rule. Here's the solution you are looking for (and you've probably done most of these steps, but I'm going to state them anyway, just in case):
Let me repeat - your data and your objects are unrelated entities. You fill the latter with stuff from the former. You should not define your data in terms of your objects. That's just asking for trouble. ------
Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose
In Section
Seekers of Perl Wisdom
|
|