[archibaldJ]

> Getting the schema/normalization correct is foundational to long term success.

Great points; I think things get werider when we try to blur the line between schema and type (conceptually)

I wonder what it would look like to have a nice single abstraction that enjoys the practicality (BL-wise) of schema and the pragmatism (programming-wise) of types

Or maybe we can demonstrate that such isomorphism can't exist?

[bob1029]

> I wonder what it would look like to have a nice single abstraction that enjoys the practicality (BL-wise) of schema and the pragmatism (programming-wise) of types

This already exists in my view. With enough discipline, you can accurately encode any type system into the relational model itself. Something to settle up front is the notion of basic types vs domain types. Basic types are required anywhere and you just need to target the simplest subset that is guaranteed to work everywhere - string, int, guid, date, bool, etc.

Domain types are the most important part of solving complex problems. If it would help, this is an example of one of my schemas. Each line item below is a table:

  /* Basic supporting types */
  String (yes, all strings in the domain live in 1 table/column)
  Date (same for date[time]s)
  /* Everything below this line is a pure domain type */
  Customer 
  Customer_CellPhone 
  Customer_Name
  CellPhone_PhoneNumber
  CellPhone_WirelessCarrier
  WirelessCarrier
  WirelessCarrier_Name
  PhoneNumber
  PhoneNumber_String
  PhoneNumber_LastModified
  LastModified
  LastModified_Date
  LastModified_User
  User
  User_Name
  Name
  Name_First
  Name_First_String
  Name_First_LastModified
  Name_Middle_String
  Name_Middle_LastModified
  Name_Last_String
  Name_Last_LastModified
  Name_Business_String
  Name_Business_LastModified
  

The above encodes a fairly detailed view of the domain in my opinion. If you look carefully, you will see that Null is not possible here and that complex data types are strictly enforced.

[codeismath]

I do this too in some apps. Very near exactly how you show it.

How do you enforce required fields in the data model? By eliminating the possibility of null values, you eliminate the possibility of not-null constraints in the data model. I end up having to enforce these types of (non-complex) constraints outside the relational model. A missing row is not detectable in the same way as a null column value.

[archibaldJ]

This is really interesting; if we hook this up with hasura we can still get some nice graphql endpoints