August 13, 2012 at 10:15 am
Matt Miller (#4) (8/13/2012)
Jeff Moden (8/11/2012)
L' Eomot Inversé (8/11/2012)
I wouldn't claim that the problem can be avoided, simply that it is just as serious with (application-visible) surrogate keys as with natural keysThat's pretty much where I was getting ready to go with this... "It Depends" and neither is a panacea. Thanks, Tom.
Agreed. That said - in my career I have run into a lot more cases of a "natural key" becoming an issue than a surrgoate key becombing an issue.
Between the UPIN to NPI fiasco, followed by having to cleanse SSN's out of patient record systems, never mind several scads of supposedly "fool proof" composite natural keys that could "never" pop a duplicate, I do tend to challenge the use of keys which carry any form of business significance to the user community, relying instead on the "invisible" surrogate key concept instead.
For me, the way to go is to have visible "natural keys" which we accept may cease to be keys (cease to be unique) and design to be able to cope with that problem when it arises; that design includes having using surrogate keys where appropriate to help when such changes happen as well as to help with performance and storage optimisation.
If you've been through the whole replacement of medicare identifiers (UPIN, PIN, OSCAR Cert, NSC) by UPIN you realise what a complete mess it is when a visble surrogate key that doesn't work has to be replaced by something that does - you've probably suffered more from it that I have, since I never had to deal with anything like that. All too often it's replaced by another visible surrogate key which the designers (in this case the people who drafted HIPAA 1996 and/or the various NPI rules versions - has that stabilised yet?). And often the people who design it claim that it will last for ever (that was claimed for PIN, then for UPIN, and now for NPI).
The real source of the problem is of course that the people who specify the requirements decide these things can never cease to be keys, and allow them to become immutable, and the application and database database designers don't understand that this part of the requirement specification is balderdash (they even thing that the magic number is a natural key) so they design something which will be hard to change when the thing ceases to be a key. If such visible surrogate keys were recognised as maybe not something that should be considered as a key forever there would be fewer problems.
Of course natural keys can suffer from the same problem if people refuse to recognise that there can come a time when they are not unique.
Tom
August 13, 2012 at 10:19 am
GSquared (8/13/2012)
Matt Miller (#4) (8/13/2012)
Jeff Moden (8/11/2012)
L' Eomot Inversé (8/11/2012)
I wouldn't claim that the problem can be avoided, simply that it is just as serious with (application-visible) surrogate keys as with natural keysThat's pretty much where I was getting ready to go with this... "It Depends" and neither is a panacea. Thanks, Tom.
Agreed. That said - in my career I have run into a lot more cases of a "natural key" becoming an issue than a surrgoate key becombing an issue.
Between the UPIN to NPI fiasco, followed by having to cleanse SSN's out of patient record systems, never mind several scads of supposedly "fool proof" composite natural keys that could "never" pop a duplicate, I do tend to challenge the use of keys which carry any form of business significance to the user community, relying instead on the "invisible" surrogate key concept instead.
Second the motion.
Third
August 13, 2012 at 10:42 am
L' Eomot Inversé (8/13/2012)
Matt Miller (#4) (8/13/2012)
Jeff Moden (8/11/2012)
L' Eomot Inversé (8/11/2012)
I wouldn't claim that the problem can be avoided, simply that it is just as serious with (application-visible) surrogate keys as with natural keysThat's pretty much where I was getting ready to go with this... "It Depends" and neither is a panacea. Thanks, Tom.
Agreed. That said - in my career I have run into a lot more cases of a "natural key" becoming an issue than a surrgoate key becombing an issue.
Between the UPIN to NPI fiasco, followed by having to cleanse SSN's out of patient record systems, never mind several scads of supposedly "fool proof" composite natural keys that could "never" pop a duplicate, I do tend to challenge the use of keys which carry any form of business significance to the user community, relying instead on the "invisible" surrogate key concept instead.
For me, the way to go is to have visible "natural keys" which we accept may cease to be keys (cease to be unique) and design to be able to cope with that problem when it arises; that design includes having using surrogate keys where appropriate to help when such changes happen as well as to help with performance and storage optimisation.
If you've been through the whole replacement of medicare identifiers (UPIN, PIN, OSCAR Cert, NSC) by UPIN you realise what a complete mess it is when a visble surrogate key that doesn't work has to be replaced by something that does - you've probably suffered more from it that I have, since I never had to deal with anything like that. All too often it's replaced by another visible surrogate key which the designers (in this case the people who drafted HIPAA 1996 and/or the various NPI rules versions - has that stabilised yet?). And often the people who design it claim that it will last for ever (that was claimed for PIN, then for UPIN, and now for NPI).
The real source of the problem is of course that the people who specify the requirements decide these things can never cease to be keys, and allow them to become immutable, and the application and database database designers don't understand that this part of the requirement specification is balderdash (they even thing that the magic number is a natural key) so they design something which will be hard to change when the thing ceases to be a key. If such visible surrogate keys were recognised as maybe not something that should be considered as a key forever there would be fewer problems.
Of course natural keys can suffer from the same problem if people refuse to recognise that there can come a time when they are not unique.
I have to ask you what your definition of visible surrogate key is? Are you talking visible to the application or visible to the user of the application? My use of surrogate keys is within the database. If that means they have to be visible to the application in some way in order to handle parent/child relations, then you design for it. I don't want the surrogate keys visible to the users of the application. The users shouldn't even know they exist.
August 13, 2012 at 12:28 pm
Lynn Pettis (8/13/2012)
L' Eomot Inversé (8/13/2012)
Matt Miller (#4) (8/13/2012)
Jeff Moden (8/11/2012)
L' Eomot Inversé (8/11/2012)
I wouldn't claim that the problem can be avoided, simply that it is just as serious with (application-visible) surrogate keys as with natural keysThat's pretty much where I was getting ready to go with this... "It Depends" and neither is a panacea. Thanks, Tom.
Agreed. That said - in my career I have run into a lot more cases of a "natural key" becoming an issue than a surrgoate key becombing an issue.
Between the UPIN to NPI fiasco, followed by having to cleanse SSN's out of patient record systems, never mind several scads of supposedly "fool proof" composite natural keys that could "never" pop a duplicate, I do tend to challenge the use of keys which carry any form of business significance to the user community, relying instead on the "invisible" surrogate key concept instead.
For me, the way to go is to have visible "natural keys" which we accept may cease to be keys (cease to be unique) and design to be able to cope with that problem when it arises; that design includes having using surrogate keys where appropriate to help when such changes happen as well as to help with performance and storage optimisation.
If you've been through the whole replacement of medicare identifiers (UPIN, PIN, OSCAR Cert, NSC) by UPIN you realise what a complete mess it is when a visble surrogate key that doesn't work has to be replaced by something that does - you've probably suffered more from it that I have, since I never had to deal with anything like that. All too often it's replaced by another visible surrogate key which the designers (in this case the people who drafted HIPAA 1996 and/or the various NPI rules versions - has that stabilised yet?). And often the people who design it claim that it will last for ever (that was claimed for PIN, then for UPIN, and now for NPI).
The real source of the problem is of course that the people who specify the requirements decide these things can never cease to be keys, and allow them to become immutable, and the application and database database designers don't understand that this part of the requirement specification is balderdash (they even thing that the magic number is a natural key) so they design something which will be hard to change when the thing ceases to be a key. If such visible surrogate keys were recognised as maybe not something that should be considered as a key forever there would be fewer problems.
Of course natural keys can suffer from the same problem if people refuse to recognise that there can come a time when they are not unique.
I have to ask you what your definition of visible surrogate key is? Are you talking visible to the application or visible to the user of the application? My use of surrogate keys is within the database. If that means they have to be visible to the application in some way in order to handle parent/child relations, then you design for it. I don't want the surrogate keys visible to the users of the application. The users shouldn't even know they exist.
To be honest, I normally use surrogate keys and, if the data needs it, I'll also use "alternate" keys which are usually some form of natural key. So far as users never know that surrogate keys exist, I'll also say "It Depends". I think every customer should be allowed to know what their CustomerID is and every employee should know their "EmployeeID".
--Jeff Moden
Change is inevitable... Change for the better is not.
August 13, 2012 at 12:44 pm
Jeff Moden (8/13/2012)
To be honest, I normally use surrogate keys and, if the data needs it, I'll also use "alternate" keys which are usually some form of natural key. So far as users never know that surrogate keys exist, I'll also say "It Depends". I think every customer should be allowed to know what their CustomerID is and every employee should know their "EmployeeID".
I wouldn't necessarily consider the CustomerID and EmployeeID as surrogate keys. These are visible to users of the application and are important. The Student Information System I helped support had 2 StudentID's. One could be changed if needed, the other was fixed by the system.
August 13, 2012 at 5:01 pm
Lynn Pettis (8/13/2012)
I have to ask you what your definition of visible surrogate key is? Are you talking visible to the application or visible to the user of the application? My use of surrogate keys is within the database. If that means they have to be visible to the application in some way in order to handle parent/child relations, then you design for it. I don't want the surrogate keys visible to the users of the application. The users shouldn't even know they exist.
It looks as if your surrogate keys are either teh same as or close to my invisible surrogate keys, which means I must have badly misunderstood one of your earlier posts (in the other thread, I think).
To me a visible surrogate key is one that has to be pretty persistent outside the database. I classify a surrogate key as visible if either one of two things applies (or both, of course). The first is that although it doesn't really mean anything that ought to be understood by a user (why should users understand surrogates?) the user gets to see it and is encouraged by the databse+application system to use it and to remember what it designates. The second is that the application stashes it away in its own storage and assigns a long term meaning to it, so that if the database ceases to recognise it or changes its meaning the application falls apart.
Of course if the application makes transient use of a surrogate key that's OK, it doesn't make the surrogate key "visible" in my sense - the sort of thing I have in mind here is that an application wants a list of choices for a menu, what will be displayed is presumably something that is meaningful to the user in context but probably doesn't identify what is referred to without the context, and so that the context doesn't have to be maintained in programs, only in the user's head, and to avoid long transactions that live over multiple interactions with the user, a surrogate key is provided to the application for each menu entry so that if the user selects that entry the app can use the surrogate key to tell the database what has been selected (or that what has been selected no longer exists - that is an exception that the application has to handle as a penalty for avoiding multi-phase transactions).
Something which is genuinely meaningful to the users (eg a credit card number or an IBAN) isn't a surrogate key, it's either a natural key (as is an IBAN - or maybe we still haven't got that right and it's still a fragment - perhaps some IBANs still need a SWIFTBIC adding to make a complete natural key, although I am pretty sure that the practise of asking for a swiftbic is just for a redundant check on the country code and bank code in the IBAN) or a fragment of a natural key (as is a credit card number - the other fragments are typically expiry date and issue date).
The thing that tends to go wrong with visible surrogate keys (and with natural keys that are system generated, like IBAN) is that people believe that they have some magical property conferred on them by the generation process (whether it be clerical or bureaucratic or automatic) that ensures they will never cease to be unique, and design systems in such a way that a failure of this uniqueness is a catastrophic change. The idea that a key has that property is balderdash for most visible surrogate keys, and also for most natural keys. Of course it's balderdash for invisible surrogate keys too, but there we've kept the things hidden so that any impact of change is confined within the database, and (I hope) designed the system to make such events comparatively easy to handle.
Tom
August 13, 2012 at 6:42 pm
Lynn Pettis (8/13/2012)
Jeff Moden (8/13/2012)
To be honest, I normally use surrogate keys and, if the data needs it, I'll also use "alternate" keys which are usually some form of natural key. So far as users never know that surrogate keys exist, I'll also say "It Depends". I think every customer should be allowed to know what their CustomerID is and every employee should know their "EmployeeID".
I wouldn't necessarily consider the CustomerID and EmployeeID as surrogate keys. These are visible to users of the application and are important. The Student Information System I helped support had 2 StudentID's. One could be changed if needed, the other was fixed by the system.
That's where we differ. To me, a natural key would be something like a State abbreviation where a surrogate key on the same table would have absolute nothing natural about it. I consider CustomerID's and EmployeeID's that are generated simply by the likes of an IDENTITY column, to be a surrogate key even when exposed to the end user.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 14, 2012 at 7:35 am
Jeff Moden (8/13/2012)
Lynn Pettis (8/13/2012)
Jeff Moden (8/13/2012)
I consider CustomerID's and EmployeeID's that are generated simply by the likes of an IDENTITY column, to be a surrogate key even when exposed to the end user.
But EmployeeIDs generated by the likes of an identity column are very rare, apart from the examples in texbooks written by the clueless, and in databases owned by businesses who have the misfortune to possess staff who trust in such textbooks. Simple sequential numbering was already rare right back in the 60s, in the days of manual payroll and manual personnel records, because the problems simple sequential numbering caused were already recognised.
Typically a EmployeeID could be a string of characters (often decimal digits, but sometimes alphanumeric) that incorporated several meaningful substrings: a substring identifying the location/office which originally recruited the employee; a substring allocated by the recruiting office as a serial number (so 0005 would mean the 5th person recruited by this office); a substring acting as validity check for the rest (perhaps modulo 97 checkdigits, or something longer); and perhaps other substrings - after the first merger or take-over, the system would incorporate a substring identifying the company which originally recruited the employee. This made it fairly easy to cater for reassigning employee neumbers on merger or takeover - the company code part of the EmployeeID would indicate what the format of the rest of the structured ID was, so the only change on take-over was to stick a company identifier in front of existing IDs for employees of the company being taken over; on merger, the company id might be added to employeeIDs from both companies; and of course compay IDs could be structured themselves, so chains of take-overs and mergers were OK too.
I first came across structured EmployeeIDs in a brief summer vacation job before I went to university - can't remember exactly which year, but it was either 1961 or 1962, and the structured employeID seemed to be old hat already then - long before we had any hierarchic or network or relational databases; probably it originated long before there was any concept of a computer-based database (the term "database" itself dates from the early 60s, I think).
If people are using employeeIDs generated as values in an IDENTITY column with no internal coding and making them visible to users they will need to stop using that the first time anything interesting happens; it really doesn't work, long term. And I would agree with you that these are visible surrogate keys. It doesn't strike me as at all a good idea to use them.
Tom
August 14, 2012 at 7:59 am
L' Eomot Inversé (8/14/2012)
Jeff Moden (8/13/2012)
Lynn Pettis (8/13/2012)
Jeff Moden (8/13/2012)
I consider CustomerID's and EmployeeID's that are generated simply by the likes of an IDENTITY column, to be a surrogate key even when exposed to the end user.But EmployeeIDs generated by the likes of an identity column are very rare, apart from the examples in texbooks written by the clueless, and in databases owned by businesses who have the misfortune to possess staff who trust in such textbooks. Simple sequential numbering was already rare right back in the 60s, in the days of manual payroll and manual personnel records, because the problems simple sequential numbering caused were already recognised.
Typically a EmployeeID could be a string of characters (often decimal digits, but sometimes alphanumeric) that incorporated several meaningful substrings: a substring identifying the location/office which originally recruited the employee; a substring allocated by the recruiting office as a serial number (so 0005 would mean the 5th person recruited by this office); a substring acting as validity check for the rest (perhaps modulo 97 checkdigits, or something longer); and perhaps other substrings - after the first merger or take-over, the system would incorporate a substring identifying the company which originally recruited the employee. This made it fairly easy to cater for reassigning employee neumbers on merger or takeover - the company code part of the EmployeeID would indicate what the format of the rest of the structured ID was, so the only change on take-over was to stick a company identifier in front of existing IDs for employees of the company being taken over; on merger, the company id might be added to employeeIDs from both companies; and of course compay IDs could be structured themselves, so chains of take-overs and mergers were OK too.
I first came across structured EmployeeIDs in a brief summer vacation job before I went to university - can't remember exactly which year, but it was either 1961 or 1962, and the structured employeID seemed to be old hat already then - long before we had any hierarchic or network or relational databases; probably it originated long before there was any concept of a computer-based database (the term "database" itself dates from the early 60s, I think).
If people are using employeeIDs generated as values in an IDENTITY column with no internal coding and making them visible to users they will need to stop using that the first time anything interesting happens; it really doesn't work, long term. And I would agree with you that these are visible surrogate keys. It doesn't strike me as at all a good idea to use them.
Sequential numbering with the values visible to the employees is what Satrbucks uses. Not only are they happy with the system, the employees get excited about it since your number is an indicator of when you joined the company. When employees meet, one of the first things they do is compare employee numbers. It seems to have worked for them long term.
Why do you think it won't work?
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
August 14, 2012 at 8:09 am
I get ideas from the weirdest places. I keep threatening to write stories about you people and never do. Well, this debate has inspired me to come up with a first draft quickie and I have decided to present it for your reading entertainment. @=)
"The Great Key Debate" by Brandie Tarvin (copyright me, of course)
Thunder rumbled overhead, a clear warning to innocent bystanders of the storm's inherent danger. But they chose to ignore it, captivated by the ongoing debate in Thread Town Square.
Lynn and Tom stood on opposite ends of the drought-stricken meadow, a parched forum of brittle humors and harsh comments. Yellowed backgrounds of aged LCD crackled underfoot as each adjusted their positions, hands at the ready, hovering waist-high above their weapons of choice. Hard eyes glinted, staring with laser precision into their opponent. If looks could kill, they'd have bored holes into each other's brains long ago.
An electron whispered. A packet dropped. The bystanders crowded close as debate ended and conflict began. The digital wind howled in dirge-like tones. Fingers twitched, breathing hitched.
Without warning, keyboards clattered, pages and pages of text filling the air. The tornado chaos flung spaghetti code rants across internet skies of screen-death blue. The posts slammed down upon Thread Town Square so fast and furious the spectators could barely keep track.
Then it happened. Out of thin air, someone pulled out the Ultimate Weapon. Books Online crashed through the barriers of real space, shattering the concentration of hundreds. Lynn and Tom looked up.
It was the last sight they ever saw.
August 14, 2012 at 8:40 am
Brandie Tarvin (8/14/2012)
I get ideas from the weirdest places. I keep threatening to write stories about you people and never do. Well, this debate has inspired me to come up with a first draft quickie and I have decided to present it for your reading entertainment. @=)"The Great Key Debate" by Brandie Tarvin (copyright me, of course)
Thunder rumbled overhead, a clear warning to innocent bystanders of the storm's inherent danger. But they chose to ignore it, captivated by the ongoing debate in Thread Town Square.
Lynn and Tom stood on opposite ends of the drought-stricken meadow, a parched forum of brittle humors and harsh comments. Yellowed backgrounds of aged LCD crackled underfoot as each adjusted their positions, hands at the ready, hovering waist-high above their weapons of choice. Hard eyes glinted, staring with laser precision into their opponent. If looks could kill, they'd have bored holes into each other's brains long ago.
An electron whispered. A packet dropped. The bystanders crowded close as debate ended and conflict began. The digital wind howled in dirge-like tones. Fingers twitched, breathing hitched.
Without warning, keyboards clattered, pages and pages of text filling the air. The tornado chaos flung spaghetti code rants across internet skies of screen-death blue. The posts slammed down upon Thread Town Square so fast and furious the spectators could barely keep track.
Then it happened. Out of thin air, someone pulled out the Ultimate Weapon. Books Online crashed through the barriers of real space, shattering the concentration of hundreds. Lynn and Tom looked up.
It was the last sight they ever saw.
:Wow: I like it. You really should write more, I think it would be fun and interesting.
August 14, 2012 at 8:43 am
Lynn Pettis (8/14/2012)
Brandie Tarvin (8/14/2012)
I get ideas from the weirdest places. I keep threatening to write stories about you people and never do. Well, this debate has inspired me to come up with a first draft quickie and I have decided to present it for your reading entertainment. @=)"The Great Key Debate" by Brandie Tarvin (copyright me, of course)
Thunder rumbled overhead, a clear warning to innocent bystanders of the storm's inherent danger. But they chose to ignore it, captivated by the ongoing debate in Thread Town Square.
Lynn and Tom stood on opposite ends of the drought-stricken meadow, a parched forum of brittle humors and harsh comments. Yellowed backgrounds of aged LCD crackled underfoot as each adjusted their positions, hands at the ready, hovering waist-high above their weapons of choice. Hard eyes glinted, staring with laser precision into their opponent. If looks could kill, they'd have bored holes into each other's brains long ago.
An electron whispered. A packet dropped. The bystanders crowded close as debate ended and conflict began. The digital wind howled in dirge-like tones. Fingers twitched, breathing hitched.
Without warning, keyboards clattered, pages and pages of text filling the air. The tornado chaos flung spaghetti code rants across internet skies of screen-death blue. The posts slammed down upon Thread Town Square so fast and furious the spectators could barely keep track.
Then it happened. Out of thin air, someone pulled out the Ultimate Weapon. Books Online crashed through the barriers of real space, shattering the concentration of hundreds. Lynn and Tom looked up.
It was the last sight they ever saw.
:Wow: I like it. You really should write more, I think it would be fun and interesting.
+1
Tom
August 14, 2012 at 8:49 am
L' Eomot Inversé (8/14/2012)
Lynn Pettis (8/14/2012)
Brandie Tarvin (8/14/2012)
I get ideas from the weirdest places. I keep threatening to write stories about you people and never do. Well, this debate has inspired me to come up with a first draft quickie and I have decided to present it for your reading entertainment. @=)"The Great Key Debate" by Brandie Tarvin (copyright me, of course)
Thunder rumbled overhead, a clear warning to innocent bystanders of the storm's inherent danger. But they chose to ignore it, captivated by the ongoing debate in Thread Town Square.
Lynn and Tom stood on opposite ends of the drought-stricken meadow, a parched forum of brittle humors and harsh comments. Yellowed backgrounds of aged LCD crackled underfoot as each adjusted their positions, hands at the ready, hovering waist-high above their weapons of choice. Hard eyes glinted, staring with laser precision into their opponent. If looks could kill, they'd have bored holes into each other's brains long ago.
An electron whispered. A packet dropped. The bystanders crowded close as debate ended and conflict began. The digital wind howled in dirge-like tones. Fingers twitched, breathing hitched.
Without warning, keyboards clattered, pages and pages of text filling the air. The tornado chaos flung spaghetti code rants across internet skies of screen-death blue. The posts slammed down upon Thread Town Square so fast and furious the spectators could barely keep track.
Then it happened. Out of thin air, someone pulled out the Ultimate Weapon. Books Online crashed through the barriers of real space, shattering the concentration of hundreds. Lynn and Tom looked up.
It was the last sight they ever saw.
:Wow: I like it. You really should write more, I think it would be fun and interesting.
+1
+1
August 14, 2012 at 8:52 am
Love the story snippet.
#declare TopicChange
New article over at simple talk - SQL Server howlers. Partitioning, indexing, hints and server settings. https://www.simple-talk.com/sql/database-administration/gail-shaws-sql-server-howlers/
</shameless plug>
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 14, 2012 at 9:10 am
Brandie Tarvin (8/14/2012)
I get ideas from the weirdest places. I keep threatening to write stories about you people and never do. Well, this debate has inspired me to come up with a first draft quickie and I have decided to present it for your reading entertainment. @=)"The Great Key Debate" by Brandie Tarvin (copyright me, of course)
Thunder rumbled overhead, a clear warning to innocent bystanders of the storm's inherent danger. But they chose to ignore it, captivated by the ongoing debate in Thread Town Square.
Lynn and Tom stood on opposite ends of the drought-stricken meadow, a parched forum of brittle humors and harsh comments. Yellowed backgrounds of aged LCD crackled underfoot as each adjusted their positions, hands at the ready, hovering waist-high above their weapons of choice. Hard eyes glinted, staring with laser precision into their opponent. If looks could kill, they'd have bored holes into each other's brains long ago.
An electron whispered. A packet dropped. The bystanders crowded close as debate ended and conflict began. The digital wind howled in dirge-like tones. Fingers twitched, breathing hitched.
Without warning, keyboards clattered, pages and pages of text filling the air. The tornado chaos flung spaghetti code rants across internet skies of screen-death blue. The posts slammed down upon Thread Town Square so fast and furious the spectators could barely keep track.
Then it happened. Out of thin air, someone pulled out the Ultimate Weapon. Books Online crashed through the barriers of real space, shattering the concentration of hundreds. Lynn and Tom looked up.
It was the last sight they ever saw.
Okay, Brandie, here is an idea that you probably already had. We all know the stories of the Knights Templar, the Men in Black, add your own secret society. We also know that on this forum people have asked how to keep the DBA from seeing the data stored in the database. We need a story where the secret society is in fact the DBA's entrusted with the keys to societies data. Would be an intriguing story line, just too bad I don't have the wordsmith skills to pull it off.
Viewing 15 posts - 37,471 through 37,485 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply