3 ms·

> 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

> 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 5y ago
> 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 5y ago
  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 5y ago
  This is really interesting; if we hook this up with hasura we can still get some nice graphql endpoints

bob1029 5y ago

> 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 5y ago
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 5y ago
This is really interesting; if we hook this up with hasura we can still get some nice graphql endpoints