Sequential keys are ok unless you have a heavily used system as you have to read with a lock, and increment a counter somewhere - in this instance we use unique ids generated using date, system time in milleseconds (system(12) in udt) and pid combined together
Symeon. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Gettino Sent: 28 August 2008 19:07 To: u2-users@listserver.u2ug.org Subject: RE: [U2] UniData Keys There is no way you should put the email address as part of the key. You can run into key length issues, the file will not hash properly causing access to it to be slow. Based on speed which is all we care about in 911 development. We use sequential keys zero filled. Date, time and email address would be attributes 1, 2 and 3. Build an index off of the data you will access all the time. The file will hash very nicely. Just make sure your counter of keys doesn't roll over back to 1 again. My 2 cents. Nicholas M Gettino | Director of Development | EnRoute Emergency Systems, an Infor company | office: 813-207-6998 | fax: 678-393-5389 [EMAIL PROTECTED] | www.enroute911.com Register Now! | EnRoute Emergency Systems Customer Conference | September 22-25, 2008 | Mainsail Suites Hotel & Conference Center | Tampa, Florida -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jpb-u2ug Sent: Thursday, August 28, 2008 10:53 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] UniData Keys I would go for #1 because the time slice may be short and cause a problem with key creation the other ways. It would create lots of records but small ones and may be faster. You can then move them into another file, periodically, deleting the single valued records and creating multi-valued ones using the email address as the key. Jerry Banker -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Israel, John R. Sent: Thursday, August 28, 2008 7:39 AM To: 'u2-users@listserver.u2ug.org' Subject: [U2] UniData Keys I am tasked with building an log file for our customers using our web site (Redback). I have figured out how to grab what I need, but am not sure the best way to make the file structure. I need to track the user (their E-mail address), the web page, the various request options, the date and time. Should I: 1) make each record a unique hit on the web (i.e. not multi-valued) with a sequential number as the key? 2) make each record a unique hit on the web (i.e. not multi-valued) with the key being the emailAddress*date*time (a big key depending on the emailAddress)? 3) make the key the emailAddress*date, with each hit that person makes a multi-value based on the time? The issue here is that while I am not storing a lot of pieces of data for each hit, some of the data will be big (emailAddress, web page). Option 2 could have a big key and I believe UniData would prefer a smaller one (half the data is the key). To take it to an extreme, since there are no multi-values, the entire key could be the record, but clearly, this is not preferred. Option 3 would take advantage of multi-values, but a user who hits a lot of pages will have a HUGE record for each day. I am leaning towards option 1 (many small records, with a sequential number as the key), but wanted to throw this out for debate. John Israel ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.6.7/1632 - Release Date: 25/08/2008 07:05 No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.6.7/1632 - Release Date: 25/08/2008 07:05 ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
