stenfчитаем:
Виноват, очень неудачно сформулировал, и Вы вполне правы, восприняв это утверждение именно так, как сказали выше. Прошу далее не учитывать эту цитату, попробую объяснить поудачнее.

null требуют того же самого винтика, что и sql вообще. Они упрощают работу в "sql-стиле" и усложняют работу в алгоритмическом стиле.

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

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

stenfБлин. Дело-то не в процессе описания, а процессе сопровождения этого описалова.
В том числе. Простую и естественную модель сопровождать куда проще и удобнее, нежели искусственную и сложную.

stenfпро уйму проблем пожалуйста поподробнее.
Хм. Видите ли, способов обойтись без null можно придумать много, проблемы соответственно в разных случаях разные. Перечислить все - пожалуй, черезчур много текста. Так что пожалуйста выделите тот путь, который нравится Вам, обсудим его.

Основной с моей точки зрения - "пожалуйста поподробнее" ниже в том письме, на которое Вы отвечаете.

stenfsoftwarer, при всем к вам уважении это - детские аргументы. Вам что, join'ны не нравяться ? Они - основа всей теории. Может тогда и нормализацию не производить, она знаете тоже к join'нам приводит ? У вас какая-то избирательная любовь к теории - тут люблю, тут не люблю.
Видите ли в чем дело, если смотреть на теорию фрагментарно, чужие взгляды заведомо покажутся фрагментарными.

Нормализация - часть теории. Денормализация - другая часть. Истина - посередине. Мне нравятся "правильные join-ы на своем месте" и не нравятся "неправильные join-ы там, где они вредны". Лично мне этот подход кажется вполне целостным.

Join - механизм с определенными потенциальными возможностями и определенной стоимостью. Его следует применять там, где он дешевле альтернатив, и не следует применять там, где траты на него неоправданны.

stenfJoin'ы при нормализации это нормально, а вот при null - нет.
В целом так. Нормализация дает серьезные преимущества, и цена join-а в большинстве случаев является более чем адекватной платой за них. Отказ от null-ов в данном варианте не дает преимуществ, сравнимых с ценой.

stenfNull между прочим тоже не бесплатный, серверу приходиться тратить на сопровождение столбца null определенное количество ресурсов.
Охх. Вот это уже детский аргумент.

Цена null, если говорим о серверных ресурсах - один байт (иногда ноль, но не будем углубляться), и соответственное время на чтение-анализ. Цена лишнего join-а - как минимум лишний full index scan, далее зависит от плана запроса, но в любом случае траты просто несравнимы.

stenfв том примере было лишь показана разница между бизнес-правилами: те, которые вероятно в будущем изменяться, и те, которые железно будут действовать, ибо того требует логика реальности, а не бизнес заказчика ;)
Как я Вам показал (на примере счетов, оторванных от банков) таких вот "железно будут действовать" не существует.

Но вопрос не в этом. Вероятность изменения того или иного бизнес-правила никак не связана с тяжестью при его нарушении, а напомню, обсуждаем мы именно последнее.

stenfпо сути, вышеприведенный ответ годиться и тут. Если бизнес-правило это позволяет, то неверными эти данные нельзя считать.
Еще раз, медленно и печально: бизнес-правило этого не позволяет. И Ваши фантазии на тему "в будущем бизнес-правила могут измениться так, чтобы позволять" не имеют отношения к сегодняшним проблемам, к проблеме разрушенных, бесполезных и даже вредных данных.

stenf softwarer
Скажем, абстракция "проводка" не представляется мне "очевидной". Однако, очень широко используется, и все добросовестно изучают, что же это такое.
Ох, а уж какая не то чтобы хорошая идея, например, "аналитического счета".....

Вы говорите парадоксами.
То отвергаете теоретически верные аргументы на той-лишь основе, что высказаны они Селко/Хендерсоном/Дейтом etc, а они вовсе и не авторитеты для вас, то показываете пальцем на неверные (по вашему) метафоры и говорите - видите там гланды через задницу удаляют ?
Парадоксами?

Вы, пардон, сказали не самую разумную вещь - "необходимо, чтобы абстракция казалась очевидной". Я привел Вам пример общеизвестной и общеиспользуемой абстракции, очевидной не являющейся. Если это для Вас парадокс - хорошо. Теперь следует правильно его оценить и уточнить теорию, на основании которой Вы в этот парадокс вляпались. Если Вы считаете, что проводки - это "удалять гланды через задницу", я уверен, тысячи присутствующих здесь с громадным удовольствием выслушают рассказ о превосходящих альтернативных решениях.

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

