Precalculate search scores with a table and a bunch of triggers #44
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The JLPT tags (if deduplicated by picking the lowest common level), are unique to each kanji and reading element. It is often used together with
baseScoreto order by commonness. Although storing a bunch of more NULLs would increase space consumption, it might speed up search a bit by having the jlpt score added into the precalculated score on these entries.This is not entirely correct. The JLPT tags are set per entry - not per reading/kanji. Need to figure out whether it's worth it to duplicate this data across the reading/kanji tables, or whether I should just make some sort of materialized view for storing query scores instead.
Consider moving JLPT tags to a column on `JMDict_{Kanji/Reading}Element`to Precalculate search scores with a table and a bunch of triggersRepurposing this issue, instead of moving all relevant factors into a single table (there might come more from different sources later), let's sum the numbers in a separate table with triggers.