[kingdomcome50]

I think your example is a solid illustration as to why you may not want non-developers writing SQL:

    SELECT 
        CASE WHEN o.EmailAddress IS NULL OR o.PhoneNumber IS NULL
            THEN 1
            ELSE 0
        END AS [IsSubmitDisabled]
    FROM Customer c 
    INNER JOIN Order o ON c.Id = o.CustomerId
        AND o.IsActiveOrder = 1
    WHERE c.IsActiveCustomer = 1

These queries aren't identical in their output, though they are logically the same. Is that a good thing? What are the implications of allowing such ad-hoc queries within a system?

[bob1029]

The SQL was only intended for illustrative purposes against a contrived domain model. Actual correctness of the query in whatever hypothetical domain was imagined at that time is not something I would focus too much on.

[kingdomcome50]

My point exactly. "Not focusing too much" on the SQL is a road you likely don't want to go down, and is rather inevitable when you bestow that power unto non-developers! (You were too quick. I made an edit)

[bob1029]

Why does someone need to be a "developer" to be highly-competent at authoring SQL?

[kingdomcome50]

You know that's not the point I'm making.

But even for authors that _are_ highly competent at authoring SQL, it is dubious to allow them to compose ad-hoc queries ad-nauseum (let's even pretend these "developers" are _also_ excellent at performance tuning).

This is death-by-a-thousand-cuts. The approach is just too granular. Databases _notoriously_ don't have unlimited throughput, and depending on your particular RDBMS it may be prohibitively expensive to just "throw more hardware" at the problem (I'm looking at you MS SQL Server).

For any system that you can imagine there is a point (i.e. scale) at which the above paradigm becomes a very big problem. Believe me. We are in the process of moving logic _out_ of SQL for this exact reason at my current company!

[vaughan]

Depends what you mean by developer, but there a heaps of ways to accidentally write code that doesn't use an index, and then you need to understand db internals and how indexing works, and so you are on your way to being a SQL dev. A non-developer I wouldn't expect to understand db internals. You can get quite far though not understanding db internals as a non-dev for simple querying until you write some complex mission-critical query that must continue running, but needs maintenance/starts over-burdening the db/etc.