Архитектура таблиц SQL

Question

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

example a. one table
productID productname weight no_of_pages
1         book        130     500
2         watch       50      null
3         ring        null    null

example b. three tables
productID productname
1         book       
2         watch      
3         ring       

productID weight
1         130   
2         50    

productID no_of_pages
1         500

Answer 1

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

Я предлагаю принять средний путь.Кажется, вес является свойством большинства продуктов, если не всех (действительно, кольцо имеет вес, даже если он маленький, и вы, вероятно, захотите узнать его для целей доставки), поэтому я бы оставил это в таблице «Продукты».Но количество страниц относится только к книге, как и множество других не упомянутых свойств (автор, ISBN и т. Д.).В этом примере я бы использовал таблицу Products и таблицу Books.Таблица книг будет расширять таблицу Продуктов способом, аналогичным наследованию классов в объектно-ориентированной программе.

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

Answer 2

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

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

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

Answer 3

Не зная фона (модель данных), невозможно определить, какой вариант является более «правильным». оба хороши в определенных сценариях.

Answer 4

Это зависит от того, сколько строк вы ожидаете в своей таблице PRODUCTS. Я бы сказал, что не имеет смысла нормализовать ваши таблицы до 3N в этом случае, потому что название продукта, вес и no_of_pages описывают продукты. Если бы у вас были повторяющиеся данные, такие как производители, было бы более разумно нормализовать ваши таблицы на этом этапе.

Answer 5

Я бы предложил пример a, если есть определенный набор атрибутов для продукта, и пример c, если вам нужно переменное количество атрибутов (новые атрибуты продолжают появляться время от времени) -

пример с

productID productName
1         book
2         watch
3         ring

attrID productID attrType    attrValue
1      1         weight      130
2      1         no_of_pages 500
3      2         weight      50

Структура таблицы, показанная в примере b, не нормализована - для второй и третьей таблиц требуются отдельные столбцы id, поскольку productId будет fk, а не pk.

Answer 6

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

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

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