Как вы знаете, когда вам нужны отдельные таблицы?

Question

Как узнать, когда создавать новую таблицу для очень похожих типов объектов?

Пример:
Чтобы узнать MySQL, я строю модель солнечной системы. Для целей моего проекта планеты имеют много схожих атрибутов с планетами-карликами, кентаврами и кометами. Карликовые планеты почти полностью идентичны планетам. Кентавры и кометы отличаются только от планет, потому что их орбитальный путь имеет больше вариаций. Должен ли я иметь отдельную таблицу для каждого типа объектов или они должны совместно использовать таблицы?

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

Answer 1

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

Любой дизайн, который не нарушает нормальную форму первый , второй или третий , меня устраивает. Это довольно длинный список требований, поэтому я предлагаю вам прочитать его по ссылкам в Википедии выше.

Answer 2

Это зависит от того, какую информацию вы хотите хранить об объектах. Если информация для всех них одинакова, скажем, радиус орбиты, масса и имя, то вы можете использовать ту же таблицу. Однако, если для каждого существуют разные свойства (например, состав атмосферы для планет и т. Д.), Вы можете использовать отдельные таблицы для каждого (не очень нормализованные) или иметь одну таблицу для основных свойств, таких как орбита, масса и имя, и вторую таблицу только для свойств, которые являются уникальными для планет (и аналогичная таблица для комет и т. д. при необходимости). Все объекты будут в первой таблице, но только планеты будут во второй таблице и связаны через внешний ключ с первой таблицей.

Answer 3

Это определенно субъективный вопрос. Похоже, вы уже на правильном пути мышления. Я бы спросил:

1. У этих объектов много атрибутов? Если это так, то, вероятно, стоит рассмотреть хотя бы базовую таблицу, чтобы перечислить их все.
2. Один объект "расширяет" другой - у него есть все атрибуты другого, плюс некоторые дополнения? Если это так, возможно, стоит добавить еще одну таблицу с дополнительными атрибутами и однозначное сопоставление с базовым объектом.
3. У обоих объектов много общих атрибутов и общих атрибутов? Если это так, возможно, вам нужна отдельная таблица плюс система «расширения данных», в которой каждый объект может иметь тип или категорию, которые определяют любое количество дополнительных атрибутов, которые могут быть связаны с ним.
4. Имеют ли объекты только один или два атрибута? В этом случае они, вероятно, достаточно различны для разделения на несколько таблиц.

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

Answer 4

Скорее всего, вам следует разделить данные о планете и т. Д., Чтобы общая (общая) информация была в другой таблице.

* 1003 Е.Г. *

Common (Table)
  Diameter (Column)
  Mass (Column)

Planet
  Population

Comet
  Speed

Бедные столбцы, которые я знаю. Сделайте так, чтобы таблицы Planet и Comet связывались с Общими данными с ключом.

Answer 5

Это называется Нормализация базы данных

Есть много нормальных форм. Применяя нормализацию, вы будете просматривать метаданные (таблицы) и более четко изучать отношения между данными. Используя методы нормализации, вы оптимизируете таблицы для предотвращения избыточности. Этот процесс поможет вам понять, какие сущности создавать на основе отношений между различными полями.

Answer 6

Возможно, у меня есть таблица с названием [HeavenlyBodies] или что-то подобное. Затем найдите таблицу с указанием типа тела, например, планеты, кометы, астероида, звезды и т. Д. У всех будут сходные вещи, такие как имя, размер, вес. Большинство ответов, которые я прочитал до сих пор, имеют хороший совет. Нормализация - это хорошо, но я чувствую, что иногда ты можешь зайти слишком далеко. 3-й нормальный - хорошая цель.

Answer 7

Есть много разных способов выразить наследование в вашей реляционной модели. Например, вы можете попытаться объединить все в одну таблицу и иметь поле, которое позволяет вам различать различные типы, или иметь одну таблицу для общих атрибутов с отношениями к дочерней таблице с конкретными атрибутами и т. Д. ... в любом выборе вы все еще храните ту же информацию. При переходе от доменной модели к реляционной модели это называется несоответствием импеданса. Оба варианта имеют разные компромиссы, например, к одной таблице будет проще запрашивать, но у нескольких таблиц будет более высокая плотность данных.

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

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

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

Answer 8

Вот мой ответ на аналогичный вопрос, который, я думаю, применим и здесь:

Как хранить бизнес-операции в базе данных SQL?

Answer 9

Если вы когда-нибудь захотите получить планеты и кометы в одном запросе, они должны быть в одной таблице, если вы хотите, чтобы база данных работала эффективно.Наследование должно быть обработано внутри самого приложения:)