You don’t necessarily want to ditch your database if it doesn’t automatically create a primary index. For example. if you have a bulk load of millions of rows to perform then adding the data first and creating the index after the load will typically be quicker than creating the index as the data is added.

Much depends on the indexing and the data access patterns. The classic order line actually represents a may-to-many relationship between order and product, with a primary key of (orderID, productID). If you build an index on the primary key that’s great for looking up the products for a particular order, but doesn’t help if you want to know about all the orders for a particular product.

In that case, a separate index on the productID foreign key would be exactly what you’d need, but no additional index would be needed on orderID because the primary key index would serve (since orderID is the dominant column). Andrew’s advice is sound because it implies specific lookup patterns.

So, as is so often the case in the database world, you can’t be too dogmatic about what’s right for a specific application without measuring performance under real application load. That’s why it’s a good thing to have a DBA who can do the performance measurement and tune the physical model long after the logical model designers have moved on to the next project. The line number isn’t that relevant in most cases, though you are correct that a separate index that allowed you to locate all the line ones wouldn’t be useful, and in fact not all order processing systems bother to number the lines.

In MS SQL Server, (Since SQL Server 2000) the query optimizer will usually aggregate separately indexed columns for you and take advantage of them as if they were composite indexes. So, at least in that RDBMS, the idea of _having_ to have composite keys is not so relevant.

I am not sure about MYSQL, PostgreSQL and Oracle as I primarily work in MSSQL.

Just thought you might want to know.

Cheers.

G. D. Milner
Portland, OR

Seriously, if you have multi-column primary keys, you want one index on all columns. So the classic “order line” table would have one index of “order_no, line_no”. Having a separate index on line_no is probably unhelpful.