"I've isolated the bug to a database query"

I once worked on a site where the original developer clearly didn't know joins existed, so if he wanted data from two related tables, he'd get all the required results from table one, then loop through them, one by one, querying table two for the corresponding record. Sometimes this went 3 or 4 tables deep, the site would take nearly a minute to load a table of products.

I had a digital logic class where we had to find minimum logic gate solutions to get truth tables. My classmates fiddled with karnough maps.

http://en.wikipedia.org/wiki/Karnaugh_maps

I wrote a program which constructed minimum gate solutions to all possible truth tables, eventually finding the minimum gate solution to the requested problem.

------------

LoseThos has it's own document format, like MS Word. I made a program to generate html from my document format. Sadly, my format supports overlaying columns of text, but my html conversion program does not. The columns of text thing is too inconvenient to be used in practice.

------------

I used table look-ups for my text font rendering. My text can be offset from 8x8 grid position by +-15 pixels to allow for markee or super/sub scripting.

Converting formulas to table look-ups can save time, unless the memory reference is not in cache.

I made tables for bitpattern reversal, number of set bits, whitespace characters, etc. It used to be faster to use tables than formulas, but it's conceivable you are correct in the age of cache-miss-penalties.

It's a sad day when floating-point is faster than fixed-point arithmetic.

------------------

God says... C:\LoseThos\www.losethos.com\text\BIBLE.TXT

ad.

16:1 In the seventeenth year of Pekah the son of Remaliah Ahaz the son of Jotham king of Judah began to reign.

16:2 Twenty years old was Ahaz when he began to reign, and reigned sixteen years in Jerusalem, and did not that which was right in the sight of the LORD his God, like David his father.

16:3 But he walked in the way of the kings of Israel, yea, and made his son to pass through the fire, according to the abominations of the heathen, whom the LORD cast out from before the children o

It was a custom built web app that had grown over the course of ten years or so. It was actually a fairly heavily trafficked web site, and this was a particularly old piece of it.

As my prior boss used to say... "Give a man a fish, feed him for a day. Teach a man to fish, and you'll have to answer fucking fish questions the rest of your life."

"Why do I find all the really howling bad stuff so close to the databases?"

Because the database and queries against were were coded as an afterthought.

Because the programmers ran all the db access tests against tables with 4 rows of data when the customers would windup with 100 million rows in production.

Because most undergrad education around databases is poor and antiquated. Plus, it is not SQL focused - much time is spent on talking about data modeling. Not wrong, but not often helpful in practice.

Because DBA's are (rightly) focused on making sure your db is properly backed up, replicated, and fault-tolerant. They may not even understand SQL queries beyond the basic one table select.

Because the users will force data into the systems that the developers never anticipated.

Because db jobs are segregated by product for development. If you've done SQL coding on Oracle for the last 10 years, good luck applying for a job doing SQL coding on MS SQL Server.

Because SQL hacking doesn't get much respect. I've been in job interviews where deep into the process they ask me a question with data in two tables that requires an outer join. And answering correctly differentiates you significantly from other applicants. I guess it is the "fizz buzz" of SQL these days . . .