No, see, that's what I was questioning. Why is using NULLs easier, such that it's the "lazy" thing you can "succumb" to? UI is fundamentally about incentives--making good things easy to do, and bad things hard--and an API, or a protocol, is a UI for programmers.
Sure, instead of a NULLable column, you can have a pair of columns, one with an ENUM type to represent the sum-typeclass's type-instance, and the other to represent a value of that type. But that sounds like you're working at the wrong level of abstraction, fundamentally.
You're using an RBDMS because it lets you speak in terms of tuples, relations, projections, and other Relational Algebra concepts, rather than in terms of keys, values, and indexes. I can see doing the pair-of-columns thing in a NoSQL store--but why did the designers of SQL let this implementation detail infect my RDBMS?
It's kind of funny, actually. I see developers treating their RDBMS as a dumb object store... but then implementing a "domain model" layer right beyond it, basically creating a "model server" accessible over an API, which enforces the business domain constraints on the objects it sends and receives. In other words, they've Greenspunned an RDBMS of their own in all but name, with its own custom protocol and half-assed validation logic. I feel like a large reason for this is that current RDBMSes just aren't up to representing the types and constraints and relations that developers need to express, so they put up their noses and say "business logic doesn't belong in the database!" ...and proceed to build a database for their business logic to reside in.
It's times like this when I almost get an urge to develop my own RDBMS that actually keeps the Relational-Algebra abstraction clean. No concept of a "table" or a "view" or an "index"; just relations between projections of an infinite theoretical tuplespace, where tables are created to store data that can't be inferred from an existing view, and garbage-collected behind the scenes when their values are no longer referenced by any projection. Indexes created gradually when a tracing-JIT-like query planner notices repeated access patterns. Strong, structural, parametric type declarations on every piece of data. Constraints that actually allow you to express things like "a user-to-user 'friend' relationship must be symmetric", rather than just being a weak declarative dress over triggers. Etc.
You don't need a pair of columns to replace a nullable column. I was addressing the second part of your comment not your questioning of allowing nulls.
Nulls have their place I believe, but they are grossly overused. For example, if you have a Person table, then something like a nullable DateDied is logical and acceptable over a sub-type solution. But something like HairColor should not be nullable to cater for bald people, it should non-nullable and reference a table that has a 'none' value.
On another note, I don't think you can eliminate the null concept because they are the implicit outcome of outer joins and therefore means of comparing and aggregating nulls needs to built in.
> if you have a Person table, then something like a nullable DateDied is logical and acceptable over a sub-type solution.
But this is exactly where NULLs are bad. "DateDied IS NULL" could mean many different things, semantically:
- This person hasn't died
- We don't know if this person has died (the information was not provided with the record when imported)
- DateDied is not an applicable property for this subtype of Person (for example, if you have an ImmortalPerson subtype.)
There are probably even more, if I wasn't just going off the top of my head. When you do an outer join, you get another level of NULLability--which would perfectly map to another layer of "Nothing | Just something"--but without that, you get those NULLs mixed in with the other three types of NULLs above. And then you insert all those into a table, export it, and import it somewhere else... and nobody knows what any of the NULLs mean.
No, see, that's what I was questioning. Why is using NULLs easier, such that it's the "lazy" thing you can "succumb" to? UI is fundamentally about incentives--making good things easy to do, and bad things hard--and an API, or a protocol, is a UI for programmers.
Sure, instead of a NULLable column, you can have a pair of columns, one with an ENUM type to represent the sum-typeclass's type-instance, and the other to represent a value of that type. But that sounds like you're working at the wrong level of abstraction, fundamentally.
You're using an RBDMS because it lets you speak in terms of tuples, relations, projections, and other Relational Algebra concepts, rather than in terms of keys, values, and indexes. I can see doing the pair-of-columns thing in a NoSQL store--but why did the designers of SQL let this implementation detail infect my RDBMS?
It's kind of funny, actually. I see developers treating their RDBMS as a dumb object store... but then implementing a "domain model" layer right beyond it, basically creating a "model server" accessible over an API, which enforces the business domain constraints on the objects it sends and receives. In other words, they've Greenspunned an RDBMS of their own in all but name, with its own custom protocol and half-assed validation logic. I feel like a large reason for this is that current RDBMSes just aren't up to representing the types and constraints and relations that developers need to express, so they put up their noses and say "business logic doesn't belong in the database!" ...and proceed to build a database for their business logic to reside in.
It's times like this when I almost get an urge to develop my own RDBMS that actually keeps the Relational-Algebra abstraction clean. No concept of a "table" or a "view" or an "index"; just relations between projections of an infinite theoretical tuplespace, where tables are created to store data that can't be inferred from an existing view, and garbage-collected behind the scenes when their values are no longer referenced by any projection. Indexes created gradually when a tracing-JIT-like query planner notices repeated access patterns. Strong, structural, parametric type declarations on every piece of data. Constraints that actually allow you to express things like "a user-to-user 'friend' relationship must be symmetric", rather than just being a weak declarative dress over triggers. Etc.
Would anyone be interested in such a beast?