stenfPragmatically, dealing with NULL brings added complexity to the storage engine because
Это верно, но в данном случае не наша задача и не предмет нашей дискуссии. Написать хорошую программу вообще сложно; если разработчик СУБД хочет дать мне хороший продукт - он справится с этой сложностью. Если хочет облегчить себе жизнь - избавится от null. А я избавлюсь от его продукта и куплю хороший.

stenfAllowing NULL also adds complexity in application code, which can often lead to bugs. You must always add special logic to account for the case of NULL.
Это очень похоже на рассуждение именно о процедурном коде. Если так, согласен. Как я уже говорил, null упрощает запросы ценой потенциального усложнения процедурного кода.

stenfIn outer-join operations, you should carefully account for NULL values that are generated to preserve rows that don't have a match in the table being joined.
Это чушь. При outer join ничего carefully account не нужно. carefully account может потребоваться при обработке полученных через outer join результатов, начиная от coalesce в select и кончая все тем же application code. Можно построить пример, когда это ведет к дополнительным сложностям, но в реальности null как правило упрощает такие ситуации. Скажем, простейший пример "контрагент может быть физическим либо юридическим лицом":


Имхо вполне очевидно, что первый запрос удобнее и для написания, и для понимания, и для последующего сопровождения.

stenfAnd even if you're comfortable with three-valued logic, your developers and anyone querying the data using the SQL language typically won't be;
typically - это явная ложь. Впрочем, типичная для микрософта идея о ламерах, которые будут писать хорошие программы, оставаясь при этом ламерами. Впервые она была выдвинута ими примерно пятнадцать лет назад, пока никаких результатов не дала. Думаю, и дальше не даст.

stenftherefore, introducing NULL will be a source of bugs just waiting to happen.
Итого, в лучшем случае это половина правды. Другая половина правды - bugs, которые waiting to happen из-за усложнений структуры данных и прочих недостатков "схем без null".

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

Видите ли, ситуации бывают разные. Например, в MSSQL некоторые проблемы доставляет различие null и пустой строки, другие проблемы доставляет специфическая работа c null unique constraint-ов. Я того и другого лишен, поэтому, вполне вероятно, смотрю на null оптимистичнее гуру MSSQL.

stenf softwarerВы пересказали банальность из книги
8-/ Какой книги, вы о чем вообще ? Бред какой-то. Я попросил-бы вас не бросаться высосанными из пальца догадками, да еще таким тоном. Когда я кого-то цитирую, я это явно указываю.
Вы знаете разницу между "цитировать" и "пересказать"? Или просто не замечаете?

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

stenfзнаете, не вы один обладаете здравым смыслом и способностью к логическим выводам.
Знаю.

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

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

stenfТут пока не готов дискутировать. Выяснение того, какой реальный процент ресурсов потребляет отслеживание null требует некоторого исследования.
Лично я перед тем как писать, проверил на MSSQL2000. На 10.000.000 строк на своей рабочей станции разницы не зафиксировал.

stenfВсе-таки движок сервера написан не на ассемблере (хотя возможно имеются значительные ассемблерные вставки), и операция проверки на null не обязательно сведется буквально к 2 ассемблерным операциям (не зная внутренностей никогда ничего нельзя гарантировать).
Хм. Тут есть два отдельных момента. Первое, что к сожалению очень часто нарушается неопытными программистами: надо очень четко понимать приоритеты различных идей, понимать, что фундамент, что следствие. В частности, если в конкретном движке SQL поддержка NULL реализована плохо, это не значит, что NULL теоретически плох - это значит, что программистам конкретного движка надо надавать пенделей, чтобы сделали хорошо. Впрочем, я уверен, что во всех серьезных продуктах такие аспекты проработаны на достойном уровне.

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


и как он выглядит в ассемблере, соответственно нетрудно предсказать.

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

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

stenfтолько поверьте, необходимости в этом нет. Список изделий редактируется от силы раз в месяц.
Вопрос не в том, как часто он редактируется. Вопрос в том, что будет, если:

- пользователь 1 загрузился и работает
- пользователь 2 изменил список изделий
- пользователь 3 загрузился и сделал операцию с участием нового/измененного изделия, например определил ему детали
- пользователь 1, не перезагружаясь, выполнил операцию с данными, которые только что подготовил пользователь 3.

Да и то это будет иметь значение только для добавления/удаления изделий, а никак не при редактировании их свойств.

stenf softwarer
Оптимизация - такая вещь, что …

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

