Нормальные формы БД и практическая реализация

Давно хотел поштудировать Википедию по нормальным формам, так что начнем с таблицы товаров.

Сомнительный с первого взгляда стобец - дополнительные фото. Вы правильно подняли вопрос об атомарности. Если взять определение атомарности из википедии, то нам нужны ответы, потеряется ли смысл при любом переупорядочивании или разбиении любого значения данного столбца.
Переупорядочивание целиком зависит от того, важен ли порядок фотографий. Тут можно доказать потерю смысла, если, например мы на всем сайте мы показываем фотографии в следующим порядке: перед, зад, левая часть, правая, вид сверху, вид снизу (ну идеология у нас такая, что тут поделаешь) .
Что же подразумевает слово "разделение" - вопрос интересный. 100% можно было бы назвать разделением, если бы мы вынесли фото в отдельную таблицу (ИД Товара, Фото) . Но так, как нам нужно принять во внимание упорядоченность (иначе бы мы прокололись по первому пункту) , то придется таблицу приводить к виду "ИД Товара, порядковый номер (иначе не 1НФ) , фото". Не совсем уверен, можно ли это называть разделением, но все-таки склоняюсь к этому.
Так что лучше перестраховаться, однако (из английской википедии) Дэйт сказал, что "для термина Атомарность нет абсолютного определения ...столбцы любого мыслимого типа (от строк и чисел до массивов и табличных типов) применимы в таблице с 1НФ, хотя и не всегда являются предпочтительными".

Название товара. Если возможно наличие товаров, различающихся лишь расцветкой и она будет включена в название, то столбец "название" будет включать значение из двух соответствующих доменов, что является нарушением 1НФ. Нужно будет разбить на 2 столбца.

(Если есть разные расцветки) Цена, название товара, описание. Ключом в исходной таблице будет "Название товара, Расцветка". Фото, доп. фото будет зависеть от них (если для каждого цвета вы предлагаете разные фото) . Однако Цена и Описание будут, скорее всего, зависеть от потенциального ключа "Название", и это будет нарушением, но уже 2НФ, поскольку эти столбцы не будут попадать под определение "каждый неключевой атрибут неприводимо зависит от ее потенциального ключа".

Таблица заказов

Хех, интересный случай нам показывают столбцы списка идентификаторов и количеств. Если не хотите вступать в полемику с преподавателем, то смело разделяйте таблицу на две "Номер заказа, Дата" и "Номер заказа, ИД Товара, Количество".

С обоснованием немного сложнее. Любой столбец любой строки может содержать любое значение из соответствующего домена. Так как определить домен (именно как множество допустимых значений) "Количества" для любых строк не представляется возможным, в силу зависимости допустимости от значения столбца "Идентификаторы товаров", то могут существовать строки, которые не несут в себе никакого смысла. Поэтому в качестве домена можно лишь определить "Упорядоченная последовательность чисел, разделенных запятой". Соответствует ли в итоге отношение ("ИД Заказа", "Упорядоченный список идентификаторов товара", "Упорядоченная последовательность чисел", "Дата") вашим ожиданиям (особенно третий столбец) - решать вам ;)

Не работал ты с "числами через запятую". Это тоже самое, что и курить через жопу.

Отвратительно. Представьте, звонит клиент и говорит, что он хочет изменить заказ: убрать или добавить какие-то товары или изменить их количество. Вместо старого доброго SQL вы имеете геморрой с базой, к которой сложно будет что-нибудь пристроить без бубна и какой-то матери.

Не совсем правильно. Может для простоты так сделано. Но кривовато как-то. Список должен быть списком а не псевдосписком в виде строки с разделителями.

Если по существу: Это точно нарушение первой нормальной формы, так как идет перечисление значений. Скорость же можно повысить оптимизацией запроса в БД и далеко не факт, что твое собственноручное разбиение выполнится быстрее, чем это сделает отточенный код БД.

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