Here's a typical problem that results from "SQL Hegemony" -- all data must be in a database, and all access must be via SQL. This can also be called the "SQL Fetish" school of programming.

War Story. On a Data Warehousing project, we had to load and process the organizational hierarchy …

Imagine that you're a beer distributor who provides "just-in-time" beer by type. You don't take orders for a specific brand, you take orders a type: stout, lager, India pale ale, etc. You resolve the bill based on what you actually delivered.

This can be kind of complex. However, there's no …

As a hypothetical, I was asked about doing Oracle Analytic functions in Python.

[Sidebar: Politics. The question came from a DBA in a C# shop. That's why it's just hypothetical. Politically, they could never make use of this information. In C# world, Functional Programming is often scary and evil. It …

Check out this blog post: http://cacm.acm.org/browse-by-subject/data-storage-and-retrieval/32212-the-end-of-a-dbms-era-might-be-upon-us/fulltext

The first issue is that the RDBMS code base in ancient. The second issue is that we keep pushing the envelope on the RDBMS model; examples include OLAP and RDF triple-stores.

Some folks want to say "reports …

Check out this list of questions from Stack Overflow: [Django] join.

These are all folks trying to do joins or outer joins even though they have objects fetched through the ORM.

How does this confusion arise? Easy. Folks work with SQL as if the relational world-view is Important and Universal …

The users want to locate people by last name. They want flexible matching. That's not very hard.

The DBA wants to do some wild-card searches efficiently. The DBA may not be responding to the users actual request, making this more complex than it needs to be.

I'm not in contact …

This is -- partially -- about the object-relational impedance mismatch.

But it's also about the parallel concepts between objects and relations. We'll use Python as our object model.

First, the obvious.

A SQL table is a list of rows. A row is a dictionary that maps a column name to a column …

First, let me point out that the Data Cartel ("DBA" means Don't Bother Asking) won't release all the information I requested, so some of this is a guess.

We'll look at a number of dumb-as-a-post SQL techniques. This is proof -- if any were needed -- that bad SQL is worse than …

A stored procedure isn't really very easy to understand. There's a profound fascination with triggers and stored procedures, and they're both really bad ideas. I can't say enough bad things about stored procedures. See PL/SQL vs. Java - Which is REALLY faster? and Over-Solving the Problem or When your architect …