stenfа решение использовать/неиспользовать null в общем случае относиться в первую очередь к структурным вопросам, а не к оптимизационным.
Правильно.

stenfЭто кстати является аргументом против применения null “потому-что это быстрее”.
Эк Вы загнули и еще веселее загибаете дальше. Напомню, как развивалась тема:

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

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

stenfПодробности об изделии закачиваются один раз и на это требуется join. Другие запросы обходяться без join’а, но все равно потребляют столбец, который будет иметь null в случае отказа от третьей таблицы.
Похоже, мы не понимаем друг друга. Постараюсь объяснить еще раз, что имею в виду.

Допустим, у нас есть столбцы A, B, C, D, которые в обсуждаемых вариантах могут быть разнесены по разным таблицам либо сведены в одну. Скажем, A и B - в одной таблице, C и D - кандидаты на вынос в другую либо на null. Набор данных у нас объективен, определяется задачей; меняться может только набор технических полей типа ключей.

Итак, у нас будут запросы вида


Мне представляется очевидным, что запросы 1) и 3) одинаковы и при прочих равных будут выполняться одинаково, несмотря на наличие либо отсутствие null-колонок c и d в таблице. Потому что c и d не участвуют в запросе, серверу нафиг не интересны их значения и "тратить заметные ресурсы на анализ маски" он не будет. Просто потому, что хорошо написан, что разработчики всячески вылизывают производительность.

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

stenf“Кривой “ структурой данных является предложение ModelR’a, которое я кстати предлагал вам критиковать еще на первой странице топика.
Хм. Согласитесь, я не обязан отзываться на все предложения. В частности, чтобы всерьез рассуждать об оптимальной структуре данных, надо знать либо четкую постановку задачи, либо предметную область. У меня такого знания нет, поэтому я воздержался от рекомендаций. Изначально я показал лишь возможные пути решения конкретной технической проблемы, далее мы спорим о концепцуальных и общих вещах.

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

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

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


Что хотел бы подчеркнуть: ид_иделия в деталях может быть null, если это нужно по условиям задачи (допускаются детали без изделий, скажем в рамках допускаемых Вами "временных null"), и проблем в указанном запросе это не доставит, ровно наоборот: наличие там null при inner join Изделия уберет ненужные Вам записи, в то время как в схеме "без null" пришлось бы рисовать специальный фильтр. Для Вашей задачи, где как я понимаю, детали строго привязаны к изделиям, там конечно следует поставить not null - опять же, не потому что это избавляет от проблем, но исключительно для соответствия бизнес-требованиям конкретной задачи.

stenfЧто-же в этом странного, обязательное появление означает что запись рано или поздно там появиться, и не важно, через 1 день или 20 лет.
Странен критерий. Не вижу цимеса, не вижу, что хорошего мы получаем таким путем и что плохого не получаем. Я не вижу значимых отличий этого подхода от "допускать перманентный null".

Что есть "рано или поздно"? Скажем, как Вы расцените ситуацию, в которой прогнозируемое "поздно" будет больше предполагаемого срока вывода этой системы из эксплуатации?

В качестве примера - возьмем поле "дата смерти" для тех же физ.лиц, ну и информационную систему, например, ЗАГСа. Вполне очевидно, что значение в этом поле "рано или поздно появится", но точно так же очевидно, что для большинства свежевведенных записей к моменту вывода этой системы из эксплуатации там будет null. Как это расценивать - как постоянный null или как временный? Стоит ли класть в ту же таблицу?

stenfВ связи с тем, что по условию задачи есть люди, которые по определению не могут иметь ИНН,
Таких людей нет. В некоторых случаях даже младенец может оказаться вынужденным получить ИНН. Вопрос в другом - теоретически существуют люди, которые могут прожить долгую и счастливую жизнь, так и не получив ИНН.

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

stenfХотя уверен, что в реальности они все в одной таблице, потому-что так “проще” ;)
В реальности они как правило в одной таблице потому, что так лучше.

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

Неужели не догадываетесь, что принципиальная разница между “null которого никто не видит” и “null доступный для всех” в том, что в первом случае sql-код для работы с базой должен учитывать возможность появления null в данных, а во втором – нет ?
Вот я как раз и не понимаю, почему Вы ожесточенно критиковали "null который никто не видит", но при этом допускаете существование "null доступный для всех". Обратную логику я бы вполне понял, в такой же постановке - смысла не вижу.

stenfПерманентный null имеет одну серьезную связанную с ним проблему – если там вдруг случайно появляется значение, то это может нарушить всю логику и привести например к появлению изделия у изделия, чего никак не может быть.
Простите, это полный бред. Давайте уточним терминологию и вообще постараемся проговорить все максимально четко.

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

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

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

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

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

