Sgt.Pepper4213 + null = null (не удобно)
Это действительно неудобно, но проблема в том, что никакой другой вариант удобнее не будет. Рассмотрите практические примеры арифметических выражений, какую-нибудь себестоимость, и получится, что в ситуации, когда один из аргументов оказался null и был воспринят как 0, будет получен неверный результат, неверное число. Последствия в этом случае будут самыми отрицательными, хуже, чем если бы получился null.

Правда, из этого правила есть исключения - агрегатные функции, например sum.

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

Также я говорил и о другом моменте, о join-е. join по условию 0=0 представляется вполне разумным, естественным для любого ключевого поля, join по '' = '' - сомнительная, очень сомнительная операция. Наверное можно придумать пример, где он пригодится, но в массе он скорее приведет к проблемам.

Далее, сортировка. Допустим, я пишу select * from table order by field nulls last. Если field строковое - перенос пустых строк в конец не выглядит безусловно неверным. Чаще пожалуй будет верным. Если field строковое - порядок сортировки -2, -1, 1, 2, 3, 0 будет.... противоречащим нормальным представлениям человека.

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

И так далее.

4213 + 0 = 4213 (удобно)

Sgt.PepperЭто я пытаюсь следовать Вашей логике "как я ее понял". И пусть стандарты идут лесом :))
Я вроде бы говорил о рассмотрении ситуации в совокупности. Включая, кстати, клиента - на клиенте различие между null и '' довольно неудобно отражать в интерфейсе В совокупности "0 как null" представляется мне крайне неудобным - я, кстати, работал с системой, где использовали этот принцип, а "пустая строка как null" представляется удобным. И действительно, пусть плохие стандарты идут лесом.

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

Александр ФедоренкоЦена не задана, т.е. не определена, т.е одно и то же.
Нет, это не одно и то же. Это Вы сказали "то есть" на то, что синонимами не является.

Александр ФедоренкоЦена есть как свойство товара,
А кто сказал, что цена - это обязательное свойство товара? Нет ее. До тех пор, пока не придет кто-то и не скажет, быть может произвольно, быть может на что-то опираясь: "цена такова". Вот допустим Вы прямо сейчас взяли молоток, пилу, доску и сделали табуретку. Какова ее цена, которая есть как свойство товара?

Александр ФедоренкоЭто надо принять как есть.
Кому надо, и зачем?

Александр ФедоренкоА неудобно кое что делать на потолке, как известно.
В том числе и это. И если стандарт загоняет на потолок - стандарт идет в сауну.

Александр Федоренко1. В данном случае я сказал :) Проверил на СУБД, с которой работаю.
Я могу прямо сейчас проверить на трех СУБД и если не изменяет память, получить три разных результата :)

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

Александр Федоренко softwarerЭто неправда, причем заведомая неправда, противоречащая стандарту.
Сэр, не кажется ли вам, что вы меня обвинили в преднамеренной лжи?
Нет, не кажется. Я не вижу ни слова про "преднамеренную" (преднамеренную - означает "Вы знали, что это неправда, и осознанно ее опубликовали").

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

Александр ФедоренкоЭто правда применительно, как минимум, к реализации логики в Информиксе.
Судя по документации Информикса, это неправда применительно к реализации логики в Informix. По крайней мере, по той документации, в которую я ткнулся (на сайте IBM предлагается много разных информиксов, и я не в курсе, какие между ними различия, взял тот, который выглядел посвежее). Итак, смотрим в http://publib.boulder.ibm.com/epubs/html/25122850/sqltmst62.htm#idx207 Читаем:

документация по InformixA Boolean expression evaluates as true or false or, if NULL values are involved, as unknown.

Александр ФедоренкоН а абсолютную правду претендовать я не имею привычки :)
В этом случае в "непривязанных к СУБД" топиках это следует отдельно оговаривать. Если бы Вы сказали "В Informix любое сравнение с null дает false", я бы крайне удивился, но ограничился бы констатацией факта, что в стандарте и в других СУБД принят иной подход.

Александр ФедоренкоКстати, вот что я нашел относительно стандартов и Оракла:
Во-первых, не надо приписывать это достижение мне. Во-вторых, если коротко, текст детский; "похожий на правильный по сути", но содержащий много неточностей.

Александр ФедоренкоА здесь вы сами подтвержаете мои слова: не прошло ни одно из сравнений перемой со значением null )
Если бы написано было без смайлика, я был бы уверен, что Вы просто не поняли приведенный код. Смайлик вызывает подозрение, что поняли, но не хотите это признать.

FrankieНо, и это также известный факт, всерьёз думали над тем, чтобы сделать 3х значную логику (- / 0 / +).
Не логику, а арифметику. Троичная система счисления в некоторых аспектах удобнее двоичной, в частности она более эффективна с точки зрения хранения данных и позволяет обойтись без дополнительного кода и подобных извращений при работе с отрицательными числами. Ну и пришли к этой идее чуть позже; в 30-е годы делали, например, .... ладно, не помню как назывался этот чудо-арифмометр, так что опустим.

