For reference: Ferry.
(Source: shinolajla)
Stored programs should be checked for consistency with existing table definitions at the time of CREATE; alteration of the schema should re-check the consistency of stored programs. Getting run-time errors for what should be checked at ‘compile time’ is balderdash.
I’m building a database in which nothing is ever deleted. I have the tables in the DB segregated into two types: Platonic and not. The Platonic forms maintain all data for the non-Platonic forms which persists over time. For example, I have, say, a:
PlatonicCompany(id:Int, name:String)
and a
Company(id:Int, pcFK:Int, createdOn:Timestamp, deletedOn:Timestamp)
where pcFK is a foreign key back to the PlatonicCompany. This naming scheme is not sufficient. Consider the following tables:
PlatonicConversation(id:Int, cFK:Int, who:String, why:String, where:String) Conversation(id:Int, pcFK:Int, createdOn:Timestamp, deletedOn:Timestamp)
where “cFK” is a foreign key to the Company. Now, PlatonicConversation is not strictly a Platonic form: it depends in on the finite nature of Company. It is an eternal entity, but only within a context; we might call a god that lives forever “immortal” but it will eventually meet destruction if it is:
I believe the correct word to describe these indirectly time dependent entities is “coeternal”, but that does not quite fit. Jesus Christ is said to be coeternal with God the Father, but I know of no Christian that would assert the Trinity ends its existence when (if?) the Universe collapses back in on itself.
Call me old fashioned, but if you are using an ORM it should have the decency to not require you to manually define the schema and the mapping while you are developing the schema. Later or with a existing database, sure.