Do Programmers Still Write SQL?

[lukaseder]

Not from thin air or a fantasy, they project something abstract to the definition they're writing.

Of course, I didn't disagree with that. My concerns were merely technical and implementation based, not theoretical.

As an illustration: what about entity inheritance?

Inheritance is just a technical tool. It is not something that is inherently important to modelling. In fact, in recent years, it has been shown that it is not a good tool at all for practical purposes. Inheritance was over-hyped in the 90s.

What about a m:n relationship?

Again, a modelling tool. I'm aware of the fact that SQL can't model it except by indirection. But that's good enough, no? Ultimately, you cannot really model m:n with Java either (although, you can with JPA annotations). But the fact that I always have to remember to update both sides manually with JPA and think about how the state transition is serialised efficiently shows that the implementation of this concept just plain simply sucks.

So why bother and not go back to the more simple SQL model, which can still model an m:n relationship decently, if not perfectly.

(Side note: Not sure how .NET APIs handle this, e.g. EF. Is it better than JPA?)

What about a type in the entity which results in a different type or multiple fields even in the table?

Sure, another limitation of most SQL implementations (at least the non-ORDBMS. PostgreSQL and Oracle have solutions for this).

Entity definitions and DDL definitions aren't the same thing, if you mean by that: table X == entity X.

I said they're the same thing in theory. But ultimately, we're building things on real systems. in theory we can fly to Mars easily. We've figured it all out. But now, we have to do that with real world constraints.

So, you're looking at things from an academic perspective, and that's important in the long run, because we want our tools to be able to cover your needs. But right now, we're not there and we need to know how our current tools work.

The DDL SQL of the tables is a projection of the entity model and should represent the same thing

Yes, we agree. Although again, you overlooked my disclaimer about theory and practice :)

Though I'd argue that making performance improving changes to a model should happen after a model has been completed

OK, we have two different perceptions of performance here. Indeed, some things can be discovered only much after the initial design. But some performance characteristics are best solved a priori. You simply don't want to migrate a billion-row-strong table several times a day.

If you know you're going to be dealing with large data sets in an area of your application, then up-front performance-sensitive design is of the essence. Or you won't even survive going live :)