stenf softwarerХм. Раз уж упрекайте, включайте логику. Кто у нас есть из "не других людей"?
А вы иногда отключайте логику и включайте здравый смысл. Абстракция может быть очевидной для вас, но не для других людей.
Я предпочитаю держать включенными и логику, и здравый смысл. Так я вижу, что например Ваша фраза "Абстракция может быть очевидной для вас, но не для других людей" в первую очередь возражает на Вашу же "абстракция должна быть очевидной" (или, если угодно, уточняет ее), во вторую очередь совершенно не относится к тому, что я говорил (Ваше уточнение насчет "других людей" является тавтологией), и делаю вывод, что Вы возражаете, не особо обдумывая сказанное, "абы возразить". Кстати, опять банальщиной.

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

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

Абстракция - в общем случае не является метафорой понятия предметной области. Если в предметной области есть понятия "молоток", "станок", "рабочий", "директор" и так далее, нам может оказаться удобным выделить такие абстракции как "инструмент" и/или "сотрудник". Мало того, такие абстракции, оказавшись удобными, со временем врастают и становятся новыми "понятиями предметной области" - как, скажем, "аналитический счет". Вы не сможете прийти на завод и показать мне железяку или иной предмет, являющийся аналитическим счетом, да и счетом (в учетном смысле) вообще. Это абстракция.

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

Так вот. Когда-то не было проводок, аналитических счетов, нулевых сборок, комплексных чисел. Когда-то они были розовыми слонами.

Скажем, Ваши слова: нулевая сборка - это термин предметной области (здесь сведены две ваши фразы из соседних предложений, надеюсь простите чуть неточное цитирование, призванное выделить ключевое). Давайте посмотрим, что это за предметная область . Три ссылки - как-то негусто. Цитаты:

Что есть нулевая сборкаНе знаю как там, у «государственных оружейников», а у меня лично «аванпроект» это то, что я нацарапал на бумажке без размеров. С размерами у меня это называется «нулевая сборка», поскольку я из авиации пришел. У нас так назывался сборочный чертеж

1) Mandriva - это логическое продожение Mandriva linux. Стоят самые последние (ну или почти) пакеты. Мне нравится. Правда бывают висяки из-за того что это нулевая сборка за датой 2 января


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

Прошу прощения, при редактировании выпала пара абзацев, повторю фрагмент с ее добавлением.

stenfПерманентный null имеет одну серьезную связанную с ним проблему – если там вдруг случайно появляется значение, то это может нарушить всю логику и привести например к появлению изделия у изделия, чего никак не может быть.
Простите, это полный бред. Давайте уточним терминологию и вообще постараемся проговорить все максимально четко.

.........

Так вот, если предположить, что проблема в том, что "в поле вдруг появилось неправильное значение", значение которого там не должно было появляться, давайте подумаем, в чем разница между перманентными и временными null в этом случае? Лично я разницы не вижу.

В случае перманентных null это неправильное значение будет висеть и доставлять непредсказуемые проблемы все время своего существования. То есть либо пока его не найдут и не исправят, либо пока не удалят запись, либо пока туда по бизнесу не окажется пробитым правильное значение. Что же будет в случае временных null? Собственно.... это неправильное значение будет висеть и доставлять непредсказуемые проблемы все время своего существования. То есть либо пока его не найдут и не исправят, либо пока не удалят запись, либо пока туда по бизнесу не окажется пробитым правильное значение.

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

!!!С точки зрения проектирования БД ничем не отличается от любой другой сборочной единицы, за исключением того, что в деревянной структуре это будет корень.
В целом, Вы укрепили мое мнение о ненужности и искусственности разделения "Деталей" и "Изделий" в терминологии автора.

2stenf: кстати, вот такая вещь. Насколько я помню, Вы собираетесь копировать детали, которые одинаковы, но входят в разные изделия. Опуская обсуждение недостатков этого подхода, давайте подумаем вот над чем: а что, если изделие состоит в том числе из других изделий? Как вы собираетесь отрабатывать этот момент? Что будет, если изделие А (заказчик АБС, срок сдачи 01.02.03) включает изделие Б (заказчик ЭЮЯ, срок сдачи 04.05.06)?

