Разрушить правило атомарности, хранящее список предметов, когда нет причин запрашивать предметы? Таблица соединения стихов, которая требует сканирования всей таблицы соединения
Этот конкретный случай касается списков и предметов.
Один и тот же элемент может принадлежать нескольким спискам, и каждый список имеет много элементов.
Вариант A ("правильный" способ, насколько я понимаю): создать таблицу соединений, в которой есть list_ID и item_ID. Когда я хочу, чтобы все элементы в запросе списка для list_ID.
Вариант B (нарушить правило атомарности): создать таблицу списка. Первичный ключ и либо повторяющиеся столбцы, либо неатомарные столбцы. Насколько я понимаю, оба этих отклонения имеют одинаковые недостатки: невозможность неэффективного запроса по элементам.
Насколько я понимаю, нормализация базы данных к NF-1 будет гарантировать, что каждый столбец будет атомарным, поэтому я не должен делать вариант B. Причина в том, что затруднит запрос элементов. Например, "сколько этого предмета было продано" или "сколько раз этот предмет был в списке"
Я не думаю, что мне когда-нибудь понадобятся эти данные (это уже ошибка / распространенная ошибка? Есть ли среди опытных инженеров баз данных мем, например, "вы всегда захотите иметь возможность запрашивать, и у вас не будет времени реорганизовать базу данных при масштабировании "? Я переоцениваю, сколько времени потребуется MySQL для сканирования таблицы соединений?
Я не могу найти ничего, чтобы поддержать это, но в то же время я чувствую, что здравый смысл принимать эту несоответствующую форму, если я знаю, что недостаток не важен для приложения. Но я не эксперт, и эти правила были написаны экспертами.
1 ответ
TL; DR Если вы собираетесь писать общие выражения запроса / ограничения для частей значений столбца, то эти части должны получить свои собственные столбцы; в противном случае нет. Если вы передумаете, то можете предоставить старую схему через представление, хотя обычно обновления требуют перекодировки.
Отношения имеют строки, которые имеют для каждого столбца одно значение типа этого столбца. Понятия "отношение" или "нормализованный" или "1NF" в терминах некоторого понятия "атомарность" являются расплывчатыми, запутанными и бесполезными. Например, список обычно называется "неатомарным", а строка называется "атомарным" - даже если строка представляет собой список символов. Укусить пулю - это чепуха.
Каждый проект должен принимать решение о том, где стоит черепаха, о типах столбцов. Этого нельзя избежать. (Даже когда вы попадаете в столбец с битовой типизацией, вы можете решить, что отдельная таблица будет иметь только те строки, которые будут иметь 1 с.) (Тогда столбца нет, следовательно, нет типа столбца.) Это проблема качества проектирования, но не проблема нормализации к более высоким NFs (нормальные формы).
Ничто в "нормализации" к более высоким NF (уменьшение некоторых проблем обновления / избыточности путем замены таблицы таблицами, которые присоединяются к ней) не требует предварительной зависящей от приложения "нормализации" до "1NF" на "атомарность" (замена таблицы некоторой таблицей). (s) со столбцами для частей своих столбцов). Потому что, когда перестановка в "1NF" помогла бы, нам нужно было написать выражения ограничения, включающие части значений столбцов, так что мы все равно будем делать эту перестановку.
(К сожалению, "нормализованные" & "1NF" и "0NF" используются по-разному, многие бессмысленные, хотя и распространенные. Лучше просто сказать, какое именно свойство / свойства вы имеете в виду.)
PS 1 Список, как правило, считается упорядоченным набором элементов, а набор - неупорядоченным набором элементов. Предикат "коллекция C имеет элемент I в качестве N-го члена" записывает список, "коллекция C имеет элемент I в качестве члена" набор.
PS 2 PS Ваше предположение, что представление списка или установки "вертикально" или "компактно" "вниз" столбца в таблице включает в себя любое более "сканирование", чем представление "горизонтально" или "компактно" "через" значение в столбец подряд наивен / неоправдан. Т.е. ((список, элемент1, 1), (список, элемент2, 2), ...) vs (список, [элемент1, элемент2, ...]).