Welcome to WebmasterWorld Guest from 188.8.131.52
I have an app with many tables and a class that handles the basic (add,edit,delete,update) functionality required to interact with each table. - Several different, very simple classes, one class per table.
Say a page has 50 'entries' - each requiring some data from each table.
Is it best to keep the classes as they are: Light and simple, keeping the 'baggage' the app carries from page to page light.
Or, extend the classes to carry much more sophisticated functionality.
The first means many, many calls to the DB for one page with 50 entries. But, much less 'baggage' being carried from page to page throughout the site. (size of require()'d classes/scripts)
The second, more baggage but more complicated calls to the DB meaning much less calls to the DB per page and more efficient queries.
Which is the lesser of the 2 evils and why?
I'd go with the second but, what about the huge amount of code being carried from page to page?
Look forward to your thoughts...
Avoid code bloat but know that doing what´s necessary to be done in PHP [php.net] is not code bloat. If "compile" time of your scripts is really an issue I´d use the Zend Optimizer to have it "precompiled". If speed is of utmost importance you should stay away from very high level languages like PHP [php.net] and Perl [perl.com] anyway and use C.
Having said that I´d go with the implementation of a class that has all the functionality that the class should provide from a locigal POV. If you already use a very high level language keep you classes at that very high and abstract level as well.
Is there a way to tweak memory usage for it or is that dealt with inside the code? I bumped my localhost PHP up to 96Mb and I never see mySQL go above 4Mb
cheers andreas ;)
[edited by: brotherhood_of_LAN at 1:19 pm (utc) on Mar. 21, 2003]
Now that is such a question that you will not find a single lawyer that would answer with a simple yes or no.
So let me answer in a way a lawyer would: Generally yes. You do realize though that more complex and 10's of calls allow for a wide variety of situations. If the classes look complete/provide the needed functionality only in a more complex way than that´s the way I´d go.
It's just blog stuff Andreas.
member table, blog table, articles table etc.
The 'many calls' comes from getting the member names, blog entries, links to member bios all from seperate tables (maybe 10posts per page).
Just wanted some thoughts, so thanks again ;)
Maybe it would be good to write anoher class specifically for getting blog pages? - then use the more simple classes for member input, validation, logg ins etc...
A separate Authentication class would be a good idea as well.
Yes, contained in the member class at the moment along with edit/add/delete/update
The blog stuff, as well as the articles stuff will each have seperate classes that can be used along-side the member class...