В настоящее время я перемещаю плоский файл базы данных в 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 … это так плохо?
Таким образом, всегда ли требуется нормализация? В такой ситуации с такой множественностью и множеством необязательных полей, что лучше всего сделать?
Может ли какой-нибудь гуру БД указать мне правильное направление?
Вы создаете один дополнительный types
стол с word_type
колонна и посторонняя на главную words
Таблица.
Затем запись в words
на таблицу могут ссылаться несколько строк в types
Таблица.
Других решений пока нет …