Comment

Comment by 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.
parent bob1029 5 years ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton