Re: Performance Issue on Large Table

Am 23.02.2020 um 20:23 schrieb Richard Damon:

>> An amount of 140 tables in such a "BibleVersions.db" is not
>> uncommon and can be managed by SQLite in a good performance.
> 
> I'm not sure that form of division would be good. One basic rule of 
> database normalization is that you don't break-up data based on the 
> value of one of the fields ...

Sure, but FTS-"Tables" are in a "special category" (IMO)...

At least, I'd separate them "by language", because it does
not really make sense to me, to stuff e.g. the 31102 verses
of a japanese Bible-version into the same FTS-index,
where already one (or more) english versions reside.

Between japanese and english that's obvious already at the
"Unicode(Point)-level" - but even among "Latin-versions"
(e.g. english and german ones) there might be different
stemmer-algos to consider, to give optimal search-results.

Olaf

_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users