Да, лучше. Но не всегда возможно. И подобное... примитивное восприятие теории, к сожалению, оказывается слишком уж непрактичным.

stenfЗначит и я так поступать имею право - все из окна прыгают, и я туда-же
Cтоп-стоп-стоп. Это Вы, пардон, все время апеллируете к "современным течениям в программировании" и прочим "все из окна прыгают". Я сказал строго наоборот - "иди туда, куда тебе надо". Будет нужно для задачи - прыгну из окна, не будет нужно - не прыгну.

stenf softwarerОни упрощают работу в "sql-стиле"
ну как-же упрощают, когда наоборот усложняют ?
Так. Упрощают.

stenfДля разнообразия, могу привести цитату другого "столпового" автора данной тематики - Кален Дилейни:
Хм. Скажите, а Вас не затруднит приводить кого-нибудь кроме MSSQL-щиков? Во-первых, я мало знаком с ними, во-вторых, безоговорочно доверять им я готов исключительно в вопросах внутренней архитектуры MSSQL.

stenf "As you know, I strongly recommend that you minimize the use of NULL... introducing NULL will be a source of bugs just waiting to happen"
Я не готов оценивать фразу, не зная подразумеваемого для нее контекста. Скажем, ее вполне можно сопоставить известной привычке MSSQL-щиков писать несколько простых запросов вместо одного сложного, связывая их процедурным кодом.

stenf softwarerДружище, рассказывать банальности так, чтобы они приходились к месту - большое искусство, и в нем у Вас еще есть, куда расти.
хм, вы по совместительству литературный критик ? Не люблю, когда меня критикуют люди, заведомо ничего не понимающие в предмете своей критики.
Помилуйте, откуда же "литературный"? Вы пересказали банальность из книги, пересказали ее совершенно не в кассу; чтобы "критиковать" Вас за это, незачем быть Виссарионом Григорьевичем, достаточно понимать суть предмета обсуждения.

stenfКакой вывод напрашивается из данных цитат ?
Эту тему я даже специально упомянул в своем FAQ: http://softwarer.ru/about.html#Derivations

stenfА такой, что вы предпочитаете действовать по принципу "зачем делать просто, когда можно сложно.
Дружище, если из всего многообразия "иди куда нужно" Вы видите одно-единственное направление движения - это шоры Вашего мышления, ничего более. И в строгом соответствии с предыдущей ссылкой выдаете это как "мне сказали именно это".

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

stenfвообще-то, если легко и естественно описать не обязательно получиться простая и естественная модель .
Вы хотите поспорить о формальной логике? Можно в принципе, хотя лениво. А если неформально, то "практически обязательно". Чтобы получилась "непростая и неестественная", надо описывать не "легко и естественно", а "тупо и формально", что отнюдь не синонимы.

stenfКопать будем в SQL Server 2000.
/me борется с желанием произнести что-нибудь типа "брось бяку" ;-)

stenfЗато если столбец позволяет null, то для каждой обрабатываемой строки столбца сервер должен декодировать маску, что-бы определить, есть-ли там null. Делается это не за счет доброго дяди, а за счет ресурсов компьютера. Хотя безусловно, для одной строки это является каплей в море.
Это для любого количества строк является каплей в море. "Декодирование маски" делается парой ассемблерных команд; поверьте, трудно найти задачу, которую компьютер решает эффективнее. Разница лишь в том, что для некоего "разумного количества строк", например до 10.000.000, это будет "капля в море вообще, в абсолютных числах", а для большего количества - "капля в море относительно других операций, которые придется провести с теми же данными".

stenfОднако при этом их не интересуют параметры изделия как такового, эти параметры запрашиваются приложением автоматически при его запуске, что происходит обычно один раз в день .
То есть, если я Вас правильно понял, ваше приложение чихает на понятие "согласованность данных"? И если вдруг меняются параметры изделия, Вы подходите к мегафону и громко-громко-громко говорите "Всем пользователям системы перевойти в нее"?

Впрочем, это лирика в сторону.

stenfТаким образом, лишний join к промежуточной таблице будет происходить 1 раз в противовес бесчисленным запросам к таблице Детали на протяжении 8 часов рабочего дня. (в реальности это реализовано не совсем так, но для иллюстрации сгодиться). Возможно, эти затраты все равно не перекроют этот join, однако говорить об несравнимых затратах я бы уже не стал.
Хм. О "несравнимых затратах в данном конкретном случае".

