Ребята, привет всем!

Нужен ваш совет и помощь. Необходимо спроектировать базу данных mysql для словаря. Схема базы получается пока совершенно небольшой, но, так как нет опыта, сомнения в правильности проектирования не дают продвинуться дальше   Пытался читать Р. Яргер, Дж. Риз, Т. Кинг "MYSQL и MSQL Базы данных для небольших предприятий и интернета", сомнения развеяло несильно.

Итак, на простом примере базы данных словаря (отношение один ко многим):


Вопросы:
1. Как физически (на примере mysql) связать между собой две приведенные выше сущности?
2. Какую СУБД выбрать (MyISAM или InnoDB)?
3. Какие потенциальные проблемы вы можете спрогнозировать для такой БД на будущее (с ростом размеров БД и пр.)?
4. Какую доходчивую литературу для нубов почитать на тему проектирования и оптимизации баз данных?

Полагаю, ответить на вопросы для знатоков дела сложности не составит, а я был бы очень признателен за помощь. Заранее спасибо!

Это сообщение отредактировал(а) FiMa1 - 4.1.2010, 20:29

Похоже вопросы 1 и 2 сняты, кажется, наконец-то нашел толковое описание связывания таблиц MyISAM (InnoDB не поддерживает мой хостер).
Все еще интересуют ответы на вопросы 3 и 4...

Это сообщение отредактировал(а) FiMa1 - 5.1.2010, 00:41

Для начала, было бы неплохо объяснить, что за сущности Term и Dict. Мне например это не очевидно.

Я бы не стал хранить русский и английский вариант в одной строке таблицы... Для одного слова на русском могут существовать несколько эквивалентов на английском. Как собственно и наоборот...

FiMa1, объясни поподробнее.
Если я правильно понял, то поддерживаю Kesh, и такой же вопрос про синонимы и антонимы (к одному слову может быть несколько синонимов/антонимов)

Ребята, спасибо за участие!


А как правильно поступить? Для случая, когда одно слово имеет несколько вариантов перевода, пример приведен ниже - Вид содержимого таблицы "Cловарь1".

Для синонимов и антонимов решил создать отдельные таблицы, чтобы в основной таблице словаря не дублировать для одного и того же термина синонимы и антонимы. Потом, при поступлении запроса на перевод слова, например "dog", искать по таблицам синонимы и антонимы все совпадения для данного термина. Но не уверен наиболее ли это оптимальный вариант...

Структура таблицы "Список словарей в направлении En-Ru-En" (для каждого списка словарей по направлениям перевода создается отдельная таблица)

Вид содержимого таблицы "Список словарей в направлении En-Ru-En"

Структура таблицы "Словарь1" (для каждого словаря создается отдельная таблица)

Вид содержимого таблицы "Cловарь1"


Это сообщение отредактировал(а) FiMa1 - 15.1.2010, 11:42

Две (если есть поле язык) или три (для каждого сзыка своя) таблички, одна из табличек служит для связки слов.
например 

Таблица 1.
1 - rus - собака
2 - eng - dog
3 - rus - пес

Таблица 2.
re - 1 - 2
re - 3 - 2
er - 2 - 1
er - 2 - 3

re - rus -> eng
er - eng -> rus

А мой приведенный выше вариант в одной строке термин-перевод в чем проигрывает?

Это сообщение отредактировал(а) FiMa1 - 15.1.2010, 11:38

1. Как вы расширять французским будете? В моем варианте - новые записи, в вашем - изменение структуры таблиц.

2. А если вас надо добавить связки синонимов.
в Моем случае Таблица 2. записи

syn - 1 - 3
syn - 3 - 1

в вашем - изменение структуры бд

3. Ну и по размеру данных

Нее, без изменения структуры. Как описано выше, при добавлении нового направления перевода (напр. Fr-Ru-Fr) происходит:

•  создание пустой таблицы "Список словарей в направлении Fr-Ru-Fr";

При создании нового словаря в направлении Fr-Ru-Fr происходит:

•  добавление записи о словаре в таблицу "Список словарей в направлении Fr-Ru-Fr" (dictid, dictname, creatdate, comment);
•  создание таблицы для словаря (в последующем будет заполняться терминами)

Изменения структуры также не предполагается.

Поиск перевода термина:

•  получить направление перевода в котором ищет пользователь;
•  из таблицы "Список словарей в направлении XXX-Ru-XXX" получить список всех словарей (таблиц) из данного направления перевода;
•  искать по всем словарям (таблицам) указанного направления перевода все соответствия rus-XXX для заданного термина;
•  из таблицы "Синонимы" извлечь все совпадения для термина;
•  из таблицы "Антонимы" извлечь все совпадения для термина;

