On 11/09/2009, at 6:27 AM, Ashley Moran wrote: > Personally, I follow Date on this, and try to avoid NULLs at every > step.
Date wishes we had a relational database system too, instead of SQL. Unfortunately almost every real business model has optional roles, and though those can be modelled without NULLs in a truly relational or attribute-free model, when you map such a pure model to efficient SQL you often wind up with NULLs in your physical model. The same goes for STI. STI is a fairly reasonable way to model inheritance, and it's still possible to enforce non-NULLity for the subclass columns... That's where CHECK constraints come in: CHECK TYPE <> 'Thing' OR (field1 is not null and field2 is not null...) Personally, I use Object Role Modeling (an attribute-free approach), which has no support or need for NULLs. It maps to SQL that does, of course, but it can enforce them correctly. See http://ormfoundation.org or http://www.orm.net - or for that matter, my ActiveFacts project on github or at http://dataconstellation.com/ActiveFacts Clifford Heath, Data Constellation. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