FrankieИ ещё, я читал (не исключаю, что это ерунда), что машина зависает в случае появления такого 0.
Скорее всего, имеется в виду то, что элементная база не позволяла сделать три четко различимых состояния, и "нечетко интерпретируемые пограничные значения" были естественным и неодолимым источником ошибок, по сути сбоями памяти.

FrankieНу, повеселили!!! А ну-ка давайте спросим у пользователей - "что такое NULL?".
Вы всегда приплетаете нечто, имеющее косвенное отношения к обсуждаемому вопросу? Сначала к обсуждению сервера приплели клиента, теперь к замечанию о клиенте - пользователя. Следующим, видимо, будет стул, на котором пользователь сидит.

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

FrankieНа клиенте должна быть возможность трактовать бдшный NULL так, как хочется, только и всего.
:) Высказывание сколь верное, столь и непродуктивное. Из серии известного "на воздушном шаре".

"Должна быть" - может быть. Из всех возможных трактовок есть более и менее удобные. Более удобную - я назвал.

Александр ФедоренкоКак мне кажется, интересная статейка на тему NULL
Факты изложены точно и хорошо. В рассуждениях и трактовках мне не нравится один момент: сквозит несформулированный, но явно видимый постулат "null рассматривается как такое же значение, как и любое другое". Особенно ярко это видно во фразе "Один приемлемый метод для избежания использования NULL-значений — применение фиктивных значений для обозначения отсутствующих данных. Например, вместо NULL в символьных столбцах можно применить строки «N/A» или «NV»." - с моей точки зрения, за такие советы надо отрывать голову, и постулат в целом представляется мне неверным и опасным.

FrankieВы всё время пишете "в сауну стандарты, если они неудобны".
Точно так.

FrankieЭто весьма животрепещущая для меня тема! Но как определить, достаточно ли я квалифицирован, чтобы брать на себя ответственность плевать на стандарты?

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

Требование атомарности вызвано тем, что "SQL сам по себе", реляционная теория в том виде, в котором она вводилась, не обладает адекватными средствами работы с неатомарными данными. Скажем, если у Вас в символьном поле хранится список значений через запятую, у Вас нет возможности сделать join со смыслом "те строки, в списках которых есть общие значения". Не знаю Postgre; в том, что касается Oracle, его расширения SQL позволяют выполнить все необходимые операции с nested tables, а потому "нарушение ими атомарности" представляется мне не разрушающим теорию. Точнее, я бы сказал, атомарность следует рассматривать именно в этом смысле - "данные, для работы с которыми есть адекватные встроенные средства". Ну и здесь еще следует помнить про потребности задачи - скажем, возможно, Вы не можете наложить на массив ограничение уникальности. Но если Вам не нужно его накладывать - какая разница, можете или нет?

Другой момент, также относящийся к Вашему примеру - реляционная теория не учитывает один тип полей, имеющий довольно широкое распространение. Это memo, lob, xml и прочие подобные поля - не участвующие в реляционных операциях, поля, единственный смысл которых - храниться в базе и предоставляться по запросу, поля, возникающие только в select-списках запросов. Теория этого прямо не оговаривает, но добавление таких полей не приводит ни к каким теоретическим неприятностям, если ваши массивы отвечают этому ограничению - ну и почему бы нет? BLOBы в противном случае тоже противоречат реляционной теории, однако почему-то повсеместно применяются. Скажем, jpeg обычно хранят в базе в виде файла, а не в виде таблицы координат и цветов точек :)

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

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

2) Одна голова - хорошо, но и другие могут подсказать полезные мысли. Подчеркиваю, именно подсказать. Обдумывать все равно нужно самостоятельно. Да, безусловно есть риск старательного идиота, который все прочитал, долго думал и придумал бред. Это риск руководителя проекта или заказчика, который поручил работу идиоту. Но риск тупого расшибания лба - имхо более весом.

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

3) Надо помнить, что принятые ранее решения могут быть ошибочными. Надо не бояться сменить точку зрения, в том числе перепроектировать или переписать что-то реализованное.

FrankieВозможно Ваш авторитет даёт Вам право говорить "удобную", не уточняя "мне удобную", но удобство - субъективная вещь, согласитесь.
Читайте оригинал:

softwarerС точки зрения клиента мне представляется наилучшим , если клиент имеет адекватный инструмент, клиентский null.

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

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

stenfЧто-то я тоже не очень понял ваш ответ. Заменить деталь новой будет означать:
1) Создаем новую деталь
2) Ищем в нескольких таблица ссылки на старую деталь и update’им их на новую
Почему в нескольких?

Если замена идет в одном месте, в одной сборке, значит update-им одну строку одной таблицы. Если замена идет в "нескольких из многих" - меняем несколько строк, скорее всего в одной таблице.

stenfЕсть дерево структуры изделия – какие сборки куда входят. Или вы про что-то другое ?
Про это. Возможно и есть, но в первом посте темы оно... как минимум не очевидно. Можно предположить, что у Вас IDСборки есть ссылка на таблицу деталей, если так, дерево становится видным, но это повод пересмотреть стандарты именования :)

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

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

