|
> From: rob@xxxxxxxxx > > I think your last paragraph delves more into the detail you are striving > with your website. > In this case he accessed several files with one sql statement. Now, is > that still slower than the three chains in your example? > Whether or not it is less visibly consistent, or more complex, is in the > eyes of the beholder. I thought his was quite clear. Even if you want to imply that embedded SQL is as visually consistent as native I/O (and boy, you have to stretch to try to sell that), or that it is less complex (again, a stretch, especially since he left out the declare and the fetch), there's still less efficient, requires more syntactical knowledge and takes longer to compile. What's the benefit? This sort of SQL, especially, where you attempt to replicate good, efficient native I/O with SQL for no good reason is the kind of thing that gives SQL a bad name. Stick to what it's good for, and you're far more likely to convince someone of SQL's merits. This thread makes it crystal clear that the only way SQL can even come close to native I/O for certain things is basically to try to emulate it, something which SQL does quite poorly. You want the eye of the beholder? Personally, I'd probably fire anyone who tried to put the code Charles wrote into production. That's exactly the sort of code that drove SSA bankrupt. Joe
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.