>I've been working in a shop that only allowed procedure/function/package >interfaces to the database. That's all and very well and good if time and >budgets are not issues. I have yet to see a web development >environment who's >development wizards do not work better with a table/view than a >function/procedure interface to the underlying data. Who or what are these "wizards" you refer to? Would you agree that even if a tool makes a programmer 100x more productive, if the code generated puts a 100x load on the database, it is not productive to run it? >I would submit that a nice compromise is to use views with instead of >triggers. That can provide the best of both worlds -- access to development >environment productivity tools like code wizards while >maintaining a pseudo >procedure/function interface to the application. Please provide an example of how your suggestion is better for "both worlds". It almost sounds like you're intending to placate those who seek efficient SQL with tricks so that your tools and methods can still prevail. Can you identify at least one "code wizard" you've used to produce efficient SQL in rapid fashion? It's not that the SQL doesn't look good, or doesn't provide the proper results that we're discussing, it's that it is not scaleable in the long run, and perhaps not the short run, either. And no one wants that. -- //www.freelists.org/webpage/oracle-l