|
|
|
|
|
|
by bob1029
1741 days 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. |
|
|
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.