Оптимизация - такая вещь, что для любого случая можно сконструировать обратный. Скажем, несложно построить пример, в котором для запроса вида SELECT * FROM TABLE WHERE ID = :ID предпочтительным методом доступа будет FULL TABLE SCAN, а индекс пойдет нервно курить в сторонке.

Однако, когда мы вот так, на пальцах, обсуждаем эффективность-неэффективность глобальных подходов, имхо естественно говорить о типичных случаях.

stenfГрубо говоря, ваша идея не учитывает случаи, когда количество лишних join'ов много меньше общих обращений к таблице.
В первую очередь: я не знаю MSSQL и могу ошибиться, но мне кажется, Вы в своем рассуждении проглядели одну маленькую подробность. Если типичный запрос не пользуется данными пристыковочной таблицы, в случае одной таблицы он также не будет лезть "декодировать маску" для этих данных и соответственно не будет тратить на это ресурсы. Таким образом, Ваш пример сводится к противопоставлению в запросе "один раз в сутки", где join скорее всего также проиграет.

Хм. "Моя идея" относится к статистически значимой выборке. Скажем, "что будет, если взять случайную систему, и в ней во всех местах - а не в одном-единственном, как в Вашем примере - заменить null поля введением дополнительных таблиц". Я - так уверен, что с малоотличимой от единицы вероятностью система замедлится.

stenfЧто еще более плохо, запрос на получение всех деталей изделия теперь вместо простого select * from Детали where IDИзделия = 21 может быть составлен как select * from Детали where coalesce(IDИзделия, IDДетали) = 21 из-за необходимости учета нулевой сборки, и помимо усложнения его синтаксиса мы еще и можем получить index scan вместо index seek
Этого, пардон, я совершенно не понял. Собственно, сама по себе фраза coalesce(IDИзделия, IDДетали) говорит о кривой структуре данных (несравнимые вещи сводятся под одной крышей). О какой структуре данных идет речь? К сожалению, я не имею представления, что такое "нулевая сборка", но в любом случае прежде всего - нарисуйте, пожалуйста, какую структуру Вы сравниваете, и с какой.

Ну а в целом - ответ тот же, что и про оптимизацию. В любом случае, можно подобрать структуру БД и профиль запросов, отвратительно соответствующие друг другу. Но из этого ничего особенного не следует.

stenfтут не понял, почему обязательно scan, а не seek ?
Не то чтобы "обязательно", подразумевался запрос ко всем данным таблицы. Запросы к одной записи всегда отрабатывают быстро, если их не слишком много, говорить об эффективности подхода применительно к таковым смысла мало.

Соглашусь, к сожалению я небрежен в нашем разговоре. Прощу простить за это, к сожалению много отвлекающих факторов.

stenfНапример мне кажется логичным высказываение одного из "столпов" (не помню какого), что если-уж применять их, то в случаях, когда в текущий момент времени значение поля неизвестно, но обязательно появиться в будущем.
Cтранный подход, признаться. Не знаю, как и в каком контексте было сформулировано в оригинале, но в таком изложении - не вижу цимеса. Скажем, как провести границу обязательного появления - через две недели, или допустим через двадцать лет?

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

Итого: как Вы предполагаете правильным хранить эти данные? Скажем, задача: хранить ФИО физ. лица, дату рождения и ИНН (прочие атрибуты для экономии времени опустим). Вопрос: как правильно хранить?

stenfПерманентное-же существование null мне не кажется оправданным.
Хм. Прежде всего мне в этом случае очень странно, что считанные письма назад Вы резко нападали на "временный null", срок жизни которого исчислялся микросекундами между выполнением нескольких операторов одной транзакции, а никто другой эти данные увидеть не мог (надеюсь, у вас в системе нет грязного чтения?) Сейчас же Вы уже примиряетесь с существованием временного null со сроком жизни в несколько недель, которым успеют воспользоваться все кому не лень.

Честно говоря, это воззрение имхо показывает слабость Вашей идеологии. Почему: потому что все проблемы, которые только может доставить null, в случае "временных null" ничуть не менее страшны, нежели в случае "перманентных null". Разница между ними в лучшем случае количественная (количество бизнес-функций, работающих с "данными во временном состоянии" несколько меньше, нежели полное количество бизнес-функций системы, мест для ошибки соответственно меньше). Таким образом, получим, что есть некоторое количество временных null допустимо для системы объема X, такое же количество перманентных null вполне допустимо для системы объемом, скажем, 3*X ("вполне допустимо" означает в данном случае "доставляет не больше проблем, чем").

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

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

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