stenfОднако случай “заменить все диоды серии 12345 диодами серии 12346 для всех изделий” маловероятен. Т.е. конечно такое может произойти, но это лишь частный случай общего бизнес-правила, говорящего что изменения могут касаться произвольного числа первоначально идентичных изделий.
Это более простой частный случай, но Ok, давайте сосредоточимся на описанном Вами более сложном.

Итак, непомнюкакому заводу были заказаны 20 самолетов Ту-4 - опытная партия. Сделали первые три, облетали, по первоначальным результатам решили сразу внести в остальные некоторые изменения. Имхо вполне обычная ситуация, которая должна закончиться тем, что в базе лежит заказ на три самолета конструкции 1 и на семнадцать самолетов конструкции 2. Далее, изменения, сами понимаете, были не очень велики, поэтому обе версии конструкции допустим, отличаются в 5% мест. Имхо вполне естественно иметь в базе 95% общего и дважды по 5% - различий.

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

stenf1 вариант) Если винтик не уникален для изделия (как вы советуете), то для случая замены винтика “везде” потребуется изменить только одну строку, а для замены винтика “в половине изделий” потребуется создание новых винтиков для половины изделий и проводки соответствующих изменений.
Нет. Потребуется создать один новый винтик и проапдейтить по строчке в половине изделий.

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

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

stenfПо поводу “присобачить к корню”.
Это неудачная мысль, пожалуй не стоит ее обсуждать.

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

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

Печально..... не вижу правда, почему в результате именно я в глупом положении, но давайте считать, что Вам виднее.

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

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

stenfПо поводу удачно/неудачно написанного кода для mssql - тут имхо надо ставить вопрос шире. Не зная подробностей, могу предположить, что чуть более медленный автомат лучше, чем чуть более быстрый но зато более сложный “ручник”.
Я не ставлю вопрос, я отослал к подробно обсуждаемому примеру. Если посмотрите, увидите, что разницы в сложности никакой. Что же до лучше-хуже, вопрос в количестве применений. Для запроса, который в течение жизни системы применяется, например, 100.000 раз, требования к оптимальности одни; для запроса, который выполняется, например, 40.000.000 раз в неделю, требования к оптимальности другие.

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

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

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

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

stenfВы напрасно смешиваете понятия “принимать в команду недомерков” и “писать понятный код”.
Вы напрасно не понимаете приведенной аналогии.

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

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

Пример хорошего, правильного подхода: вопрос, ответ, результат. Хотя я почему-то подозреваю, что Вы этот пример не воспримете.

stenfЭто разные вещи. Увеличивая относительную сложность кода вы в любом случае повышаете вероятность ошибок, даже если набрали команду Эйнштейнов.
Вы забываете про одну мелкую, но важную деталь: "относительная сложность кода" - вещь субъективная. Сейчас уже не найду, но здесь же, в проектировании некоторое время назад был совершенно замечательный пример - там человек хотел нагромоздить целый механизм, что-то типа асинхронной обработки путем цепляния на cron батника, выполняющего какие-то скрипты, и все из-за совершеннейшего с моей точки зрения пустяка, уровня нежелания написать сложный с его точки зрения sql-запрос. Для него "запрос" было сложно, а "вот эта неустойчивая механизьма" - просто. Я - так совершенно уверен, что его решение куда более ненадежно, чем даже им же написанный запрос.

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

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


Скажете, этот код сложнее? Нет, ему так было проще. if - более простое понятие, чем например "массив".

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

stenfЯ не могу спорить с такими аргументами как ваш опыт. Он больше и вам виднее.
Понимаю. В силу субъективности этого опыта я стараюсь его не выпячивать, как-то разъяснить, из-за чего получается именно так.

stenfВсе-таки мне кажется, что есть некая разница. Для того, что-бы появилась неверная дата смерти человека, в случае выделения “смертельного” столбца в отдельную таблицу – должен произойти insert. В случае null – вероятность появления этой даты может быть выше, так как к этому может привести неверное задание условий where в операторе update.
Неправильное значение может появиться из-за неверного where в update. Неправильная строка может появиться из-за неправильного on в merge или where в insert..select. В чем разница?

Кстати, вот еще merge. Снова "дополнительные сложности, которые надо изучать" там, где вполне можно обойтись if - exists - update - insert.

stenfВообще-то мне казалось, что реализация тип/подтип будет проще и понятнее, чем куча check’ов. Представляете, если подтипов ЛА штук 50 ? Замучаетесь эти чеки писать и сопровождать. С другой стороны, подтип более понятен.
Я не очень понимаю, с какой стати я замучаюсь писать и сопровождать check-и, если это забота CASE-средства. Моя забота - нарисовать дугу в ER-диаграмме. Впрочем, даже если и надо будет писать руками - .... Вы всерьез полагаете, что аргумент "замучаешься писать foreign key-и" достаточен, чтобы не делать в БД никаких foreign key-ев? А ведь ситуация та же.

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

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

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

ModelRХотел ответить, но уже отвечено:
Не согласен принять такой ответ без уточнений. Чем, по-Вашему, код


лучше, нежели


? Второй, однако, спокойно обойдется без null.