Right, I missed “remaining semantically consistent in the type signatures”. Assuming you mean correspondence between the DDL schema definition and the PL type signature, I see no need to do so, as long as both can be generated from the same definition, or one from the other. That is, the scenario were dependent types are used on the PL side and constraint checks on the database side seems perfectly fine to me (given the limitations of SQL). I’m assuming that you meant value checks on the PL side if you didn’t mean checks on the DB side.
By "type definition" I did actually mean the database schema. I don't particularly care what happens at the boundaries, and I think translating a database schema into suitable types at the programming language level makes sense (e.g. dependent types). I was just describing how it would make most sense in my mind to design the database schema in isolation with other concerns in order to remain most semantically correct.