guest_20040621Я свои аргументы привел.Вы, видимо, называете аргументами следующие утверждения: guest_20040621Тогда это просто ошибочная точка зрения guest_20040621Вы делаете распространенную ошибку. guest_20040621 {ваше предложение}Абсолютно неактуально. guest_20040621У-у-у... напрасно Вы так. Этот пример еще хуже. ;)) guest_20040621У-у-у... все плохо. Снова бесполезный пример.

Пусть каждый судит сам, но мне набор подобных заявлений доказательным как-то не показался. На вполне резонный и конкретный пример Templar про ФИО вы ответили:
guest_20040621Я не телепат. Не сталкивался со структурой данных почтовых систем. Что и требовалось доказать.

Остальные ваши аргументы я уже рассмотрел в предыдущем посте. И выглядят они не лучшим образом. Ссылки на «опыт» не пойдут. Лично вас здесь никто не знает, опыт ваш никому из присутствующих не известен, даже регистрироваться на форуме вы почему-то не стали. А верить на слово, что у некой «маски» с ником guest_20040621 уж такой опыт, что всем опытам опыт...
А насчет красивых фраз «придется начинать со стандартов, метаданных, тезауруса» сразу вспоминается «я знаю карате, дзюдо и еще много страшных слов».
Знаете, как-то... хм, нехорошо после этого заявлять оппонентам, что у них «аргументы закончились», что «с ответными аргументами - как-то глуховато». Закончились у меня или Templarа аргументы, или не закончились, — ваши-то еще и не начинались. К сожалению, ваше любимое «У-у-у...» веским аргументом не выглядит.
guest_20040621Пожалуйста, продемонстрируйте, как будут меняться эти атрибуты (атомарность атрибутов) в зависимости от предметной области.
Рассмотрим один пример. Дата/время.
В одних случаях может использоваться как атомарный атрибут, в других желательно разбиение на дату и время, а иногда даже разбиение даты на год, месяц, день. Критерием является наличие/отсутствие необходимости постоянно оперировать частями даты (постоянные выборки по годам, по месяцам и т.д.).
Очевидно, что необходимость постоянно выполнять над датой операцию DATEPART не позволяет использовать индексы и сильно снижает производительность запросов. А если такие запросы составляют львиную долю работы, значит, рассматривать атрибут «дата/время» как атомарный нельзя, лучше разбить его на несколько атрибутов. Разумеется, это требует специальных мер по обеспечению корректности ввода/обновления, но это уже технические детали.
Таким образом, взгляд на «атомарность» даты/времени сильно меняется от задач системы. Пример системы с «атомарностью» — поле «дата рождения» в системе кадрового учета. Типовые операции — атомарное занесение, атомарное чтение, сравнение. Операции над частями даты редки или отсутствуют, над частью «время» — отсутствуют. Это и есть пример «огрубления» в модели. В реальном мире человек рождается в определенный час, минуту. Это время фиксируется в роддоме. А вот для кадрового учета этот аспект неважен — так и долой время рождения. Модель от этого не становится неадекватной, так как цель такой системы полностью достижима.
Пример систем с «неатомарностью» — производственные системы (часто как надстройки над АСУ ТП). Я этим лично занимаюсь. Данные поступают от датчиком и от ручного ввода потоком. Их надо прореживать. Виды отчетности по периодичности самые разные: за каждые два часа (двухчасовки), день, месяц, год, весь период. Операции выборки с условиями над отдельными частями даты и времени не исключение, а скорее правило.
И т.д.
Может, хватит спорить, Ясно же, что вы неправы, признайте честно. Зачем упорствовать?

guest_20040621P.S. Вы отметили, надеюсь, что я тактично проигнорировал Ваши хамские замечания и ответил исключительно по существу.
Дорогой вы мой человек! Не считаете ли вы хамство вот эти слова:
Мистер ВежливостьУ-у-у... дружище, начните, наконец, _изучать_ проектирование баз данных. Купите книжку, что-ли? Или репетитора наймите.
Раз вы первый перешли на такой тон, то и я позволил себе быть с вами... попроще. Впрочем, готов принести искренние извинения за некорректную фразу «Большего бреда я в жизни не видел». Переформулирую так:
Ваша мысль о том, что «есть атрибуты-идентификаторы, которые, конечно, абсолютно необязательно ключевые», мне кажется странной, нелогичной и требующей дополнительных разъяснений.

Programmer_OrtodoxА что будет, если вторичный ключ есть, а первичного нету?Вы о чем? Сформулируйте вопрос яснее, а то непонятно. Кстати, что такое "вторичный ключ"? Такого зверя я нигде не встречал. Полагаю, имеете в виду альтернативный ключ?