Пока не вижу из-за чего должна сильнее распухнуть база по сравнению с вашим предложением.
Единственное только, слово "dog", в моем случае, будет присутствовать и в таблице словаря и в таблицах синонимы и антонимы, это да, согласен.

Единственное, но очень весомое преимущество, которое я вижу для вашего предложения по сравнению с моим - это то, что в вашем случае соответствия термин-синоним, термин-антоним заданы численными id, по которым, насколько я знаю, поиск в базе будет осуществлен быстрее, чем поиск по id термина, представленному в текстовом виде. Хотя уверенности по всем пунктам, приведенным мной нет абсолютно   

Это сообщение отредактировал(а) FiMa1 - 15.1.2010, 12:04

создание таблицы (индексы, связи и т.д.) это уже изменение структуры БД.
Вариант, предложенный Kesh, достаточно хорош (можно конечно еще подумать).

весь вопрос в слове "сильно". 
Во-первых, посчитать сколько байт хранит целое и строка (в примере varchar(255)), то можно прикинуть разницу в объемах.
Во-вторых, никто не отменял нормализацию, если слово "dog" набрано с ошибкой и его нужно исправить, то придется делать update, который затронет много(в Вашем примере 2) записей в таблице и использованием неуникального индекса и с перестройкой его, а в примере Kesh update только 1 записи, причем по первичному ключу.
В-третьих, правильно подмечено, что поиск по integer будет в разы быстрее, чем поиск по varchar(...), причем, чем длиннее varchar и больше записей в таблице, тем больше integer будет выигрывать.

Ага, это я понял, спасибо!

Уже изменение структуры данных... А для работы с табличкой надо будет еще и програму подправить, чтобы она могла из этой новой таблицы читать.

Теперь смотрите, если у вас слово dog будет переводится на английский и французский, то у вас это слово будет сидеть во всех словарях (англо-русском и франко-русском), тут вставет проблема с тем, чтобы правильно занести дополнительную информацию даже к русскому слову. Что если в одном словаре одно описание, в другом - другое. Это уже некорректность в основных данных.

теперь синонимы антонимы... Создавая дополнительную таблицу вы потихоньку приближаетесь к тому, что предложил я. 

Взгляните на это с точки зрения сущностей. Слово у вас это одна сущьность. Язык на котором оно написано, его класс и т.п. - это его свойства. Логично все сущности хранить в одно таблице. (table1)

Перевод слова, его синонимы и антонимы - по сути это связи меду словами (сущностями) - принимаем связь за сущность (в ее тип: перевод, синонимия и т.п. за свойство) и вот у нас вторая табличка со связями. (table2)

Словари - тоже сущьности, которые характеризуются направлением перевода и содержат в себе набор сущьностей в виде слов и их переводов. Т.е. отдельная табличка для словарей (table3) и табличка включения слова в словарь (table4) (т.к. в одинаковых словарях могут быть одни и те же слова).  

Возможно также подключение связей слов в переводе (table2) к словарям(table3), если например вы хотите объявить, что в словаре содержатся не все возможные переводы слова, а только тематические. (table5)

Как только переварю и переосмыслю, составлю новый вариант таблиц и напишу чтобы показать, что получилось. Спасибо!

Думал, смотрел, появились вопросы:

ВОПРОС 1

А почему только запись в таблице 2 "Связи между словами (сущностями)"? А как насчет случая, если для слова "собака" нужно вести синоним "пёс", а "пса" в таблице 1 "Термины" еще нет по факту? Как построить такую связь?

Похоже, что syn - кандидат на добавление в таблицу 1 "Термины" в качестве "языка" (наравне с русским, английским и пр.). Тогда получим в таблице 1 запись:


А в таблице 2 в соответствие имеем:

Хотя это уже, по-моему, бред, но вот такой вопрос возник   ...

ВОПРОС 2

Эту фразу, честно, просто не понял. Можно чуть поподробнее, что имелось в виду, что значит "только тематические". Очень интересно.

Ну и, наконец, результаты моего творчества. Ребята, посмотрите, пожалуйста.

ЯЗЫКИ
1 – русский
2 – английский
3 – французский
…

ЧАСТИ РЕЧИ
1 – прилагательное
2 – наречие
3 – союз
4 – междометие
5 – числительное
6 – частица
7 – предлог
8 – существительное
9 – глагол
10 – порядковое числительное
11 – местоименное прилагательное
12 – местоименное наречие
13 – местоименное существительное
…



НАПРАВЛЕНИЯ ПЕРЕВОДА
1 – русско-английский
2 – русско-французский
3 – англо-французский
4 – англо-русский
…



В принципе уже видно, что Направление перевода дублируется, присутствует и в таблице TermsRelations и в таблице Dicts. Надо бы, видимо, откуда-то удалить (скорее всего из Dicts).

Это сообщение отредактировал(а) FiMa1 - 16.1.2010, 01:04