>If I a tables primary key is (username, title, start_date)...I'm guessing it
>will create an index on (username, title, start_date).

Correct.

>If I'm querying by username, start_date, will it still use the index OR
>do I need to add an extra index for username, start_date)?

It will probably use the index, but can only use it for username, since title is before start_date in the index, no index will be used to find the start_date. Generally, what I'd rather recommend, would be to add another field with no meaning except being the primary key. Then you can add a unique constraint for username, title and start_date, and create separate indexes for title and start_date (I assume they're going to be rather selective).

Today it might seem to you to be a good idea to have these three fields as a primary key. If you can guarantee that these fields will never change, then this might be fair enough as long as you don't use them as foreign keys anywhere (there's no reason to repeat these three fields in other tables). However, if there is a chance that things may change - e.g. the length of the username or title may change - or you might in the future get into the situation where username, title and start_date isn't unique, then think about what changes that would demand in your database, and preferrably try do the changes on a test database to ascertain that Firebird allows you to do that. Often, I think changing fields is easier if they're not part of primary keys.

Of couse, I've no idea about the complexity or size of your database. If it is a small and simple database, it might not matter too much how you implement things.

HTH,
Set