stenfУ нас специфическое опытное производство
Кстати, эта фраза меня уже изрядно настораживает. Дело в том, что специфические на первый взгляд задачи склонны в ходе сопровождения становиться все более и более похожими на типовые. Поэтому внесение информации заказа в изделие меня... напрягает; я не стал бы так делать, даже если сейчас они связаны 1:1. Просто потому, что весьма вероятно, это придется переделывать.

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

Поверьте, даже на таком специфическом производстве, как строительство АЭС - мне пришлось иметь с этим дело - были многогдеиспользуемые детали.

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

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

stenf2 softwarer: Обратите внимание, сделанный вывод, базирующийся на домыслах автора. Ниже еще поговорим о логических выводах.
Давайте все же в разговоре Вас со мной обойдемся без анализа выводов третьих лиц.

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

stenf softwarer
Это очень похоже на рассуждение именно о процедурном коде.

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

Если я говорю "А похоже на Б" - это не "догадка". Это "мнение", которое по необходимости я могу обосновать. Сказанное дальше "если так" Вы, разумеется, деликатно опустили.

stenf softwarer
Это чушь. При outer join ничего carefully account не нужно. carefully account может потребоваться при обработке полученных через outer join результатов

;) очевидно, ваш английский не находиться на идеальном уровне. Речь тут как раз и идет о Null в записях, сгенерированных при отсутствии совпадающих в другой таблице.
Мой английский находится на очень далеком от идеального уровне, впрочем, к данному случаю это отношения не имеет.

Очевидно, Вы в очередной раз не смогли или не захотели понять сказанное. Разжевываю: есть такая операция в реляционной алгебре, join. У нее есть вариация, outer join. Для ее применения никаких особых null учитывать не надо. В результате применения этой операции null values generated to preserve rows. Если эти данные дальше где-то обрабатываются (а не просто выводятся в грид, например), для этих null-ов может потребоваться "специальное внимание" на тех же основаниях, что и для полученных любым другим образом, ничего особенного outer join-ы не вносят.

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

stenfи вы безусловно можете дать ссылку на что-нибудь официальное, где говориться именно о ламерах, способных писать хорошие программы при помощи софта ?
Скажем, рекламные пресс-релизы к Microsoft Access :) Ссылки, к сожалению, не дам - все же с 92-го года прошло немало времени, непросто найти - но впервые эта идея была подчеркнута именно там.

stenfСогласен, что про типичных девелоперов не знающих про null немного спорно, но вот про "anyone querying the data using the SQL language" вполне разумное высказывание.
Ничуть. Те, кто работает с данными именно на SQL - обычно толковые люди, специалисты в своей области, и идею null-ов схватывают очень быстро вместе с пользой от нее. Проблемы я видел у тех людей, кто пользуется визуальными инструментами, а в SQL лезет редко по особой необходимости. Но тут достаточно, чтобы визуальный интерфейс хорошо отрабатывал этот момент, благо это несложно - понятие необязательной связи интуитивное, внимание стоит уделить тонкостям, например вычисляемым атрибутам.

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

null - это не "тонкости языка". Это основа.

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

stenfа что, в Оракл пустая строка и null это одно и то-же ?
Да.

stenfИ вы этим, кгхм, гордитесь ?
Нет, ничуть не горжусь. Я этим пользуюсь, очень удобно. После того, как поработал на MSSQL и почуствовал разницу, стал ценить еще больше.

Кстати - следует ли понимать так, что Вы гордитесь mssql-ными unique?

stenfеще одна "пальцемвнебо" догадка.
Не "еще одна", а "та же самая". Которую я Вам разжевал, прямо сказав, что это догадка.

stenfИз мысли про футбольную команду вы вывели отсутствие опыта работы в команде ?
Нет, нисколько. И если не ошибаюсь, не давал повода думать именно так.

stenfПотрясающая логика.
Безусловно. Я уже упоминал, что Ваша логика представляется мне необычной. Например, сказанное Вами в предыдущем предложении мне бы и в голову не пришло. Жаль, конечно, но моя фантазия ограничена.

stenfВы знаете анекдот про логику и аквариум ?
Нет, не знаю, хотя примерно догадываюсь.

stenfТам, где, раз у тебя нет аквариума, то ты голубой ? Сильно напоминает.
Ну... меняйте, если хотите.

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

Поясняю: оптимально - значит оптимально. Если с некоторой задачей лучше справятся десять дворников, я найму десять дворников и куплю им метлы. Если с некоторой задачей лучше справятся два гуру, я найму двух гур и куплю им гурий. Технологии выполнения дворниками недворницких задач мне неинтересны, поскольку не позволяют достичь хорошего результата. Их потолок - "средний результат при низкой квалификации".

