Enter Your Reply

Graeme Neatham wrote:

Primary Key - the Candidate Key that is the main index for a table and which will be used as a Foreign Key in other tables. For performance purposes a Primary Key will usually not be Composite.

What kind of performance issues are there? With a composite primary key, will it search individual keys until it finds a match instead of directly knowing where to go?

Self-rating - personally I would be wary of such a practice, not because I think inventors are always going to give maximum marks to their own games, but because they are too close to their own games to provide a disinterested assessment.

I'm not worried about that. I think that game inventors, especially the more productive ones, distinguish between games they consider experiments and games they consider masterpieces. And especially when it comes to inventors of several games, I want to know which ones they like best. Regardless of how objective inventors can be in evaluating their own games, I want to know how they evaluate their own games.

Overwriting of data due to revision of values leading to loss of historical data strikes me as being what would be called 'bad practice'. But I guess I'm guilty of trying to apply corporate standards in a non-corporate situation.

I'm not worried about overwriting old data, because it will have no use anyway. Also, if I included old data, I would either have to expand the table dynamically or use a more complicated primary key. The latter approach could be a real problem, because the php script would not know what primary key to use to access the ratings.