|
> You imply that somehow reorganizing > your database will make SQL perform > as well as native I/O. > I'd love an example of where a different > database design will either: > > A. Make a single record FETCH as fast as a CHAIN > -or- > B. Remove the need for single-record access Hi Joe! I read/post via nntp, so I don't see these things as they happen. I apologise for the delay. First, I'd like to apologise if I mislead you into thinking that I meant a simple change to the layout would make SQL work faster. What I meant to say was that a completely different approach altogether is required. I'm as unit-record oriented as anybody, so I may not be the best person to come up with a good example of an alternative architecture. Second, I'd like to agree that there will always be a place for record-at-a-time I/O, especially data collection like order entry. A new architecture can limit that need, but not eliminate it. The more I thought about it, the more I tried to write about it, I became convinced that it is nigh impossible for me to adequately put my thoughts in a form that is concise and meaningful. Given that, I concede that I cannot fulfil either of your challenges. --buck
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.