Dan Waters
df.waters at outlook.com
Wed Sep 3 09:14:01 CDT 2014
Hi Susan, What he is talking about, in effect, is using a time value as a primary key. He says that each time value that would be [automatically] entered into a database when a new record is create would always be different by at least 100 nanoseconds. It looks like he might be taking data from one database and using it to create a new database that is specifically designed for telephone data analysis (a rather specialized activity). He doesn't say what the original database primary key is, so we don't know why he wants to use a time value instead. If I was doing something like this I would certainly use the original primary key (unless that key has a problem). But without that key, then using the time value like he's describing sounds like a reasonable alternative. I would not use a time value as a primary key unless I had to. I always use autonumbers in Access, or in SQL Server I use the primary key set up as an integer with an identity, seed = 1, and increment = 1 (this ends up working just like an autonumber in Access. So, for your app I'd suggest sticking with Autonumbers for primary keys. Good Luck! Dan -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Susan Harkins Sent: Wednesday, September 03, 2014 9:02 AM To: Discussion concerning MS SQL Server Subject: [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 > _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com