|
|
Posted by pb648174 on 03/14/06 14:54
Just out of curiosity, lets say we are told that only a basic
description of something is needed, let's say a list of projects that a
user is going to work on, that needs to be 500 characters long. What
should the primary key be? Is it the 500 character description or an
identity column? Are there performance issues with having 500 character
foreign keys, indexes, etc.? In what ways is it going to be better than
using an identity column taking into account that it is going to be
passed through the QueryString, posted in links, etc.?
Doug, I think your solution would mostly work, but be a pain to
implement when there are lots of columns. I think perhaps a more
general way to do it would be to store only the primary key of the
copied data (identity or not) and use that to know which records were
copied. As long as the amount of copied data is fairly small I don't
see that there would be a very big performance impact for that. I think
I might just do that to avoid needing the serializable transaction.
--CELKO-- wrote:
> Your whoel mental model of RDBMS is wrong and it is about to kludge you
> to death.
>
> When you look for a key, start with your industry standards. I have
> been in IT for a bit over 35 years, and would estimate that this covers
> ~80% of the properly defined systems -- VIN, ISBN, UPC, EAN, etc. which
> can be verified and validated via a trusted exernal source. In the ode
> days, this took time; you can Google it today.
>
> After that, there is a natural key in the data, such as (longitude,
> latitude), (store, cash register, ticket_nbr), etc. which can be
> verified and validated in the reality of the data. This is ~18% of the
> cases. if you have no natural key, then your schema is probably wrong.
>
>
> Then, if that fails we invent a key with check digits, validation rules
> and an audit trail within our enterprise. This is a great screaming
> pain IF you do it right. This is why industry standards exists --
> people got tired the pain (would you like to do Retail without UPC
> barcodes on products?)
>
> So, newbies prefer to do it wrong by using auto-increments or other
> proprietary stuff that cannot be verified or validated BECAUSE it is
> easier than real RDBMS design. It takes SIX years to become a Union
> Journeyman carpenter in New York State, but newbies can be a DB
> designer in less than 10 years. Hell, less than 10 months! WOW!
>
> I know you want the quick easy answer that does not require you
> ACTUALLY UNDERSTAND the business problem or your problem domain. Just
> make up something in the software and hope you never write for a
> company that has a SOX audit or a Data Warehouse project.
>
> What you posted is just enough to get a lot of Kludges but not a real
> answer.
Navigation:
[Reply to this message]
|