|
While reading the thread on SQL and aggregates I had a thought about SQL - well really about the underlying optimiser and the SQL engine. The 'theoretical' SQL question is as follows; Can one assume 100% that the optimiser/SQL engine will 'break' from processing when performing a SELECT * FROM CUSTOMERS WHERE ID = '123456' after hitting the record with the matching ID when ID is defined as a unique key field? I'm in the camp that the software is 'smart enough' (or was written smart enough) to realise that once that value is found, and since the key is unique there shouldn't/won't be any other records to find that will match the WHERE clause, that the processing of the query will terminate right there and then and return the found record with no further record searches. Is this how everyone else would expect the processing to occur? Also, would it also be expected that the search algorithm (with or without the use of indices or access paths) would also be smart enough in this instance (selecting on a unique key) that it wouldn't be a traversal search but something faster e.g. a binary tree/chop search? That's my SQL musings for a while :o) --phil
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.