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

это не абстрактные философствования, а слегка модифицированный пример задачи с моей прошлой работы. Автоматизировался склад инструмента, по ряду организационных причин, при занесении номенклатурного номера инструмента оператор не указывал его тип, а выбирал из списка доступных характеристик те, что понравились и присваивал им значения. После сохранения в БД, можно было отобразить/редактировать данные определенного инструмента, соответственно высвечивались только те значения, которым было что-то присвоено. Задача была решена по-другому, но одно из решений было сложить все поля в одну таблицу, а затем для искомого номера инструмента выбиралась-бы строка и разворачивалась pivot'ом (null'ы при этом-бы отсеивались). Некоторые значения вполне могли-бы оказаться пустой строкой и подлежать заполнению потом (вариант не заполнять ее вообще, а когда понадобиться вывалить список всех доступных характеристик для выбора представляется гораздо более плохим решением). Соответственно, при неразличимости null и пустой строки такой подход был-бы невозможен
softwarer
Если Вы работали и в той, и в другой реализации - с интересом выслушаю Ваше мнение о плюсах и минусах. Если же нет - подчеркну, что "кажется" не всегда выдерживает столкновение с реальностью.

это надо понимать так, что у вас есть продолжительный и плодотворный опыт работы с обоими системами?
softwarer
Кстати, я не увидел в приведённом примере дефолтных значений. Может быть, конечно, и такая реализация, но увидел я всего лишь умное поведение для случая obj = null, сродни классическому дельфовому

нет, в дотнет value типы по определению не могут быть null. Т.е. никаких if obj = null then быть не может по определению. В последних версиях появились nullable варианты этих типов, но это по-сути новые типы данных. Однако, видимо из подобных-же рассуждений об абстрактном удобстве для сферического программиста в вакууме, в vb возможно присвоение этим типам nothing, что в реальности приводит к получению ими дефолтных значений, а на деле может привести к серьезным багам
softwarer
О, это один из тех вопросов, который отличает "теоретиков" от "практиков". Первые уверены, что нетрудно. Вторые, написав этот isnull() несколько десятков, несколько сотен или несколько тысяч раз, начинают любить теории других теоретиков, где не нужно заниматься подобной тупизной.

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

"Не то, к чему я привык" - вовсе не всегда "удобство", часто наоборот.
softwarer
А в чём разница, если null - пустая строка? Заменить nvl на nvl2 - и всего делов-то. С другой стороны, когда null - не пустая строка, простейшее выражение вида name || patronymic || surname превращаются в нечто нечитаемое.

перепутали автора цитаты, на которую отвечали :)