Дизайн таблицы для SQL

Question

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

Предположим, у меня есть таблица с именем family_surname. Внутри этой таблицы может быть х количество членов семьи, скажем, от 2 человек до 22 человек. Как я могу ссылаться на family_members против family_surname?

Так я бы СЕМЬИ ФАМИЛИЯ Смит, Джонс, Браун, Тейлор, и т.д.

И тогда Смит может иметь 5 членов, где я хотел бы записать возраст, рост, вес , без разницы. У Джонса может быть 8 членов - он может варьироваться между семьями.

Я не хочу, чтобы «фамилия» была указана 8 раз для каждого члена - в идеале строка фамилии будет ссылаться (или как-то указывать) на соответствующую строку в другой таблице. И вот где у них проблемы!

Надеюсь, у меня есть смысл; как я говорю, им просто интересно, но я хотел бы знать, как это сделать с двумя таблицами.

В любом случае, спасибо за вашу помощь, я ценю это.

EDIT Спасибо вам, кто прокомментировал - конечно, полезную информацию здесь, которую я ценю. Я читаю и исследую некоторые биты SQL и peices, и пока это довольно хорошо. Еще раз спасибо, ребята!

Answer 1

Что вы спрашиваете, это вопрос о нормализации. Таблица будет выглядеть так:

Create table surname (
    SurnameID int, 
    Surname varchar(255) 
) 

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

Тем не менее, я не уверен, что фамилия - отличный кандидат для такого рода расщепления. Одной из причин нормализации данных является поддержание реляционной целостности. В этом случае это означает, что когда вы меняете «Смит» на «Джонс», все Смиты меняются сразу. Я не думаю, что это вызывает беспокойство в вашем случае.

Answer 2

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

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

В сценарии, который вы нарисовали, вы должны иметь таблицу лиц, которая имеет PersonId, FirstName, LastName. И, если нужно, отдельная таблица для хранения другой информации. Однако, поскольку человек может иметь только одну высоту, вес, возраст и т. Д., Они должны храниться в таблице «Лица».

Поэтому вам действительно нужен только один стол. Если вы не начнете получать телефонные номера, адреса и т. Д.

Answer 3

Разложение может быть сделано следующим образом

1. CREATE TABLE фамилии (INT ID, ФАМИЛИЯ VARCHAR2 (200))
2. CREATE TABLE детали (INT ID, FOREIGN KEY (SURNAME_ID) СПРАВОЧНЫЕ фамилии (ID) , PARAM1, param2 .....)

грубый эскиз разложения

Получить список атрибутов (ФАМИЛИЯ, PARAM1, param2, ....). на основе список атрибутов следующие ключи могут подразумеваться: 1. (ФАМИЛИЯ) 2. (PARAM1, param2 ...) отдельная таблица создается для каждого набора ключей

Answer 4

Я не делаю действительно хотите, чтобы «фамилия» была указана 8 раз для каждого члена

Почему? Получили ли вы на реалистичные объемы данных и определили, что это на самом деле проблема?

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

В самом деле, что вы предлагаете может быть очень плохая идея, по следующим причинам:

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