Fran, I think the key here is taking care of the 80% easily. This has been mentioned in this thread several times, and in previous threads. No, I don't think there will ever be an (efficient) wrapper that can handle ALL the cases and ALL the possible SQL queries. But if you can handle the majority of them easily with a wrapper, and that wrapper also provides a way to get at the SQL directly (I heard SPOPS as being good for this), then that is a lot of work saved. Work saved = money & time saved = you look better to your boss.
Both approaches have merit, so the trick is to determine which one is best for your situation. At my day job, the tables are relatively denormalized, ie. very wide, so a wrapper can easily work. At a previous job I was working to encapsulate all the SQL calls into a single module. The ability to find the approach that works best for you is the difference between a grunt and a good software engineer. :-) Drew At 01:30 AM 6/14/02 -0400, Fran Fabrizio wrote: >I don't typically find apps that just mirror some subset of one of the db >tables to be all that interesting. After all, it's the relationships >between the data that make the data interesting, and by necessity this >means your queries will be complex. And looking over the stuff outlined >at poop.sourceforge.net, there's not too many models/frameworks out there >that can accurately abstract ALL of SQL, and if it only does a subset, I >feel like that's shooting myself in the foot. ====================================================================== Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com ---------------------------------------------------------------------- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ======================================================================
