Thanks for the answers. I'll definitely change the schema, adding new fields to
improve quality of results.
In the meanwhile I cannot throw away everything, because this is a production
project. What I'm worried about is the size of this text field (about 4/5MB for
each document). How can be
AFAIK your text field can be as big as your resources make possible.
The flip side is that, the bigger the field, the longer it'll take to
search, and more importantly return. If you plan on storing and returning
your entire 4/5 MB field, it is going to take you a lot of time. I mean A
LOT! For
Thanks Binoy for sharing your experience that's a good suggestion. Thank you so
much.
Ciao,
Vincenzo
--
mobile: 3498513251
skype: free.dev
> Il giorno 03 gen 2016, alle ore 14:02, Binoy Dalal
> ha scritto:
>
> AFAIK your text field can be as big as your resources
Sorry Upayavira, I didn't see your question. This collection is used to search
and retrieve the document if there is whatever matching query. I'm not sure if
the entire document is returned or if the big text field is used only to search
and return some ids, I have to investigate.
Ciao,
Ask yourself what you want out of the index, how you want to query it,
then the way to structure your index will become more clear.
What sort of queries do you need to execute?
Upayavira
On Sat, Jan 2, 2016, at 01:30 PM, Vincenzo D'Amore wrote:
> Hi All,
>
> Recently I have started to work on
Indexing the various columns of your database table as separate fields into
solr will allow for more flexibility in terms of filter queries, faceting
and sorting your results. If you're looking to implement such features then
you should definitely be indexing every table column as a separate solr
Hi All,
Recently I have started to work on an new project. I found a collection where
there are few documents (~8000), but each document has only a big text field
with about 4/5 MB.
As far as I understood the text field is created by copying all the text fields
existing into a mssql table.