Secondary Indexes

There's an extension for that.

A key/value database, in and off itself, is not all that flexible. There are times when you need to find items based on criteria other than the key. That's where secondary indexes come in. A secondary index gives you access to the SQL tools you're used to, allowing you to create indexes on important properties, and to query those indexes to find the item(s) you need.

Extension options

There are multiple extensions that come with YapDatabase. It's important to understand what's available so that you can pick the best extension for the job.

• Views
• Full Text Search
• Secondary Indexes

There is some overlap in functionality between each of these extensions. For example, you could use a secondary index to index strings, and then perform searches on them. This is fine and well if you're searching for exact matches. But if you're doing google style searching for terms and such, then the full text search extension is better suited to your needs.

In a similar manner, there is overlap between views and secondary indexes. And this is important to understand:

• A view allows you to specify something similar to a SELECT clause (but with blocks), and gives you a sorted subset of your items. This makes it perfect for acting as the datasource for a table. Or any other kind of SELECT type query you need to access on a regular basis. Further, the view automatically updates as the database changes, and also pumps out change-sets which can be used to animate changes to a tableView.

• A secondary index gives you one or more indexes in SQLite, which can then be queried directly to find or enumerate matching items.

Your specific use cases will dictate which extension is a better match for your needs. Keep in mind that you can use both extensions simultaneously. In fact, you can have multiple views and multiple secondary indexes. So you can make these decisions on a per-need basis.

Understanding extensions

Extensions work seamlessly behind the scenes. You don't have to change the way you write objects to the database. Extensions automatically take part in the transaction architecture, and automatically update themselves as you make changes to the database.

The end result is that your extensions can come and go with ease. You can change your extensions around every build-and-go as you're developing. But the objects in your database stay the same. And, just as important, the code you have that inserts, deletes & updates objects in the database can stay the same.

For a deeper understanding of the extensions architecture, see the Extensions article.

Creating secondary indexes