|
Archives of the TeradataForumMessage Posted: Thu, 01 May 2003 @ 14:56:27 GMT
Anomy, I can think of 2 ways in which Surrogate IDs can be utilizied: 1) Simply to save space by storing fat, character-based natural keys as integers (with some sort of look-up taking place at run-time) - Many people (particularly within the Teradata community) take offense to this. From my point of view, assuming you don't control the purse strings to your company's hardware budget (more hardware almost always being the cleaner, easier solution assuming all other optimization techniques have been exhausted), you do what you have to do in order to meet requirements. If you have a requirement of 3 second response times, and this requirement is only achievable by trimming the size of your tables via surrogate IDs, then do what you have to do. 2) (As in your case) To take data from mulitple sources and conform the external, natural keys into an internal set of surrogate IDs in order to enforce RI and allow for Enterprise Reporting across the mulitple data sources - This is a totally valid reason to use surrogate IDs. Not everyody has the luxury of sourcing all of their data from a single source. The alternative is to store all externally sourced data within the same subject area into different tables (making enterprise reporting damn near impossible.) My 2 Cents, Clay
| ||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||
Copyright 2016 - All Rights Reserved | ||||||||||||||||||||||||||||||||||||||||||||||||
Last Modified: 15 Jun 2023 | ||||||||||||||||||||||||||||||||||||||||||||||||