Сохранение языкового словаря в MySQL: обработка нескольких определений

В настоящее время я перемещаю плоский файл базы данных в MySQL, и у меня возникли серьезные проблемы в отношении того, как правильно его структурировать. Цель состоит в том, чтобы найти японское слово и вывести определения в формате JSON.

Как я могу лучше всего представить эти данные в MySQL?

Структура плоского файла

Текущий плоский файл:
слово + [чтение *] / (глагол / существительное / прилагательное) / определение + / uid

Вот несколько примеров записей,

螠 (ок) [ゆ む し; ユ ム シ] / (n) (великобритания) ложка (особенно виды Urechis unicinctus) / EntL2265440 /

蠔油 (ОК) [ハ オ ユ ー] / (n) (obsc) (Великобритания) (см. オ イ ス タ ー ソ ー ス) устричный соус (chi: haoyou) / EntL2232860X /

袘 [ふ き] / (n) (obsc) перевернутый подол кимоно / EntL2566160 /

襅 (ок) [ち は や] / (n) (obsc) (великобритания) тонкие белые церемониальные хаори, носимые Мико / EntL2222620X /

跑 (ок) [だ く] / (n) (аббр) (см. 跑 足) рысь (как в верховой езде) / EntL2110610X /

踠 き (ОК) [も が き] / (n) (Великобритания) борьба / корчиться / извиваться / барахтаться / EntL2656220 /

Как видите, у некоторых слов много «чтений», у некоторых «типов».

Это может показаться странным, но в основном, поскольку целевой язык — японский, одно и то же «слово» может иметь несколько способов его написания, а также множественные или отсутствующие «чтения» (это не учитывается, если чтение совпадает со словом) и определения.

Сложность состоит в том, что слова могут быть одновременно глаголом или существительным среди других вещей. Я не могу использовать одно поле и просто выбрать один тип.

проблемы

Основная проблема здесь, конечно, нормализация базы данных. Стандартная идея состоит в том, чтобы создать таблицу для показаний и определений и связать их с основной таблицей «определений» с использованием внешнего ключа. Но это очень быстро выходит из-под контроля, если учесть, что в плоском файле есть много типов типов слов (это не только глаголы, существительные, прилагательные, но также идиомы, междометия и тому подобное) — должны ли они быть или их собственными таблицами или должны Я создаю 20 полей в каждой строке таблицы, например isVerb isAdjective? Кажется грязным

Часть меня просто хочет нарушить нормализацию и сохранить все английские определения в одном поле varchar … это так плохо?

Таким образом, всегда ли требуется нормализация? В такой ситуации с такой множественностью и множеством необязательных полей, что лучше всего сделать?

Может ли какой-нибудь гуру БД указать мне правильное направление?

0

Решение

Вы создаете один дополнительный types стол с word_type колонна и посторонняя на главную words Таблица.
Затем запись в words на таблицу могут ссылаться несколько строк в typesТаблица.

0

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]