stenfу меня нет причин вам недоверять, но вы все-таки напишите пожалуйста какие параметры вы меряли. Время там, или загрузку ЦП или что-то еще. Я хочу в свободное время поэкспериментировать
Я выкинул все лишнее и мерял время выполнения запроса над табличкой с null- и notnull-полем в ситуации, когда надо было выполнить проверку на null. Конкретнее уже не вспомню.

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

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

stenfПользователь 1 не увидит нового изделия. Он-же без него загрузился. Если-же изделие наоборот, было удалено например в архив, то при попытке доступа к деталям этого изделия он получит сообщение в духе "список изделий изменился".
А если изделие изменилось? А если он и не должен видеть изделие, пляшет от деталей - скажем, выполнил поиск детали по ее артикулу, а деталь от нового изделия?

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

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

stenfСогласен, но я имел ввиду несколько другую ситуацию.....
В случае отказа от третьей таблицы и разрешения null в Детали.IDИзделия, вышеуказанный запрос на детали изделия не измениться. Однако в этом случае столбец IDИзделия nullable и значит требует расшифровки маски.
Хм. Видимо, мы к этому моменту потеряли понимание, раз обсуждали разные ситуации. Я понимал, что мы обсуждаем ситуацию с объединением таблиц изделий и деталей.

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

stenfэто чудо нужно затем, что-бы .....
Я понимаю, зачем оно нужно в текущей реализации. Но оно подозрительно своей особой ролью; я бы предположил, что либо "нулевая сборка есть изделие" в варианте с объединенными таблицами изделий и деталей, либо "нулевая сборка есть одна из многочисленных сборок" в других реализациях. Именно такая роль - в деталях лежит нулевая сборка и только она..... подозрительна.

stenfСпасибо, данная схема действительно представляется более удачной. Однако хотел-бы узнать, чем она лучше/хуже введения третьей таблицы. Или такие решения вообще равноправны ?
Поверхностно, оно лучше соблюдением принципа "не стрелять из пушки по воробьям". Если для хорошего решения задачи достаточно поля, незачем плодить таблицу, тем более таблицу с подчиненными объектами, такими как внешние ключи. Это верно со всех точек зрения: и проектирования (меньше делать, меньше держать в голове), и кодирования (меньше и проще кодировать), и соответственно сопровождения, и трат ресурсов.

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

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

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

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

Но какое отношение это все имеет к постоянным/временным null? Чем логический парадокс для одного отличается от логического парадокса для другого?

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

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

stenfОднако, проблема совсем другого плана появиться, если в моей схеме (где если IDИЗделия is null, то это корень) в этой ячейке IDИзделия вместо перманентного null возникнет число. В этом случае нулевая сборка станет неразличимой и изделие вообще "изчезнет". Согласитесь, это другой уровень ошибки.
Нет, не соглашусь. Скажем, в ЖКХ есть понятие "ответственный квартиросъемщик". Если у него в "дате смерти" вдруг появится дата, легко произойдет ровно то же самое (достаточно предположить, что в запросе квартиры join-ятся со вьюхой "живых людей").

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

stenfОператор системы вполне в состоянии увидеть логическую ошибку живущего мертвеца, а вот изчезнувшее изделие требует вмешательства другого уровня.
Хм. Знаете, я полтора года занимался тем, что разгребал подобные ошибки. А именно "находил подозрительные места в данных, искал, откуда они взялись и как их ликвидировать". Так вот, с точки зрения проблем, "исчезнувшая запись" - самая приятная какая только может быть. Потому, что пользователь, который работал с ней и вдруг не нашел - тут же говорит "исчезло". Или звонит из другого города и говорит "нам в бухгалтерии говорят, что счет уже оплачен, а у нас в списке оплаченных он так и не появился". Или "я пробую ввести, а система говорит мне, что такая запись уже есть, а я ее не могу найти" (это если например срабатывает unique key на каком-нибудь артикуле, номере документа итп). Или что-то еще подобное, быстро и просто, а потому обычно ликвидируется раньше, чем успели возникнуть серьезные последствия.

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

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

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

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

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

stenfК примеру, слово "транзакция" мне вообще не кажется связанным с тем, что все под ней представляют.
Ээ... а что "все под ней представляют"? Это слово употребляется в разных областях, в частности в туризме под ним понимают практически перевозку клиентов из пункта А в пункт Б.

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

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

