Cane Cat FisherNekifrovvВсем большое спасибо за ответы, победил второй вариант. Посмотрим, как он покажет себя в действии.

Добро пожаловать в мир EAV. Для примера, простейший запрос: "Выбрать квартиры, где есть холодильник и стиралка, но нет ни мебели, ни микроволновки". Составьте для первого и второго варианта, сравните.
А Вы, в свою очередь, составьте этот запрос для совершенно правильного Вашего варианта из
15013211
который Вы ошибочно раскритиковали - 1НФ в нем не нарушается никак. И даже после того, как добавят материальный учет, так сказать (конечно, клиентов будет интересовать объем холодильника), то это (тогда - уже вычисляемое) поле вполне может использоваться.
Второй вариант не имеет вообще никакого отношения к БД.

NekifrovvВсем большое спасибо за ответы, победил второй вариант. Посмотрим, как он покажет себя в действии.
То есть, Вы решили просто отказаться от БД. И правильно))

Cane Cat FisherТеперь по примерам:
...
Последний - опять пританцевали к первому варианту: теоретически, как я только что сказал, они равнозначны, отличаются только реализацией. Нарушение 1НФ - значение поля имеет внутреннюю структуру- информацию, важную для задачи, но недоступную как ОТНОШЕНИЕ.АТРИБУТ. Функция LIKE в каноническом числе реляционных операндов не значится.
Это не убедительная интерпретация)) 1НФ нарушают не только дата или, например, номер телефона, но и та же фамилия: например, первая буква имеет особое значение, по ней фамилия относится к разделу каталога. Поэтому, чтобы не нарушать 1НФ фамилию нужно хранить в двух полях: "П" и "етров". Впрочем, со второй та же история))
Другими словами, реляционная теория должна быть как-то доработана, чтобы появился какой-то смысл)) Это, конечно, не поможет создать реляционную СУБД, но, хотя бы в теории.

vadiminfoБредятина например, первая буква имеет особое значение, по ней фамилия относится к разделу каталога. Поэтому, чтобы не нарушать 1НФ фамилию нужно хранить в двух полях: "П" и "етров"..
Знатоки подвалили. Чувствуется уровень проетирования за версту. Тока забыли выдумать что значитЬ "етров". (Все таки 1НФ азначент атомарное , а не части атомарного же). Ну это уже детали.
Подвалили знатоки лжи и подлога))) Вот мой текст:

Это не убедительная интерпретация)) 1НФ нарушают не только дата или, например, номер телефона, но и та же фамилия: например, первая буква имеет особое значение, по ней фамилия относится к разделу каталога. Поэтому, чтобы не нарушать 1НФ фамилию нужно хранить в двух полях: "П" и "етров". Впрочем, со второй та же история))
Другими словами, реляционная теория должна быть как-то доработана, чтобы появился какой-то смысл)) Это, конечно, не поможет создать реляционную СУБД, но, хотя бы в теории.

"етров" - это часть фамилии со второй буквы до последней - это смог бы сформулировать даже первоклассник))

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

vadiminfoЭта ахинея возможно превосходит все что было от ЧАЛа до сих пор. Наверное, дальнейшая нармолизация по ЧАЛу приведет к разбиениб "П" на три палки.
...
Заднюю часть надо полагать. ЧАЛ слышал, наверное, звон что в РМД запрос всегда возвращает отношение (что есть следствие алгебры, а не принципов БД), и типа додумал по своему, по деревенски С "частями".
Это не убедительная интерпретация)) 1НФ нарушают не только дата или, например, номер телефона, но и та же фамилия: например, первая буква имеет особое значение, по ней фамилия относится к разделу каталога. Поэтому, чтобы не нарушать 1НФ фамилию нужно хранить в двух полях: "П" и "етров". Впрочем, со второй та же история))
Другими словами, реляционная теория должна быть как-то доработана, чтобы появился какой-то смысл)) Это, конечно, не поможет создать реляционную СУБД, но, хотя бы в теории.
Что касается того известного факта, что любой запрос к БД (а не последующие вычисления в целях вольных интепретаций результата запроса) представляет собой часть БД со всей присущей БД семантикой, так это один из ключевых принципов БД. А известный факт, что в "реляционных системах" этот принцип не поддерживается из-за известных непреодолимах ограничений РМД, приводит к неизбежному хамству по отношению ко всем, кто об этом факте напоминает. Это вполне нормальная привычка вести обсуждение по принципу "поквакали - и в болото"))
13254920
13545785
13577413
13755686
14020991
14026626
--
Лет 5 назад я был убежденным оптимистом - искренне полагал, что местные "знатоки РМД" понимают о чем идет речь, но специально, из чувства самозащиты, скрывают это. Но, теперь я убежденный пессимист - уверен, что искренне не понимают)) Например, сейчас vadiminfo искренне не понимает, что мое сообщение - о том что 110101 не нарушает 1НФ, а не о том, что нужно разделить фамилию на число полей, равное числу букв))

