CODEWITHSUNDEEP
azure-cognitive-search
Guillaume Morin
Guillaume Morin

Reputation: 4010

Azure Search Index field Id an Name

First I want to say that the concept of a dedicated search engine is all new to me, so please be indulgent :-)

How does a transactional database entity with an Id and a Name does translate into an Azure Search Index field ? Should we add only Name, or both Id and Name ?

For example, let's say I want the Client in my index. I want both to search and have facets on Client.

Should I add only ClientName into the index ? What if ClientName is renammed ? What if ClientName is not unique ?

Should I add both fields into the index and have:

I understand having ClientId Facetable (instead of ClientName) will make it more work to show the facets since i'll have to fetch myself the names corresponding the the ClientId returned by Azure Search.

Also, having the ClientId Filterable, I assume it would allow me to perform a batch rename of ClientName.

Is my reasoning ok ?

Is there any best practices / guidelines ?

EDIT

Here is a more concrete example. Let say that in the transactional db, we have tables with Id and Name for Format, Location, Author, Genre, Region, ...

If we were to build those facets in Azure Search, would the recommended approach be to add both the Id and Name for each of them, and set the Id field as Facetable ? enter image description here

Upvotes: 1

Views: 1436

Answers (1)

Eugene Shvets
Eugene Shvets

Reputation: 4671

It's probably a good idea to add both Id and Name, since potentially Name can change. Also, the Name field can contain arbitrary characters, while document id can only contain alphanumeric characters, dashes, underscores and equal signs (see Naming Rules).

Only id field must be unique (it has the same semantics as the primary key in a relational database). All other fields can have non-unique values. If a value changes, you just update the document (using merge or mergeOrUpload indexing action).

Azure Search supports batches of up to 1000 documents. If you want to update more documents than that, you'll have to break your updates into multiple batches. See Indexing API. The links shows REST API, but of course the same functionality is available in .NET SDK, if you're on .NET.

Should I add both fields into the index and have: ClientName: Searchable ClientId: Facetable, Filterable I understand having ClientId Facetable (instead of ClientName) will make it more work to show the facets since i'll have to fetch myself the names corresponding the the ClientId returned by Azure Search.

We do not recommend making ClientId facetable. Facets work best on fields with a relatively small number of unique values. Since ClientId by definition must be unique, faceting will not be useful and any faceting queries that reference ClientId will probably perform poorly if you have many documents in your index. It is reasonable to make ClientId filterable though, since there may be situations when you want to retrieve or exclude certain documents by ClientId.

Also, having the ClientId Filterable, I assume it would allow me to perform a batch rename of ClientName.

This is not necessary. Making ClientId filterable allows you to filter by ClientId, nothing more. You always need to specify document IDs when updating fields using the Index API, but that doesn't require the ID field to be filterable.

I hope this gets you started, and as you have more specific questions, you can post them here.

Upvotes: 3

Related Questions