У Вас в изделии присутствовали атрибуты, кажется, заказчик и дата заказа или нечто подобное. Так вот: я бы не стал так делать, потому что по моему мнению, с высокой вероятностью бизнес-правила здесь рано или поздно изменятся так, что этот фрагмент потребуется переделать, и эта переделка окажется сравнительно трудоемкой. Поэтому я бы скорее всего сразу выделил бы сущность "заказы", чтобы потом сравнительно легко перейти к любым другим вариантам (скажем: заказ может включать несколько изделий, каждое изделие может заказываться несколько раз).

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

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

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

Так или иначе, у вас при этом используется определенная элементная база. И рано или поздно, но случатся глобальные операции, скажем, "заменить все диоды серии 12345 диодами серии 12346, такими же по основным характеристикам, но, скажем, на 0.05г более легкими".

stenfкак это нет подсбророк ? Изделие имеет дерево входимости, туда можно занести любую сборку.
Ээ.... дерева я там точно не припомню. Сколь помнится, первым же ответом Вам был как раз "используйте дерево". У меня пока что ощущение, что структура плоская, или я вообще не понял изначальной схемы.

stenfопять-таки, почему дублирование ? Если простите пересказ книжной банальности, то дублирование - это когда ФИО автора книги занесено в систему например 2 раза, и исправление ее в одном месте приведет к ошибке - один и тот-же автор в разных местах будет появляться под разным и именем. У нас-же бизнес-правило как раз говорит о том, что изменение должно влиять только на одно место, а не на несколько.
Хм. Видите ли в чем дело, существуют разные типы изменений. Скажем, если человек поменял фамилию, это не значит, что в БД ранее выпущенных книг должны в одночасье смениться атрибуты автора у давным-давно отпечатанных изданий - те должны лежать под старой фамилией. В то же время, если при вводе данных автора в БД была допущена опечатка, как раз таки изменение должно отразиться везде - эти правила вполне могут действовать одновременно. А в худшем случае может действовать еще и третье правило, скажем, если у нас есть данные из внешнего источника, и мы исправили опечатку, может оказаться, что теперь у нас в справочнике нет того автора, который указан во внешнем источнике (связка по имени распалась) и этот конфликт надо как-либо специально решать.

Так вот, как я упомянул выше, я не верю в то, что у вас каждый используемый винтик абсолютно уникален. "Так не бывает". А раз не бывает - значит, потребуется пройти по всему изделию и исправить ошибку человека, который материалом для винтика М3-18/1 указал дерево. Это другая операция, не та же, что "в конкретном месте использовать вместо него M3-18/2".

stenfничего страшного нет, но к какому изделию-то деталь относиться вы тогда не определите.
Да нет, я имел в виду "вполне решается". Просто пока неизвестно, куда присобачивать сборку, присобачивать к корню. Скажем, карбюратор не бывает сам по себе - поэтому когда вводят его сборку, уже введен (или нетрудно ввести) "автомобиль". К нему и привязать. Когда позже будет введен двигатель - перепривязать к нему.

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

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

- Запросы и прочий DML, включая динамически сгенерированные
- Процедурная бизнес-логика (включая триггера, скрипты-батчи и код бизнес-логики на аппсервере или клиенте)
- Интерфейс и прочие задачи клиента.

В цитате сказано "application code", что не дает какой-то конкретной привязки. При этом следующая и логически связанная фраза (You must always add special logic to account for the case of NULL) очевидно неверна, скажем, для задачи "выполнить запрос и вывести его результаты в грид"; таким образом можно предполагать, что имелось в виду не все многообразие "приложения в широком смысле этого слова", а что-то более узкое. Собственно, эта фраза в целом верна для второго пункта и в много меньшей степени - для первого и третьего. Для рассматриваемой фразы верно то же самое - она скорее верна для второго пункта, спорно-неоднозначна для третьего и скорее не верна для первого (пример обратного, который я полагаю типичным, я привел).

Таким образом, создается впечатление, что в этом фрагменте под application code имелся в виду второй пункт.

stenfЕе переводом на русский является В операциях outer-join вы должны внимательно относиться к null, которые генерируются для сохранения строк, которые не имеют совпадений в соединяемой таблице.
Согласен.

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

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

Что касается выводов... в "наверняка" Вы промахнулись. Микрософт довольно активно продвигал идею "программировать без программистов", типа того, что специалист сможет решать свои задачи самостоятельно, программируя в Access, чуть позже - в Офисе (тогда Access не входил в состав офиса). Для этого делалось довольно много всего, в частности в тот же акцес включался набор заранее разработанных типовых БД, какие-то визарды вида "отметьте, какие поля в стандартных сущностях вам нужны и получите готовую БД" итп.

