How to apply the constraint ONLY to new rows

Question

Hi, Gurus:
   I have one question as follows:
   We need to migrate a legacy system to a new production server. I am required to add two columns to every table in order to record who updates the row most recently through triggers, and  I should apply not null constraint to the columns . However, since legacy system already has data for every table, and old data does not have value for the 2 new columns. If we apply the constraint, all of existing rows will raise exception. I wonder if there is possibility to apply the constraint ONLY to new rows to come in future.
Thanks.
Sam

Answer 1

   We need to migrate a legacy system to a new production server. I am required to add two columns to every table in order to record who updates the row most recently through triggers, and  I should apply not null constraint to the columns .
The best suggestion I can give you is that you make sure management documents the name of the person that came up with that hair-brained requirement so they can be sufficiently punished in the future for the tremendous waste of human and database resources they caused for which they got virtually NOTHING in return.
I have seen many systems over the past 25+years that have added columns such as those: CREATED_DATE, CREATED_BY, MODIFIED_DATE, MODIFIED_BY.
I have yet to see even ONE system where that information is actually useful for any real purpose. Many systems have application/schema users and those users can modify the data. Also, any DBA can modify the data and many of them can connect as the schema owner to do that.
Many tables also get updated by other applications or bulk load processes and those processes use generic connections that can NOT be tied back to any particular system.
The net result is that those columns will be populated by user names that are utterly useless for any auditing purposes.
If a user is allowed to modify a table they are allowed to modify a table. If you want to track that you should implement a proper security strategy using Oracle's AUDIT functionality.
Cluttering up ALL, or even many, of your tables with such columns is a TERRIBLE idea. Worse is adding triggers that server no other purpose but capture useless infomation but, because they are PL/SQL cause performance impacts just aggravates the total impact.
It is certainly appropriate to be concerned about the security and auditability of your important data. But adding columns and triggers such as those proposed is NOT the proper solution to achieve that security.
Before your organization makes such an idiotic decision you should propose that the same steps be taken before adding that functionality that you should take before the addition of ANY MAJOR structural or application changes:
1. document the actual requirement
2. document and justify the business reasons for that requirement
3. perform testing that shows the impact of that requirement on the production system
4. determine the resource cost (people, storage, etc) of implementing that requirement
5. demonstrate how that information will actually be used EFFECTIVELY for some business purpose
As regards items #1 and #2 above the requirement should be stated in terms of the PROBLEM to be solved, not some preconceived notion of the solution that should be used.
Your org should also talk to other orgs or other depts in your same org that have used your proposed solution and find out how useful it has been for them. If you do this research you will likely find that it hasn't met their needs at all.
And in your own org there are likely some applications with tables that already have such columns. Has anyone there EVER used those columns and found them invaluable for identifying and resolving any actual problem?
If you can't use them and their data for some important process why add them to begin with?
IMHO it is a total waste of time and resources to add such columns to ALL of your tables. Any such approach to auditing or security should, at most, be limited to those tables with key data that needs to be protected and only then when you cannot implement the proper 'best practices' auditing.
A migration is difficult enough without adding useless additional requirements like those. You have FAR more important things you can do with the resources you have available:
1. Capture ALL DDL for the existing system into a version control system
2. Train your developers on using the version control system
3. Determining the proper configuration of the new server and system. It is almost a CERTAINTY that settings will get changed and performance will suffer even though you don't think you have changed anything at all.
4. Validating that the data has been migrated successfully. That can involve extensive querying and comparison to make sure data has not been altered during the migration. The process of validating a SINGLE TABLE is more difficult if the table structures are not the same. And they won't be if you add two columns to every table; every single query you do will have to specify the columns by name in order to EXCLUDE your two new columns.
5. Validating the performance of the app on the new system. There WILL BE problems where things don't work like they used to. You need to find those problems and fix them
6. Capturing the proper statistics after the data has been migrated and all of the indexes have been rebuilt.
7. Capturing the new execution plans to use a a baseline for when things go wrong in the future.
If it is worth doing it is worth doing right.