Я раньше тоже так думал, попробовал рассказать про один из моих сайтов с белым и пушистым каталогом, начислили 7 баллов штрафа за рекламу, а сам рассказ почистили.
Проще реализовать, быстрее искать, экономится память, но их не всегда есть смысл использовать.
У меня написано "самим словам идентификаторы нужны только для восстановления текста из прямого индекса" причем для поисковой системы а не про общий случай.
Может Вы того, объясните что значит слово "нечитабельна" по поводу мысли, а то я такого слова в словаре не нашел.
Вы вечный двигатель еще случаем не изобрели?
Любой нормальный учебник по проектированию баз данных причем самое его начало, декомпозиция, нормальная форма Бойса-Кодда, нормализация, почитайте внимательно для чего все это делается.
Мне Ваша путеводная задача пока что даже слабо не ясна.
При неявных идентификаторах слов система получается простой что хорошо для скорости и памяти но очень жесткой, и если например надо обновлять словарь для поисковой системы то придется обновлять его связь с инвертированным индексом, в отличии от случая когда идентификаторы слов явные и используются как указатели на инвертированный индекс то есть являются идентификаторами частей инвертированного индекса для слов, а самим словам идентификаторы нужны только для восстановления текста из прямого индекса но возможно проще хранить сам текст, то есть неявные идентификаторы слов есть смысл применять только в том случае когда словарь не планируется часто обновлять или можно обойтись обновлением отдельного малого словаря пользователя.
Все это написано в учебниках, а для Вашей задачи для начала было бы полезно точно ее задать и уже потом думать как ее решать, здесь много важных переменных которые влияют на выбор алгоритмов и их применение.
Все зависит от точной постановки задачи, можно вообще обойтись без явных идентификаторов и вместо них использовать номера слов в массивах отдельно для каждой длины слова.
@---,---`-----
Массивов может быть несколько для каждой длины слова отдельно что позволит как лучше использовать память при этом ускоряя поиск и обновление так возможно и обойтись 16 бит идентификаторами для слов при этом используя длину слова в качестве неявного расширения пространства идентификаторов. А если для Вашей задачи достаточно скорости последовательного поиска то словарь можно даже сжать причем намного плотнее чем обычный текст.
И при этом использовать двоичный поиск в массиве без всякого хэширования.
2^19 = 524288
То есть за 20 простых сравнений слово будет найдено что быстрее чем вычислить хэш функцию и потом разбираться с совпадениями.
Действительно, зачем все это городить? Если Вы уточните задачу то возможно еще идеи появятся.
Я и не старался быть понятным. А по теме можно вспомнить о том что великий Кнут явно пишет о непригодности чистого хэширования для серьезных задач потому что у этого способа индексации очень плохая производительность в наихудшем случае. Возможно что то что предлагает euhenio по поводу дополнения хэширования деревом будет оптимальным решением. Только я бы хэшировал не часть слова а все слово полностью чем нибудь типа md5 для лучшего распределения при этом не обращая внимания на совпадения и брал бы столько бит что их бы хватило на хэширование без совпадений при идеальном случае то есть дерево было бы только страховкой для наихудшего случая при совпадениях.