tanglirvadiminfoпропущено...

Эта ахинея возможно превосходит все что было от ЧАЛа до сих пор. Наверное, дальнейшая нармолизация по ЧАЛу приведет к разбиениб "П" на три палки.Зачем углубляться в такие дебри? :) Можно ведь поступить логичнее - если уж мы выделили первую букву, то дальше надо выделить вторую ("е" в данном случае) и хранить фамилию в трёх полях. Потом выделить третью и хранить в четырёх. Ну и так далее...
Вам, вероятно, тоже лень читать сообщения))
"Это не убедительная интерпретация)) 1НФ нарушают не только дата или, например, номер телефона, но и та же фамилия: например, первая буква имеет особое значение, по ней фамилия относится к разделу каталога. Поэтому, чтобы не нарушать 1НФ фамилию нужно хранить в двух полях: "П" и "етров". Впрочем, со второй та же история))"

vadiminfoБредятинаЭто не убедительная интерпретация))

Это не интерпретация, просто блестящее подтверждение ранее нами с Вами принципа БД:

БредятинаДо таких идиотов, как я, конечно, не доходит))
Хорошо, что Вы конструктивно участвуете в диалоге. Диалог - хорошая форма понимания учебного материала. Но, все-таки, эта Ваша интерпретация не убедительна)) 1НФ нарушают не только дата или, например, номер телефона, но и та же фамилия: например, первая буква имеет особое значение, по ней фамилия относится к разделу каталога. Поэтому, чтобы не нарушать 1НФ фамилию нужно хранить в двух полях: "П" и "етров". Впрочем, со второй та же история))
Другими словами, реляционная теория должна быть как-то доработана, чтобы появился какой-то смысл)) Это, конечно, не поможет создать реляционную СУБД, но, хотя бы в теории.
Что касается того известного факта, что любой запрос к БД (а не последующие вычисления в целях вольных интепретаций результата запроса) представляет собой часть БД со всей присущей БД семантикой, так это один из ключевых принципов БД. А известный факт, что в "реляционных системах" этот принцип не поддерживается из-за известных непреодолимах ограничений РМД, приводит к неизбежному хамству по отношению ко всем, кто об этом факте напоминает. Это вполне нормальная привычка вести обсуждение по принципу "поквакали - и в болото"))
13254920
13545785
13577413
13755686
14020991
14026626
--
Похоже, Вы искренне не понимаете, что мое сообщение - о том что 110101 не нарушает 1НФ, а не о том, что нужно разделить фамилию на число полей, равное числу букв))

То есть, никто не понимает, что мое сообщение - о том что 110101 не нарушает 1НФ, а не о том, что нужно каким-либо образом разделить фамилию)) Или "проблема фамилии" действительно так важна?))

Гость333БредятинаТо есть, никто не понимает, что мое сообщение - о том что 110101 не нарушает 1НФ, а не о том, что нужно каким-либо образом разделить фамилию))
Ну, я уловил.
Предположим, что я DBD от сохи, руководствуюсь своим здравым смыслом, в дебри реляционной теории углубляться не хочу.
Вот что нашлось в википедии:
Первая нормальная формаВопрос об атомарности атрибутов решается на основе семантики данных, то есть их смыслового значения. Атрибут атомарен, если его значение теряет смысл при любом разбиении на части или переупорядочивании. Следовательно, если какой-либо способ разбиения на части не лишает атрибут смысла, то атрибут неатомарен.

Одно и то же значение может быть атомарным или неатомарным в зависимости от смысла этого значения. Например, значение «4286» является
атомарным, если его смысл — «пин-код кредитной карты» (при разбиении на части или переупорядочивании смысл теряется)
неатомарным, если его смысл — «набор цифр» (при разбиении на части или переупорядочивании смысл не теряется)
То, что здесь написано, правильно? Если да, то согласно какой семантике "110101" является атомарным атрибутом? Согласно какой семантике разбиение "110101" на части лишит этот атрибут смысла?
Совокупность бытовых устройств в квартире.
Справочник значений (код и описание):
А (или 1000, что имеет тот же смысл, что и А) - есть холодильник, нет стиральной машины, телевизора и радио.
Б (или 1100, что имеет тот же смысл, что и Б) - есть холодильник и стиральная машина, но нет телевизора и радио.
....
"при разбиении на части или переупорядочивании смысл теряется")) Разумеется, кажется, что 1000 можно разбить на части, в отличие от А, а на самом деле нельзя, потому что 1000 имеет тот же смысл , что и А, но другое , более наглядное, представление этого смысла . Сравните с представлениями телефонного номера (+74951000000 и +7 (495) 100-00-00) или даты (20131101 или 01-11-2013). Второй пример показывает, что при определенном переупорядочивании смысл не теряется)) Следовательно, тип поля "дата" сам по себе нарушает 1НФ)) Если не развивать и детализировать теорию, которую Вы частично привели.