Reason to not use nullable number in Oracle? Our company is interfacing with another software company for a joint project, and we were told that, if a particular value should not be displayed, we should pass in a -5000 (their arbitrary sentinel value); the reason is that no number column in their Oracle database supports null values, on the recommendation of their (now former) Oracle dev. This company also writes the vast majority of their code in VB6 (slowly transitioning to VB.NET, which is another topic for another day...).  Out of pure curiosity, is there any valid reason for this recommendation? I can't think of any on my side.

--- edit

Thanks for the feedback all. I posed the same question on CodeProject.com (link) and received very similar feedback. It appears the only time one could possibly begin to justify this practice is related to foreign keys, and I can state that they use no foreign keys anywhere in the system. The developer that made this determination (I used to work at that company) has significantly more experience than I, so I wanted to make sure there wasn't a valid reason for this before derision ensues.
Realistically, the requirement is crazy.  Like all great crazy ideas, however, it is probably based on a nugget of potential reasonableness taken far out of context by people that have no understanding of the underlying rationale.

It can be reasonable to design a database schema such that no NULL values are allowed.  If you do that, however, you are committing to a level of normalization where every non-required element is broken out into an separate table with an appropriate foreign-key reference back to the parent.  It's not often done in practice but in cases where it makes sense to do, there can be benefits.

If you are going to design a database schema such that no NULL values are allowed, it makes no sense to allow let alone require magic values to indicate that something is unknown.  That introduces all the problems that allowing NULL values has plus it adds additional code to check for the magic values that has to get repeated all over the place.  It makes no sense to develop an API that requires magic values to be passed in regardless of the database design-- if you're going to hobble your code with checks for magic values, you really ought not let that insanity propagate out to other systems.