Структура базы данных 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) Создание одной таблицы с дополнительный столбец «тег» и маркировать все мои условия в зависимости от этого же словаря, а именно:

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

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

DictionaryType (DTId, DTName)

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

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

Затем ваши определения

DifinitionId, TermID, определение, DTId)

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

Answer 2

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

Там всегда есть «это зависит ...»

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

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

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

Answer 6

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

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

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

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

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

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

Answer 7

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

alt text http://img300.imageshack.us/img300/6550/worddict.png

Answer 8

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

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

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

Answer 9

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

Это говорит о том, что он отработал немного предоставленного; Я бы выбрал вариант №3.

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

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