stenfНапример я, если какой-нибудь умник при сопровождении моей системы, для обхода логической проблемы оторвет детали от ссылок на изделия и напортачит с данными - сначала заставлю вернуть все на свои места, а уж затем исправлять проблемы
Правильно. А вот почему-то "умником, который хочет для обхода логической проблемы разрушить баланс и напортачить с данными" - Вы готовы выступить, во всяком случае, привели такой пример и считаете его правильным.

stenf softwarer
Вы, пардон, сказали не самую разумную вещь - "необходимо, чтобы абстракция казалась очевидной". Я привел Вам пример общеизвестной и общеиспользуемой абстракции, очевидной не являющейся. Если это для Вас парадокс - хорошо. Теперь следует правильно его оценить и уточнить теорию, на основании которой Вы в этот парадокс вляпались

Раз уж цитируете, то цитируйте до конца - "необходимо, чтобы абстракция казалась очевидной и другим людям "
Хм. Раз уж упрекайте, включайте логику. Кто у нас есть из "не других людей"? Автору абстракции - она как правило очевидна, или во всяком случае хорошо понятна, о нем речь не идет. Есть другие люди. Еще есть бог, марсиане и морские свинки; когда мы говорим о проектировании БД, эти категории "прочих" неинтересны и не обсуждаются. Кто еще есть кроме "других людей", кому "должно быть очевидно"?

Таким образом, я не убрал из Вашей цитаты ничего значимого.

stenf;) Откуда у вас такая уверенность, кто из нас вляпался ?
Вкратце уже объяснено в том, на что Вы отвечаете. Ваше утверждение противоречит практике, причем не довольно абстрактным рассуждениям о глобальных тенденциях, но практике, существовавшей задолго до программирования и процветающей до сих пор. Таким образом, чтобы обосновать свое утверждение, Вам придется пояснить, чем эта практика не верна, и самое главное - как сделать лучше.

Как я уже сказал, тысячи присутствующих здесь с громадным интересом выслушают толковые предложения. Но пока Вы их не выдвинули - я буду пребывать в уверенности, что Вы таки вляпались.

stenfПриведу еще одну цитату: "Метафоры имеют одно неоспоримое достоинство - описываемое ими поведение предсказуемо и понятно всем людям.
Ха-ха-ха. Это далеко не всегда верно даже в случае таких очевидных и проработанных метафор, как элементы пользовательского интерфейса.

Это идеальная ситуация, к которой нужно стремиться, но которую в случае "всех людей" совершенно невозможно достичь.

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

"Другие люди, не являющиеся членами проектной команды", проекту совершенно неинтересны. Если Вася Пупкин, сварщик из Воркуты, не ориентируется в моих розовых слонах - никому от того не холодно и не жарко. Вот Вы же - не знаете, что такое проводка? Но мир от того не рушится. Если когда-нибудь придете работать туда, где используется эта абстракция - узнаете.

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

Разумеется, очевидность той или иной метафоры является ее достоинством. Не всегда достижимым достоинством. Однако, при выборе "один раз научить принятого на работу человека неочевидной метафоре" либо "всем каждый день работать с неудобными метафорами" разумные люди выбирают первый путь.

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

stenf softwarer
Если Вы считаете, что проводки - это "удалять гланды через задницу", я уверен, тысячи присутствующих здесь с громадным удовольствием выслушают рассказ о превосходящих альтернативных решениях
ну и напрасно вы тут так злорадничаете, я понятия не имею что такое проводка.
Тогда Вы неэтично поступили выше, там, где пассаж про литературную критику. Там у Вас есть критика "не разбирающихся"; сейчас же Вы ткнули в предмет, в котором "понятия не имеете" и сказали "гланды через задницу". То есть Вы требуете от других одной модели поведения, а сами пользуетесь другой, противоречащей.

stenfВы сами сказали, что эта абстракция неочевидна. Однако если вы хотите этим оправдать появление на свет вашего еще менее очевидного слона - то вы на неверном пути
Хм. Еще раз, медленно и печально: "проводка", "нулевая сборка", "аналитический счет", "поле комплексных чисел" и мириады других неочевидных абстракций - примеры "розовых слонов", которые появляются потому, что удобны для решения той или иной задачи.