Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
steelkilt
Constraint Violating Yak Guru
255 Posts |
 Posted - 2003-11-06 : 11:49:34
|
| I have a database, call it PARENT, with a primary key that allows decimals and whole numbers. For those who are already wincing, I refer you to this thread, written awhile back, describing my original predicament. http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=19351I have no choice but to live with this PK.One of the managers at my place of work needs to begin collecting data from a sub-population of people who don't technically belong in the above-mentioned db, i.e. they are part of a related study. However, this manager would be collecting the exact same data that we collect in the PARENT db, i.e. same tables and fields across the board.Now, the last thing I want to do is create a mirror image of PARENT, including web-based data entry front-end for this guy just so he can keep tabs on a very small set of records, maybe 100 total, that will be moved in 1 year's time to an archive separate from PARENT. And since PARENT is the master db, whenever there are design changes made to tables/fields/etc. in PARENT, same changes would have to be made in the mirror image db.I'm sorely tempted to allow this guy to add his subjects to PARENT, but flag these subjects in such a way as to make absolutely sure they are never included in query results that don't specifically ask for them. This would involve blocking off a chunk of unique numbers that would NOT otherwise be used for normal PARENT records. Acceptable entries for normal PARENT records are decimal entries, max of two places to the right, i.e. 2.1 or 2.15 and whole numbers, i.e. 12000. The data type on this field is FLOAT. <ouch> So, for example, I could allow the "renegade" records to have unique IDs that are negative values.The db designer purist's call is to keep these data sets separate. The purist might say: "if the new subject cannot be assigned the next available unique ID because those IDs are reserved for the "proper" subjects, then this new subject does not belong in this db."However, keeping in mind that PARENT would be a temporary location for a small subset of data, might you be tempted to do what I'm thinking of doing?Thx./Steelkilt |
|
|
|
|
|
|
|
Allow renegade records if I promise to move them?