3 ms·

There's no real reason you can't have sum types in a relational database, this just goes back to our current crop of RDBMSs being quite old and predating the cu

There's no real reason you can't have sum types in a relational database, this just goes back to our current crop of RDBMSs being quite old and predating the current emphasis on strong typing. I suspect a modern relational database with an easier way define complex types (not writing a plugin) would be very popular, but the amount of work required to make something like that is immense

throwaway894345 6y ago
That matches my intuition. The more surprising thing is that this doesn't seem to be talked about very much. I've literally never heard anyone else advocate for a relational database with support for sum types (I'm sure they exist) which has caused a lot of introspection about whether or not there's something about RDBMSs that I just don't understand.
- gfody 6y ago
  it came and went, postgres and sql server were (and still are) referred to as "object-relational" because of their support for rich user-defined complex types. it's just not that practical real-world because we tend to start with first normal form which complex types violate naturally. > whether or not there's something about RDBMSs that I just don't understand perhaps if you consider the entire result of some query to imply the type of the thing being modeled rather than any given table or cell, then it's more obvious that the basic types supported aren't much of a limitation? afterall you can always include a "type" indicator (or project one from a more sophisticated relational model).
  - throwaway894345 6y ago
    Normal form supports complex product types just fine. A row is an object and a row containing a reference to a row in another table is equivalent to an object containing another object, and of course a result set is a list. But I’m not talking about product types, complex or otherwise. I’m talking about sum types (also known as Algebraic Data Types).
    - gfody 6y ago
      > A row is an object and a row containing a reference to a row in another table is equivalent to an object containing another object if you're already thinking of it that way then it's a small jump to the result set as a set, that can participate in a union - and there's your sum type. add or project a type indicator and it's literally a tagged union.
      - throwaway894345 6y ago
        That's not type safe.
        gfody 6y ago
        honestly I don't see how it's not - do you want to be able to union an int with a float or something? there's sql_variant or you can make your own type but that's pretty gross, violates 1NF, and is the opposite of type-safety IMO
        throwaway894345 6y ago
        Tagged unions as you describe are dynamic types. With a fair amount of effort, a SQL query can perhaps use the tag column to make sense of the other columns in the union at runtime, but the type system doesn't have access to that information. You can get part of the way there with constraints, but it's tedious and incomplete.

throwaway894345 6y ago

That matches my intuition. The more surprising thing is that this doesn't seem to be talked about very much. I've literally never heard anyone else advocate for a relational database with support for sum types (I'm sure they exist) which has caused a lot of introspection about whether or not there's something about RDBMSs that I just don't understand.

gfody 6y ago
it came and went, postgres and sql server were (and still are) referred to as "object-relational" because of their support for rich user-defined complex types. it's just not that practical real-world because we tend to start with first normal form which complex types violate naturally. > whether or not there's something about RDBMSs that I just don't understand perhaps if you consider the entire result of some query to imply the type of the thing being modeled rather than any given table or cell, then it's more obvious that the basic types supported aren't much of a limitation? afterall you can always include a "type" indicator (or project one from a more sophisticated relational model).
- throwaway894345 6y ago
  Normal form supports complex product types just fine. A row is an object and a row containing a reference to a row in another table is equivalent to an object containing another object, and of course a result set is a list. But I’m not talking about product types, complex or otherwise. I’m talking about sum types (also known as Algebraic Data Types).
  - gfody 6y ago
    > A row is an object and a row containing a reference to a row in another table is equivalent to an object containing another object if you're already thinking of it that way then it's a small jump to the result set as a set, that can participate in a union - and there's your sum type. add or project a type indicator and it's literally a tagged union.
    - throwaway894345 6y ago
      That's not type safe.
      - gfody 6y ago
        honestly I don't see how it's not - do you want to be able to union an int with a float or something? there's sql_variant or you can make your own type but that's pretty gross, violates 1NF, and is the opposite of type-safety IMO
        throwaway894345 6y ago
        Tagged unions as you describe are dynamic types. With a fair amount of effort, a SQL query can perhaps use the tag column to make sense of the other columns in the union at runtime, but the type system doesn't have access to that information. You can get part of the way there with constraints, but it's tedious and incomplete.