Hacker News Reader

Comment by catnaroek | Hacker News Reader

> Which is why the real interpretation happens outside the DBMS.

Unfortunately, computer programs mean what they actually do, not what you wish they did. The field of formal semantics of programming languages exists to study the real meaning of programming languages, not the “intended” one, whatever the latter might be.

> If this is your way of saying that the only thing a DBMS does (and can ever be expected to do) is algebraic computation (e.g. to verify constraint satisfaction of a given update to a given existing db state)

The programmer is expected to make the DBMS enforce business rules. A database schema is a model (in the informal, everyday sense of the word) of the real world to the extent the real world's rules are enforced constraints in the schema. Otherwise, it's just wishful thinking.

View on HN

I thought it was the database designer. But OK, maybe that's just semantics and I'm not very good at those.

The database designer is a programmer, and the DBMS's data definition language is a programming language.

Placing this in its context of things said previously, "The DBMS doesn't read your mind before interpreting relations.", "Which is why the real interpretation happens outside the DBMS.", "Unfortunately, computer programs mean what they actually do", it is entirely irrelevant.

The meaning of what a DDL script does is that it asserts/ensures the (non-)existence of database objects in the database. This has absolutely nothing to do with the intended interpretation that the designer attaches to those of the database objects that are base tables/relations/relvars and derived ones in his design.

> The meaning of what a DDL script does is that it asserts/ensures the (non-)existence of database objects in the database.

The DDL also defines what database objects mean. It's the programmer's job to make sure database objects actually mean what the specification says they should mean. Calling it a “customer” isn't enough: it has to have the same attributes, as well as obey the same constraints, as a customer in your problem domain. If your DBMS can't enforce this, it's not a customer, no matter what you call it.

> This has absolutely nothing to do with the intended interpretation that the designer attaches to those of the database objects that are base tables/relations/relvars and derived ones in his design.

If your DBMS's DDL is sufficiently expressive, you can arrange things so that the behavior of your database objects matches your intended interpretation. (And, if it isn't sufficiently expressive, you should switch DBMSes.) This is the whole point to studying database models.

My DBMS is sufficiently expressive, thank you.

Reply on news.ycombinator.com