Hi Bill,
I don't know how are stored primary keys in SQL Server, but it seems to me
that having multiple fields indexes would only double the complexity of
searching a single record ( O(2 * log(RecordNumber)/log(2) ), which is not
so bad.
So what I would do is to keep my PK as long as I can deal with it, and the
day I have to split my records, I'll switch. It is not so hard to break
out data for identifying the type of info you said.
Cheers,
Franck
Le Tue, 28 Mar 2006 02:17:40 -0500, Bill H a écrit :
[quoted text, click to view] > Is it recommended to keep primary keys limited to a single field?
>
> I have an account_id in all tables, and I wanted to make the rec_id in all
> tables unique within an account_id, so the primary key would be based on
> account_id + rec_id. I like the idea of each Account starting at 1 for
> their rec_ids, though I know this is not necessary. I also want to do this
> in case I need to break out all recs in all tables for a particular account
> or customer. Initially, all customers will be hosted in one database for a
> web app. But there will opportunity for that customer to later host their
> own data, at which point, it be real easy to break out their data.
>
> The downside is that all my queries need to include account_id. Will this
> impact performance on SQL much greater than having a single field primary
> key ? Is there a recommended design for this ?
>
> It will work either way, I know. I'm just trying to get opinions on the
> preferred method out there.
>
>
> Thanks...
> Bill