stuffhappensМне интуитивно понятно, что это плохо и неправильно (нужно использовать null), а вот аргументы, почему это так придумать не могу. Подскажите, чем плохо так делать и плохо ли?
Так делать плохо потому, что это вносит в систему большое количество дорогих в смысле последствий ошибок. Мне довелось полтора года работать с системой, написанной подобным образом, и за это время от трети до половины серьёзных проблем, которые я решал, было прямым следствием этой практики. То есть - при null-ах тот же код работал бы правильно.

Причина проблем в том, что условия вида a.id = b.id и a.id = :param дают false positives, ложные срабатывания при -1, которых не давали бы при null. По-хорошему, каждое условие связи в такой модели нужно довешивать проверкой на <> -1, но программисты постоянно забывают это делать, во всяком случае если пишут запросы руками. А дальше, даже если на момент написания кода работало без явных проблем, с учётом того, что бизнес-логика со временем модифицируется, начинаются всякие интересные эффекты. Ну просто ради примера, одна из проблем, которую пришлось разгребать:

а) На некую таблицу повесили триггер, обновляющий при её изменении денормалированные данные в другой таблице.

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

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

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

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

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

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