Re: Millisecond time stamp
I am writing a type of message stack that is built while a task is
processing and presented to the user at the end of processing. I do it
using a function like
Logit("Blah, blah, blah");
Which records the SessionID, Sequence and Message, which is presented to
the user in sequence at the end of processing.
I was thinking of indexing on Timestamp which lead to my first post.
But as Tim pointed out I am better off using an auto-increment (hence
the banging my head against the wall for not thinking of that myself).
So as far as I am concerned, problem solved
John Meyer wrote:
John Comerford wrote:
Thanks for the replies guys, banging my head against the wall for not
thinking of using an auto increment integer to handle the sequence,
I've got to cut back on those Friday night beers
Okay, color me confused, but what exactly are you wanting to do anyway?
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Millisecond time stamp
John Comerford wrote: Thanks for the replies guys, banging my head against the wall for not thinking of using an auto increment integer to handle the sequence, I've got to cut back on those Friday night beers Okay, color me confused, but what exactly are you wanting to do anyway? -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Millisecond time stamp
Thanks for the replies guys, banging my head against the wall for not thinking of using an auto increment integer to handle the sequence, I've got to cut back on those Friday night beers On 4/17/07, John Comerford <[EMAIL PROTECTED]> wrote: Hi Folks, A) One character string contain a string I build with the date and milliseconds tagged onto the end b) Two separate fields Field1 TimeStamp Field2 Milliseconds I am leaning towards approach B, but saying that it's more gut instinct than anything else. My questions are: 1) Is there some a better way to achieve what I want ? 2) Which of the two methods above would/do you use ? -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Millisecond time stamp
On 4/18/07, Tim Lucia <[EMAIL PROTECTED]> wrote: -Original Message- From: John Comerford [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 17, 2007 10:50 PM To: mysql@lists.mysql.com Subject: Millisecond time stamp Hi Folks, I am putting together a table to hold log entries. I was going to index it on a field with a type of TimeStamp. Unfortunately this will not suit my needs because I could have more than one log entry per second. As far as my (limited) knowledge goes I have two options to get around this: A) One character string contain a string I build with the date and milliseconds tagged onto the end b) Two separate fields Field1 TimeStamp Field2 Milliseconds WHY are you indexing the Timestamp? It should not be your primary key because, as you point out, it might allow duplicates. Even case B is not foolproof. If you're indexing it for searching, then your application should be prepared to handle multiple log records for any value. For uniqueness, add an auto_increment primary key column. That way, you can tell two+ log records apart even when they have the same timestamp. Tim - Dave Ashley's note: Tim's solution is better than the one I proposed if this is your only problem. In my applications, typically the need for unique identifiers comes up in may places, so I'm used to using that style of solution. However, adding an auto-increment primary key column will get the same effect with a lot less work. Also, it is probably more efficient due to the absence of a spin-lock.
Re: Millisecond time stamp
On 4/17/07, John Comerford <[EMAIL PROTECTED]> wrote: Hi Folks, A) One character string contain a string I build with the date and milliseconds tagged onto the end b) Two separate fields Field1 TimeStamp Field2 Milliseconds I am leaning towards approach B, but saying that it's more gut instinct than anything else. My questions are: 1) Is there some a better way to achieve what I want ? 2) Which of the two methods above would/do you use ? What you are looking for is the notion of a server-globally-unique-identifier (SGUID). You want something that can't occur again. Milliseconds isn't precise enough. You want microseconds or nanoseconds. You also need to consider these things: a)With PHP (assuming web access), multiple processes can be active at the same time. Thus, even with microseconds, it is possible for two different processes to get exactly the same timestamp (especially since the microseconds counters are typically updated only on hardware timer interrupts, which don't occur every microsecond). Thus, you need more than just time to ensure uniqueness. b)It is helpful if the string sorting order of the field is also the time order. The best approach I've found is to use the following fields, fixed length, concatenated: a)Integer time (seconds). b)Microtime (microseconds or nanoseconds). c)PID of the process. with the provision that the code must execute a spinlock to wait for the microtime to change (otherwise, the next call could get the same identifier, or--although no practical system is this fast--the current process could end and another could run with the same PID and get the same time. Using the three fields above with the spin-lock, the string generated is guaranteed unique for the lifetime of the server (assuming that nobody tampers with the machine time). The result from above is guaranteed unique because no two processes can have the same PID at the same time. Here is some sample code: http://fboprime.e3ft.com/vcvsgpl01/viewcvs.cgi/gpl01/webprojs/fboprime/sw/phplib/sguid.inc?rev=1.4&content-type=text/vnd.viewcvs-markup You can figure out how to navigate from the above to find the other include files referenced. If you have any questions and I don't seem to reply to something you post on this list, please write me at [EMAIL PROTECTED] and reply to the server's reply to make it through my SPAM filtering. I don't always watch this mailing list closely. Dave
RE: Millisecond time stamp
> -Original Message- > From: John Comerford [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 17, 2007 10:50 PM > To: mysql@lists.mysql.com > Subject: Millisecond time stamp > > Hi Folks, > > I am putting together a table to hold log entries. I was going to index > it on a field with a type of TimeStamp. Unfortunately this will not > suit my needs because I could have more than one log entry per second. > As far as my (limited) knowledge goes I have two options to get around > this: > > A) One character string contain a string I build with the date and > milliseconds tagged onto the end > b) Two separate fields Field1 TimeStamp Field2 Milliseconds WHY are you indexing the Timestamp? It should not be your primary key because, as you point out, it might allow duplicates. Even case B is not foolproof. If you're indexing it for searching, then your application should be prepared to handle multiple log records for any value. For uniqueness, add an auto_increment primary key column. That way, you can tell two+ log records apart even when they have the same timestamp. Tim > I am leaning towards approach B, but saying that it's more gut instinct > than anything else. My questions are: > > 1) Is there some a better way to achieve what I want ? > 2) Which of the two methods above would/do you use ? > > I am using PHP to access the database and I am fairly new to both PHP > and MySQL. > > TIA, > JC > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
