This is just a bad idea. Better idea: unless you are rewriting your entire schema from scratch, you should be able to use database views, database triggers, extra/duplicated columns and tables as you make schema swaps.
Even with tools like Liquibase, the more functionality you put in the database (views, stored procedures, triggers, etc.) the harder it is to do deployments and rollbacks and keep the code and the database functionality in sync.
Temporary development functionality, not permanent (I said "as you make schema swaps").
> keep the code and the database functionality in sync.
At any time there should only be a fixed number of versions of the code (ideally two: Production and Stage; and maybe a half, Development, if things go really sour). Hence the overhead for supporting that fixed number of versions should then be relatively constant. When a system is done and moved to maintenance mode you remove all of your temporary functionality and get the database back to it's optimal form for the current code.
Obviously it gets tricky when you are doing multiple products on the same database, or a very large database. But I don't see how a DAL delivers anything to those that just having clean well documented code and using existing database features doesn't.
Stable App w/ old schema -> add functionality to support new schema -> add new code w/ new schema -> add functionality to support old schema, migrate to new schema -> remove old app w/ old schema -> remove now vestigial functionality supporting old schema. Supports multiple versions of the code and supports rolling updates. If it's hard to keep track of that I don't know how to help you.
Like all things, it depends. Certain features/abstractions have more value at different stages of an application.
I LOVE using views early on in a new application's schema as it allows me to evolve the logical model separately from the physical model, and once I've coalesced on something I like it's easy enough to swap the view with a real table and my application code higher in the stack is none the wiser.
Even Facebook at one point relied on MySQL triggers to keep its memcache fleet synced.
Views aren’t quite as bad as stored procedures. I could see doing a view being decently easy to manage - you can always add s column without breaking backwards compatibility. But you can’t imaging the number of times I’ve seen things like...
Even with tools like Liquibase, the more functionality you put in the database (views, stored procedures, triggers, etc.) the harder it is to do deployments and rollbacks and keep the code and the database functionality in sync.