Question

I have an OLTP application with three tables

Item Table - ItemId, CategoryId, AgeGroupId, ... 100K rows. 

CategoryTable - CategoryId, ...  (only 5-10 rows)
AgeGroupTable - AgeGroupId, ...  (only 4-5 rows) 

What is appropriate index for CategoryId and AgeGroupId for Item table? It would be nice to query items by Category or Agegroup or both of them!

I was thinking that a bitmap index might work due to low cardinality, but I don’t know how exactly they work with multiple bitmap indexes per table? How would horizontal partitioning help, if at all?

Answer 1

Since this is an OLTP application, you almost certainly don’t want to use a bitmap index. Bitmap indexes tend not to work well with OLTP applications. They tend to grow in size very rapidly when you do a lot of single-row operations on the data (though this effect is lessened in more recent versions). But more importantly, the locking impact tends to radically reduce the scalability of an application. If you had a bitmap index on CategoryID, for example, updating a single row’s CategoryID would effectively require locking every row in the table that has a CategoryID of either the source or target value.

It sounds like, at most, you need composite indexes on (AgeGroupID, CategoryID) and (CategoryID, AgeGroupID). Potentially, you could use just the composite index on (AgeGroupID, CategoryID) and let Oracle use an index skip scan if only CategoryID is specified. It depends on the trade-offs you want to make– multiple indexes will make queries just on CategoryID more efficient at the expense of additional index maintenance on DML operations and additional disk space usage.

Are you licensed to use partitioning? That is an extra cost option on top of the enterprise edition license. Potentially, I suppose, you could partition the table. A table with just 100,000 rows is pretty small to consider partitioning, though. And whatever you partition by would tend to make queries that don’t use the partition key less efficient. That might make sense if you know that queries that specify AgeGroupID are much more common than CategoryID (or vice versa) but that doesn’t sound like what you are describing.