For a job interview, I need to know the differneces between NATURAL 1.2
and NATURAL 2 - used with ADABAS.
Can anyone give me a brief summary.
Thanks - Joe Jones - MSc. Comp. Sci Studnet at South Bank University, London
Another issue arises under my favourite topic of discussion!
What solutions do people have for creating a "natural" key that is both
meaningful, and unique.
Consider a situation where people create "things" that will be stored as
unique entities, but where the user themselves have not predefined a
natural, unique identifier. In other words, it is left up do the database to
create an identifier (heck, every "natural" key must have been created by
someone or something at some point, right?)
Well, a natural key might be defined at least partly by who is submitting it
and when. As a quick example, a table created in 2003 might be keyed as
The idea is to have as much of the key as possible be meaningful, the xxxx
is there merely to guarantee uniqueness.
Is there any way to efficiently and safely implement creating the unique
(xxxx) part of the key?
By "efficient", I mean without causing serialized inserts. Is an instead of
insert trigger the best solution (using either a temp table with an identity
and using that, or using the max+1 method (which I would rather avoid...
like the plague)? Moreover, is there any _standard_ solution? (Are IOI
triggers sql server specific?)
By "safe", I mean that relying on serial inserts is surely bad. OK, we could
have a stored proc to insert records one at a time, acting as a middle tier
key generator. But what happens when Mr dbo comes along in a year's time and
performs a basic insert statement against the table from some other table?
Or more generally, for some reason in the future a set based insert
operation is required?
As an almost total tangent, I have seen a few posts which recommend using a
datetime key... eg this from JC...
CREATE TABLE Foobar
(trans_date DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
product_id INTEGER NOT NULL,
quantity INTEGER NOT NULL,
Surely this fails Joe's own test regarding set based inserts as every record
in the inserted set will get the same timestamp.