В этом направлении воз и ныне там, и несколько позже Микрософт пошел по другому пути, довольно явно ориентируясь на массу малограмотных разработчиков как на основную движущую силу индустрии. Как типовой пример, сошлюсь на пару раз обсуждавшийся в Сравнении СУБД механизм работы MSSQL с параметрами; если позволите краткий вывод, этот механизм микширует последствия неудачно написанного кода ценой повышенной вероятности замедления удачно написанного.

stenfя все-таки имел ввиду людей, для которых sql не является основным инструментом
Я сказал "более основной" :) Не знаю, может мне попадались не все категории людей, но я практически не встречал пользователей, которые бы плохо знали SQL, но при этом активно им пользовались. Точнее, я такого встретил в единственном экземпляре.

stenfу меня есть подозрение, что стоит мне поработать с Оракл, и я тоже начну ценить mssql'ое отличие null от пустой строки ;)
Все может быть, но не думаю. Впрочем, не вижу смысла поднимать здесь обсуждение еще и этой темы.

stenfВас кстати, не смущает что равенство null и пустой строки вообще-то противоречит определению null ?
"Смущать" меня это определенно не смущает. Я это знаю и рад, что Oracle в данном случае сделал правильный выбор. Если посмотрите другие мои сообщения в форуме, увидите, что я сторонник таких точек зрения, как

Сделанные ошибки нужно исправлять, поддерживая совместимость сколь возможно, но не оправдывая продолжающуюся глупость совместимостью со старыми багами

и


Стандарт - дело хорошее до тех пор, пока стандарт хорош. Там, где стандарт плох, стандарт идет в баню.

stenfПо поводу того, что в mssql в unique столбце разрешен null, но почему-то только один - да согласен, нелогично.
Это не то что "нелогично", а в первую очередь ровно так же противоречит стандарту. Почему и упомянул здесь, чтобы показать, что нарушение стандарта не является ноу-хау оракла :)

stenfХотя не помню, что-бы это мне приносило какие-то неприятности, возможно просто повезло
Это не то что приносит неприятности... просто в результате становится практически невозможным наложить unique constraint на nullable поле. Скажем, тот же ИНН - как мы говорили выше, его может не быть, но уж если он есть, он должен быть уникальным. Чтобы реализовать такое с помощью mssql-ных unique, придется извращаться, например таки вынести в отдельную таблицу.

stenfЕсли вы еще раз загляните назад, то увидете, что уже после null, я привел пример множественного наследования и указателей, что вы затем обозвали стандартным подходом программиста на VB, и сказали, что предпочитаете другой подход - брать тех, кто разбирается в этом.
Да, сказал.

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

Я в свое время играл в гандбол и нежно люблю эту игру, но есть одна проблема - на серьезном уровне требования к гандболистам примерно как к баскетболистам, а у меня рост 167. Даже на малосерьезном уровне, играя против много более высоких оппонентов, мне приходилось действовать по собственной тактике, "не по-книжному".

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

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

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

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

stenfЗато мысль, что структура и алгоритмы программы должны быть как можно проще и понятнее - имеет некоторую смысловую нагрузку.
Смысловую нагрузку эта мысль имеет, вот только она неверна :)))

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

Я бы сказал, для разных задач существует разная степень "оптимальной простоты". Скажем, для очень простых задач клиент-серверная архитектура неоптимальна, старое-доброе "все на клиенте" проще и не хуже. Но для более сложных задач - становится "проще и хуже", а потом так и "сложнее и хуже".

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

stenfда, но помнить о необходимости isnull(), coalesce() и пр. вещах ведь тоже надо.
Ээ.... мне изменяет память или это "почти синонимы"? То есть всех прочих вещей в первом приближении одна штука :)

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

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

"Типично" в данном случае - по моему опыту, включающему в себя работу с изрядным количеством разных БД, спроектированных разными людьми.

stenfПо сути, вопрос в том, какой подход проще, и вы уверены, что с null ?
"Уверен" - да. Поскольку уверенность статистическая, передать ее трудно - почему я и ограничился примером и "утверждением на правах мнения" что именно такая пропорция сложности типична.

stenfА почему "в деталях лежит нулевая сборка и только она" ? В деталях лежат все сборки, включая нулевую.
Ээ... боюсь, по указанной в первом письме структуре я этого тем более не понял.

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

stenf softwarerСистема никогда не может удостоверить корректность введенных данных, она может удостоверить только "явную некорректность". Остальное на совести вводящих.

