How to identify backup tables within production databases that can be removed.
'Temporal' tables contain facts that are valid for a period of time. When they are used for financial information they have to be very well constrained to prevent errors getting in and causing incorrect reporting. This makes them more difficult to maintain. Is it possible to have both the stringent constraints and simple CRUD operations? Well, yes. Dwain Camps patiently explains the whole process.
Temporary tables are used by every DB developer, but they're not likely to be too adventurous with their use, or exploit all their advantages. They can improve your code's performance and maintainability, but can be the source of grief to both developer and DBA if things go wrong and a process grinds away inexorably slowly. We asked Phil Factor for advice, thinking that it would be a simple explanation.
I run this code on SQL Server 2019:
DBCC CLONEDATABASE(imdb, imdb_dev)I then change to the cloned database, imdb_dev, and run some queries. I then run this code while testing:
INSERT dbo.Title (TitleID, Title, DateReleased) VALUES (3234, 'Maestro', '2023') GOWhat happens? See possible answers