I've seen worse. Some teams use JSON for their data. Not only each field can be missing (aka NULL), it can also be "null". Or a different type.

I envy your team who's only mistake is to forget setting NULLABLE. Rainbows and unicorns ;)

▲

toledocavani 21 hours ago | parent | next [-]

Worked in an enterprise project where they use a BPMN engine for all business logic (designed by non-technical people).

Each process can either have predefined fields (take time to implement) or key-string value store (yes, they chose this).

Either the BPMN logic or some JSs (some, as not all people can code) in PBMN nodes or some Java hooks (a lot, wrote under those other people requests) edit those values.

So when something's wrong, we swam in the sea of key-value, search all the code for who update this field, and why it's value is not JSON nor null nor boolean but a string "Not used, waiting for policy 1234".

After that project, I'm happy every time I can use a DB to store data, more so if it can run in local, much more so if it's relational.

▲

lock1 a day ago | parent | prev | next [-]

What if almost everything is NULLABLE? including the supposedly primary key and foreign keys of the table?

I've had the firsthand experience building a consumer for that kind of DB and it's hell to get anything running correctly without literally writing a dedicated layer to sanity check everything.

	▲	gopher_space a day ago \| parent \| next [-]
		> without literally writing a dedicated layer to sanity check everything It's not attractive to developers for a variety of reasons, but encapsulation is generally cheaper (in every sense) than the alternatives by orders of magnitude. If a system is hard to alter and other people rely on it to do their jobs, thinking about it as set in stone during my planning process will save me grief and heartache. Starting with an independent client in mind makes it easier to plan around things like reconstructing tables from composed exports or dealing with authoritatively incorrect data. It's a good collection point for hard-coded edge case handling, and a great location for all of your discovery notes.
	▲	phplovesong a day ago \| parent \| prev [-]
		Sounds like a bad domain, and/or poor design.

▲

thomas-st a day ago | parent | prev | next [-]

That's just the JSON equivalent of "we have data, and it's null" vs "data is missing", and consistency could be enforced using a constraint or by making it non-NULL in the first place.

It's more common in string fields, which in many cases just get rendered on a web form that doesn't differentiate blank (empty string) from null state, therefore in the database we should in most cases set it up as follows:

- Value required: field should be non-NULL + at least length 1 (via check constraint)

- Value optional: either field is non-NULL, or field is nullable + at least length 1

I'm curious if you prefer to store optional strings as non-NULL and rely on the length, or as nullable and have a length constraint.

▲

antif a day ago | parent | prev [-]

No shame on JSON.. XML can do this too!