Harvinder,
Every table needs a PK. Otherwise, you have no way of identifying a row
uniquely.
You also need an index on each FK, to prevent locking problems when
updating/deleting the parent table. You can kill two birds with one stone
by making your history tables' PKs (enforced by unique inde
You can have a PK for your history table(like a sequence number) and add the
PK from another table as normal column for this history table.
There is no need for and Relationship to the history table.
-Original Message-
Sent: Thursday, March 07, 2002 9:13 AM
To: Multiple recipients of list
On Tuesday 12 June 2001 13:19, Jared Still wrote:
> The only real downfall of surrogate keys is that it may require a developer
> to do a join on the FK to the parent table to get the unique key
> information.
Well, there are other downfalls on a system with a high transaction rate,
but there ar
This is strictly a warehouse type solution. Loads only, never an
update.
Images and supporting data will be loaded from another database and
queried from the internet and will remain online for X days.
I do need to find out about the uniqueness of this data though just for
my information. They
Brian,
This may be rather simplistic, but why can't you just use the bank routing
number, account number, check number as the primary key? Routing numbers
are unique to each bank. Account numbers are unique to each bank/customer.
Check numbers are unique to each customer. Occasionally, an uns
WOW! Overhead city! If this is being done on such large tables I would strongly suggest a simple application modification to include a better way to query. It looks to me like a primary key is in order.
Brian Wisniewski <[EMAIL PROTECTED]> wrote:
The will be querying off of customer id, check n
The other problem is that if you do not have a unique key, how can you ever manipulate
that row. while I know that you can use the rowid, that will not work if you ever
need to link another table into your application.
>>> "Tony Johnson" <[EMAIL PROTECTED]> 02/01/01 03:27PM >>>
How are you goi
I don't know if my prior email made it out to the list or not.
In 99% of the rows the Primary key will be a combination of 2 fields
however they cannot be 100% sure this concatenated key will always be
unique therefore the need for the surrogate key.
>From what I've gathered the PK will usually
When you say "no natural key" I assume you mean no data that is non-null
and unique. How, then, do you propose to get single records, since you
(probably) don't want to have to find them by the image data...
Of course, if the table is write-only -- who cares? :-)
Brian Wisniewski wrote:
> I kn
The will be querying off of customer id, check number, etc but they
cannot guarantee the combination of customer and check or various other
columns will be a unique row so the need for a sequence. The columns
that would normally make up the PK are ALMOST always unique but once in
a while ...
Th
How are you going to retrieve the data in these tables for your application.
A surrogate key as you are describing is valid in many instances if for no
other reason that to make the model much cleaner. There are many occasions
where the 'live-and-die' relational rules have to be bent to meet real
Well, how are you going to locate the image you need? If none of the
supported data is needed to describe or locate the image, why have the
data at all? I'm not quite sure how to answer your question.
-Original Message-
Sent: Thursday, February 01, 2001 2:08 PM
To: Multiple recipients
12 matches
Mail list logo
