If you look at the database the user has, and the data given by that database, you will see that his composite key is a combination of a string id, and the time the news item was generated (or something along those lines).
This is used either to reduce the risk of having a primary key used twice, as we're using two elements, or because of the user's lack of knowledge of SQL (there's no reason to use a composite key, if one of the keys in that composite key can be primary in itself.) I admit my statement isn't true, but it would have resulted in the correct application by the anon monk ;) (I have sinned.)
The primary key is an attribute or a set of attributes that uniquely identify a specific instance of an entity. If you were to benchmark a statement using a composite primary key, or a one attribute primary key, you would find that they single primary key would go faster. (Try using SQL's explain feature. This goes with the standard perl notion, of doing things with as little code as possible, while maintaining maximum flexibility, and pumping out high performance. From what I saw of the use of this monk's primary (composite) key, it would be easyer to create either a random string, which would be verified by the database as unused as a key, or just an integer, using auto_increment for the key. Primary keys are used to speed up queries (for the most part), and using a primary composite key doesn't help that out. In some instances it is necessary to create a primary composite key, but for the most part a primary key should suffice.
That's why I was hinting at the fact that a composite key was not necessary, but you got me on the fact that my statement is actually not valid, and was not thought out... my bad ;)
Sorry for the tangent, but I thought it was necessary to explain my reasoning.
Gyan Kapur
gyan.kapur@rhhllp.com | [reply]
[d/l] |