Так как никакого внятного описания структуры базы данных нет и вряд ли будет (всё-таки она меняется чуть ли не в каждой версии), попробуем немного сами поковырять её внутренности.
(Готовьтесь, будет критика)
При открытии БД видим несколько таблиц:
basis
beginning
end
entries
form
meaning
wlist
word
В таблице basis хранятся основы, в beginning - начала (не приставки), а в end - окончания слов. Зачем всё это хранится в БД не понятно, ведь по логике вещей эти вспомогательные для поиска элементы должны генерироваться при создании словаря TOM.dic, хранить их постоянно в БД нет смысла.
Далее идет таблица entries. И что же внутри? Ни за что не догадаетесь: там практически в готовом виде находится содержимое файла TOM.dic. Зачем, если всё это опять же должно генерироваться (и наверняка делает это) непосредственно перед созданием файла TOM.dic?
Далее (но не по порядку) мы заглянем в таблицу wlist. Вы действительно хотите знать, что там находится? Именно: там опять содержимое TOM.dic, при чём в не самом самом не оптимальном виде. Я даже скрин сейчас покажу:
Это таблица списков. Списки повторяются два раза: один раз текстом через точку с запятой, второй раз в полях. При этом полей 30. Тридцать полей. Во-первых, огромные расходы памяти. Во-вторых, что если значений будет 31? В-третьих, эта таблица должна генерироваться непосредственно перед созданием файла TOM.dic.
Ладно, самое страшное прошли. Давайте взглянем на нужные, но не менее избыточные, оставшиеся три таблицы.
Начнём с таблицы word. Тут хранятся слова. Эх, как я был бы рад, если бы это было действительно так. Но увы, кроме слов тут ещё и предлоги. Но предлоги это тоже слова, скажете вы. В концепции ТОМа - нет. Они имеют разную структуру. Так зачем же они в одной таблице - известно только автору. Могу лишь предположить, что словарь задумывался как набор словарных статей, и каждая статья может содержать не только описание слова, но и других объектов. Тогда почему в этой таблице только слова и предлоги, а классы и атрибуты - в другой?
Прокомментируем поля этой таблицы:
name - имя слова/предлога
main_form - основная форма? Зачем? Разве она у слова не вычисляется на основе ключа по умолчанию? А у предлога её в принципе не должно быть
fkey - ключ слова. Определён в БД как строка максимальной длиной 12 символов. А что, если ключ будет больше 6 кодов?
defkey - ключ по умолчанию (привет, основная форма). Тоже 12 символов. Ну тут-то точно встретится больше 6 кодов.
status - число, показывающее готовность описания слова. Если 100, то это слово попадает в файл TOM.dic
type - тип слова (verb, misc, pron, prep ...). Просто рудимент от базы данных, из которой брались слова. Не должен использоваться программой (я очень надеюсь на это).
frequency - частота "встречаемости" слова. Тоже рудимент.
code - код слова/предлога. Для слов содержит чистый код слова: имя, ключ, ключ по умолчанию, все формы слова... Всё то, что уже описано в других полях таблиц. То-есть опять-же избыточная информация. Для предлогов тут тоже описан чистый код, но без окончания. Уже не избыточен, т.к. элементы предлога не хранятся в других таблицах.
Cluster - без понятия что это, но похоже на что-то очень важное. Только не пойму на что.
obj_code - объектный код. Это код, который нельзя поместить в списки слова/предлога, но нужно засунуть в тело слова/предлога. Не избыточное поле.
glb_code - код, который, по видимому, как-бы добавляется в основной модуль программы при доступе к этому слову/предлогу. Встречается редко, но метко (убивает логический анализатор мозга практически сразу).
Дальше мы обязаны посмотреть таблицу form, т.к. она содержит формы слова. Да! Именно так и делается в БД, когда хотят сделать динамический список (а не описывают 30 статических полей).
Тут почти нет нареканий и непоняток. Почти. Но не будем останавливаться.
Последняя таблица - meaning. Это что-то мыслимое, значимое. Тут хранятся классы и атрибуты. Всё красиво, понятно и со смыслом. Исключение пожалуй - поля class_id, class2_id и class3_id. Опять-же, а что если кросс-класс состоит из 4-х классов?
Вот и подошло к концу моё критическое повествование. Прошу прощения, наболело.
Наверняка всё не так страшно, как я описал, и у всего есть какой-то смысл или логическое объяснение. Я бы и слова не сказал, если бы мне не пришлось разрабатывать что-то под этот формат. И ещё, я не настаиваю на полном изменении структуры БД, я лишь хочу разобраться как это работает, чтобы иметь возможность загружать и работать со стандартной библиотекой в своей среде разработки.