Но какое отношение это все имеет к постоянным/временным null? Чем логический парадокс для одного отличается от логического парадокса для другого?

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

stenfНапример есть таблица летательных средств, содержащая самолеты и вертолеты. У вертолетов среди прочего есть аттрибут "количество лопастей", а у самолетов "размах крыла". Соответственно, для вертолетов у размаха крыла будет null (и не простой null, а перманентный, т.е. такой, который там по логике физической реальности ;) никогда не может появиться). Теперь, если случайно там все-таки возникло число, то в запросах "покажи все самолеты с размахом крыла 10 метров" появиться вертолет, что может например привести к аварийному завершению работы клиента.
И таки правильно в ответах упомянули винтокрылы, хороший пример на тему соответствия реальности, бизнес-правил и прочего :)

Однако, оставим их в стороне и по сути. У Вас здесь есть один тонкий, незаметный переход, играющий важную роль. Если у Вас запрос "покажи все самолеты", то вертолет туда не попадет. Почему - потому что в запросе так или иначе будет фильтр "на самолеты". Скажем, "... and construction_type = 1". В случае с пристыковочными таблицами фильтром может выступать join, скажем, "Летательные_Аппараты join Атрибуты_Самолетов" дадут фильтр по самолетам. Если же запрос к "летательным аппаратам", появление там вертолета нормально.

Теперь давайте подробнее про фильтр. Если используется поле типа или нечто подобное, с этим все просто. Допустим, Вы решили использовать атрибут "размах крыла" как признак самолета, и пишете запрос примерно как


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


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

И вот теперь давайте посмотрим с другой стороны: как Вы собираетесь обеспечить проверку аналогичного правила, если Вы вынесли атрибуты в отдельные таблицы? Есть ли у Вас простой способ сказать СУБД, что "расширением к ЛА должны быть либо атрибуты самолетов, либо атрибуты вертолетов, но не те и другие сразу"?

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

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

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

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

Про исчезнувшие строки, надеюсь, разобрались, я полагаю соответствующий аргумент дезавуированным. С лишними строками может быть очень много чего, варианты вряд ли реально перебрать. Скажем, запрос "покажи все самолеты с размахом крыла 10" типичен для пользовательских фильтров, динамического where и подобных задач. А там в большинстве случаев результат будет одинаков и в структуре с null-атрибутами, и в структуре с расширяющими таблицами (почему - потому что программистам чаще всего лень анализировать, нужно ли включать таблицу во from, они пишут безусловные join, а далее в where отсекают по введенным условиям. Это плохо, но это так).

stenfНекоторое противоречие: сначала вы говорите "Если бы был неудобным, придумали бы другую абстракцию", а затем "могло бы быть названо как угодно".
Если Вы видите противоречие, значит Вы не поняли, что я имел в виду. Или я плохо сказал. Я постарался максимально четко отделить ситуации "разные по сути абстракции" и "одна по сути абстракция, быть может названная тем или иным термином".

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

Не обязана абстракция быть понятной. Она обязана быть "удобной и при этом по возможности понятной".

FrankieПростите, а не кажется вам, что это действительно противоречит сути null?
Возникает вопрос, что есть суть null :)

Оно безусловно противоречит определению null из стандарта, и скорее всего из тех источников, на основании которых формировался стандарт. Что же до сути..... давайте я приведу пример, в котором определение null из стандарта очевидно неудачно. Это случай, когда в типе данных уже есть значение, "очень похожее на null во всем смыслах". Очевидно, что наличие второго null вызовет существенные неудобства, согласны?

Пустая строка, конечно, не совсем null, но как оказывается, в единственном случае, где они практически различны (конкатенация строк), null как раз не дает преимуществ, исключительно неудобства. Мало того, если подумать о таких операциях, как join по строковому полю (изврат, конечно, но раз уж взялись сравнивать - например по какому-нибудь артикулу или коду изделия) - окажется, что null-овское поведение пустых строк при join-е очень даже правильно.

FrankieВ Делфи строка s:='' и s:=nil делают далеко не одно и то же.
Вы в этом действительно уверены? А проверяли?

Ваше утверждение вообще говоря не совсем корректно, поскольку строка s := nil, например в используемой мной D7 является синтаксически неверной, но если сделать то же корректно, например s := PChar(nil), я уверен, результат будет одинаковым (если посмотрите в ассемблерный отладчик - увидите, что оба варианта сводятся к вызову системной функции LStrClr).

Frankie S естственно будет ''
Вот как? А попробуйте вот так: