Структура базы данных MySQL: больше столбцов или больше строк?

Question

Я создаю онлайн-словарь, и для этого мне нужно использовать три разных словаря: повседневные термины, химические термины, компьютерные термины. У меня есть варианты дерева:

1) Создайте три разные таблицы, по одной таблице для каждого словаря

2) Создать одну таблицу с дополнительными столбцами, т. Е .:

id    term    dic_1_definition    dic_2_definition    dic_3_definition
----------------------------------------------------------------------
1     term1   definition
----------------------------------------------------------------------
2     term2                       definition
----------------------------------------------------------------------
3     term3                                           definition
----------------------------------------------------------------------
4     term4                       definition
----------------------------------------------------------------------
5     term5   definition                              definition
----------------------------------------------------------------------
etc.

3) Создайте одну таблицу с дополнительным столбцом «tag» и пометьте все мои термины в зависимости от словаря, т.е.

id    term     definition    tag
------------------------------------
1     term1    definition    dic_1
2     term2    definition    dic_2
3     term3    definition    dic_3
4     term4    definition    dic_2
5     term1    definition    dic_2
etc.

Термин может относиться к одному или нескольким словарям, но иметь разные определения, скажем, термин в повседневном использовании может отличаться от того же термина в области ИТ. Вот почему таблице term1 (в моей последней) можно присвоить два тега - dic_1 (id 1) и dic_2 (id 5).

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

Какой вариант является лучшим в моем случае? Какой из них быстрее? Зачем? Будем благодарны за любые предложения и другие варианты.

Спасибо.

Answer 1

2) Создать одну таблицу с дополнительным столбцом

Вы определенно не должны использовать второй подход. Что если в будущем вы решите, что хотите 10 словарей? Вы должны были бы создать дополнительные 10 столбцов, что является безумием.

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

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

Answer 2

Я думаю, у вас должна быть таблица соответствия для ваших типов словарей

DictionaryType (DTId, DTName)

Есть еще одна таблица для вас условия

Условия (TermID, TermName)

Тогда ваши определения

Различия (DifinitionId, TermID, Definition, DTId)

Это должно сработать.

Answer 3

Я разработал аналогичный проект, и мой дизайн был следующим. Хранение слов, определений и словарей в разных таблицах - это гибкий выбор, особенно если вы добавите новые словари в будущем.

альтернативный текст http://img300.imageshack.us/img300/6550/worddict.png

Answer 4

Вариант 3 звучит как наиболее подходящий выбор для вашего сценария. Это делает запросы немного проще и определенно более удобными в долгосрочной перспективе.

Вариант 2 определенно не подходит, потому что вы получите множество нулевых значений, и написание запросов к такой таблице станет кошмаром.

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

Таким образом, вариант 3 приведет к простым запросам, таким как:

Select term, definition from table where tag = 'dic_1'

Вы можете даже создать другую таблицу тегов для хранения информации о самих тегах.

Answer 5

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

Вариант 1 требует изменения базы данных и переписывания запросов с целью добавления новых словарей. Это также добавляет излишнюю сложность простым запросам, таким как «в каких словарях есть это слово?»

Вариант 3 Самый гибкий и лучший выбор здесь. Если ваши данные становятся слишком большими, вы можете в конечном итоге использовать такие детали БД, как разбиение таблиц, чтобы ускорить процесс.

Answer 6

Вы хотите получать данные на основе типа словаря, это означает, что типом словаря являются данные.

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

Первый вариант использует тип словаря в качестве имен таблиц.

Второй вариант использует тип словаря в качестве имени поля.

Третий вариант правильно размещает тип словаря как данные в поле.

Однако термин и тег не должны быть строками, они должны быть внешними ключами таблиц, в которых определены термины и типы словарей.

Answer 7

Всегда есть "это зависит ..."

Сказав это, вариант 2 обычно будет плохим выбором - как с точки зрения пуристов (нормализация данных), так и с практической точки зрения - вы должны изменить определение таблицы, чтобы добавить новый словарь (или удалить старый)

Если ваш основной доступ всегда будет искать подходящий термин, а имя словаря («повседневный», «химический», «гик») является атрибутом, то вариант 3 имеет смысл.

Если, с другой стороны, ваш доступ всегда в основном по типу словаря, а также по термину, и словарь 1 огромен, но редко используется, в то время как словари 2..n малы, но широко используются, тогда вариант 1 может иметь больше смысла ( или вариант 1a => 1 таблица для редко используемых словарей, другая для интенсивно используемых словарей) ... это очень гипотетический случай!

Answer 8

Нормализация данных. Я бы пошел с 3, тогда вам не нужно делать какие-то причудливые запросы, чтобы определить, сколько определений применимо для данного термина

Answer 9

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

Тем не менее, отработать мало обеспеченного; Я бы пошел с вариацией на # 3.

• Номер 1 вполне жизнеспособен, если словари будут использоваться совершенно независимо, и единственная причина, по которой была упомянута концепция общих терминов, заключается в том, что это просто случайная возможность.
• Кювет 2; излишне приводит к значениям NULL в столбцах, и дизайн БД не нравится.
• Номер 3 самый лучший, но угробите искусственный ключ и ключ на Term + Tag. Помимо искусственного ключа создается возможность дублирования записей (по Term + Tag). Если никакие другие таблицы не ссылаются на TermDefinitions, ключ является пустой тратой; если что-то делает; затем они говорят (например) «Я ссылаюсь на TermDefinition # 3 ... Хм, что бы это ни было.: S»

В двух словах, ничто из приведенного в требовании ничего не говорит о необходимости более сложного, чем вариант 3.