Question

The table

I got a table that contains price for some 1 000 000 articles. The articles got a uniques ID-number but the table contains prices from multiple stores. Thus if two stores got the same article the uniques ID will not be unique for the table.

Table Structure

table articles

id INT

price IN

store VARCHAR(40)

Daily use

Except for queries using the ID-number by users I need to run daily updates where data from csv-files insert/update each article in the table. The choosen procedure is to try to select an article and then perform either an insert or an update.

Question

With this in mind, which key should I choose?

Here are some solutions that Ive been considering:

• FULLTEXT index of the fields isbn and store
• Add a field with a value generated by isbn and store that is set as PRIMARY key
• One table per store and use isbn as PRIMARY key

Answer 1

Use a compound primary key consisting of the store ID and the article ID – that’ll give you a unique primary key for each item on a per-store basis and you don’t need a separate field for it (assuming the store id and article id are already in the table).

Ideally you should have 3 tables… something like:

article
--------------------------------------------
id | isbn | ... etc ...


store
--------------------------------------------
id | description | ... etc ...


pricelist
--------------------------------------------
article_id | store_id | price | ... etc ...

With the PRIMARY KEY for pricelist being a compound key made up of article_id and store_id.

EDIT : (updated to incorporate an answer from the comment)

Even on a million rows the UPDATE should be OK (for a certain definition of OK, it might still take a little while with 1 million+ rows) since the article_id and store_id comprise the PRIMARY KEY – they’ll both be indexed.

You’ll just need to write your query so that it’s along the lines of:

UPDATE pricelist SET price = {$fNewPrice} 
WHERE article_id = {$iArticleId} 
AND store_id =` '{$sStoreId}'

Though you may want to consider converting the PRIMARY KEY in the store table (store.id – and therefore also pricelist.store_id in the pricelist table) to either an unsigned INT or something like CHAR(30).

Whilst VARCHAR is more efficient when it comes to disk space it has a couple of drawbacks:

1: MySQL isn’t too keen on updating VARCHAR values and it can make the indexes bloat a bit so you may need to occasionally run OPTIMIZE TABLE on it (I’ve found this on an order_header table before).

2: Any (MyISAM) table with non-fixed length fields (such as VARCHAR) will have to have a DYNAMIC row format which is slightly less efficient when it comes to querying it – there’s more information about that on this SO post: MySQL Row Format: Difference between fixed and dynamic?