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

Question

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

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

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

Answer 1

Normal forms что вас должно заинтересует. Они в значительной степени являются конвенцией для построения таблиц.

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

Answer 2

Это называется Database Normalization

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

Answer 3

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

Answer 4

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

Answer 5

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

E.g.

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

Planet 
    Population 

Comet 
    Speed 

Плохие столбцы, которые я знаю. Примените таблицы Planet и Comet к общим данным с помощью ключа.

Answer 6

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

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

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

Answer 7

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

How do you store business activities in a SQL database?

Answer 8

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

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

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

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

Answer 9

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