[valenterry]

First of all, your example constraint is not possible to be statically expressed in SQL anyways. In the typesystem, that is.

Sure, you can create a constraint for `'at least one of these two fields must be empty, but both can't be empty'` but that will only be applied at runtime. It's not like any dmbs (to my knowledge) will reject the query at parse-time. Or else, please show me an example of how you would do that. (and don't use constraints or indexes, because those only work at runtime)

Second, I deliberately said "good programming languages" and you changed that to "mainstream programming language". You know what? If all your mainstream programming languages (however you count or define those) don't support that stuff, maybe it's time to move on and choose a better language.

In Scala at least, it's trivially possible to define such a constraint with types. That ensures that you will never by accident violate that constraint. And that is guaranteed at compile time, so no one is gonna wake you up in the night because your query failed due to that condition you specified.

If you don't believe me, I'm happy to show you the code to encode that logic.

[lelanthran]

> First of all, your example constraint is not possible to be statically expressed in SQL anyways. In the typesystem, that is.

So? The DB will prevent you from violating the constraints, because it cannot tell in advance (i.e. before getting the query with the data in it) whether the data violates the constraint.

> It's not like any dmbs (to my knowledge) will reject the query at parse-time.

What parse-time?

     echo "INSERT INTO tbl_test (c_one, c_two) VALUES (3, 4);

Where's the parse-time in that?

TBH, I am still failing to see your point - this looks like an artificial restriction (the query must be rejected before you present it to the DB).

Whether you call it runtime or compile-time or parse-time, the DB will not let you violate the type safety by accident.

The point is that the DB will enforce the constraints.

> Second, I deliberately said "good programming languages" and you changed that to "mainstream programming language".

Well, if your bar for "good programming languages" rules out all the mainstream languages, what's the point of even discussing your point? The point you are making then becomes irrelevant.

> If all your mainstream programming languages (however you count or define those) don't support that stuff, maybe it's time to move on and choose a better language.

For better or worse, the world has rejected those better languages and relegated them to niche uses. Shrieking shrilly about your favourite languages aren't gonna make them more popular.

You know what's more realistic? Teaching the users of the "poorer" languages that they can get all those benefits of type enforcement in their DB without needing to switch languages.

> In Scala at least, it's trivially possible to define such a constraint with types.

In more than a few languages it's possible to do that. I'm thinking more Prolog, and specific SAT solvers than Scala, though. There's benefits in doing so.

However, the minute you plug an RDBMS into your system, many benefits can be gained without switching languages at all. Like real constraints for XOR or composite uniqueness, referential integrity, NULL-prevention, default values, etc.

[valenterry]

> What parse-time? (...) TBH, I am still failing to see your point

What I tried to say was: in some programming languages, this insert will not even compile. So you don't have to write a test, you don't have to spin up a test database or anything, it just doesn't compile. And I prefer that over having to wait until a query is actually sent before I get an error.

This is relevant for me because 1.) it makes me more productive since I get the error much quicker and I don't have to write a test and 2.) it prevents getting calls in the night because something broke.

I hope that makes it clear.

> However, the minute you plug an RDBMS into your system, many benefits can be gained without switching languages at all.

Yeah, but that doesn't invalidate my original point, does it?

[lelanthran]

I don't really have time to discuss this in depth, but note that:

1) I still disagree somewhat on the finer points,

and

2) I've upvoted your post anyway because other than the finer points on which I disagree, you make good points anyway.

Cheers :-)