3 ms·
I find Big-O is mostly applicable to SQL queries. A hard drive/memory bottleneck exists in all database queries. Programmers will easily ignore bad SQL and chal
by ambiate 13y ago
I find Big-O is mostly applicable to SQL queries. A hard drive/memory bottleneck exists in all database queries. Programmers will easily ignore bad SQL and chalk it up to 'database bottleneck etc'. The truth usually goes along the lines of 'I do not understand temporary tables or views. I just SELECT. I opened a 30,000 row cursor, then, a 1,000,000 row cursor, and finally another 500,000 row cursor and got the data (while storing all of the fetches in leaking arrays)!' Usually on keys without indices or tables without primary keys.
SELECT a, b, c FROM abc (30,000 rows)
BEGIN
SELECT e, d, f FROM edf WHERE e = a (30k * 1m)
BEGIN
SELECT x, y, z FROM xyz WHERE d = x (30k*1m*500k scanned)
BEGIN
process()
END
END
END
A customer or manager can all find respect in lowering the growth rate of a query. No mathematics required. Simply, "Your report now runs in 30 seconds instead of 20 minutes." Anyone can compute that!
The mathematics of Big-O gets annoying for average case scenarios. Instances of
def fun(abc):
l=[]
for x in abc:
if x%2==0:
for y in abc:
l.append(y)
return l