Gustav Brock
gustav at cactus.dk
Wed Sep 3 09:08:45 CDT 2014
Hi Susan It sounds like a log table. Does he need a PK at all? A unique index on the call start field should do it. /gustav -----Oprindelig meddelelse----- Fra: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] På vegne af Susan Harkins Sendt: 3. september 2014 16:02 Til: Discussion concerning MS SQL Server Emne: [dba-SQLServer] Fwd: SQL Server Primary Key This is from a reader -- seriously over my head. Anyone want to offer some advice? Susan H. On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com> wrote: > Hi Susan, > Just reading your post regarding using the right Primary Key. I'm > building a rehouse to store telephone data. Each phone record can be > uniquely identified by the DateTime2(7) start time of the call because > each record is guaranteed to be created in a different 100 nano second > window. There are 100 million records. The main way to view data is chronological order. > I'm trying to decide whether to use the CallStart datetime2(7) field > for the primary key. I can cluster on this key and join to my bridging > tables using this key. Or should I crate a CallId (Bigint) that > encodes the datetim, Maybe in yymmddhhmmssnnnnnnn format. You have > stated on your post that there is an overhead to using Datetime type > as the primary key. Is this true for my scenario? > Best regards > > Phillip