Yeah, I mean, an integer can definitely hold more data than a boolean.

If your data was simple enough, you could have an integer hold the entire meaning of a table's row, if every client understood how it was interpreted. You could do bitwise manipulations, encodings, and so on.

Sometimes it is nice to understand what the data means in the schema alone. You can do that with enums, etc.

  ate_an_apple_in_may_2024
  saw_an_eclipse_before_30

These are more of the sort of things I don't see needing enums, timestamps, integers...

▲ grey-area 5 days ago | parent [-]

I’ve never seen anything remotely like that in a schema and it seems inappropriate anyway - those should IMO be timestamps like saw_eclipse_at not booleans. You should not encode business rules in the schema (like certain magic dates) because those business rules always change over time.

▲

ZYbCRq22HbJ2y7 5 days ago | parent [-]

Yeah, need a bit of imagination to walk there with me, but you are saying just use `saw_eclipse_at`. That would require having knowledge of the entity's birthday, the date that the event occurred on, and so on, which in this imaginary scenario, we do not.

▲

grey-area 5 days ago | parent [-]

I would not store that in a schema, storing bday and date seen is much more useful so that when the business inevitably asks for saw eclipse at 50 too you can answer the question without adding a saw at 50 boolean. Bday is also super useful info for a business that cares how old someone is (as your hypothetical one clearly does).

Often the stated requirements of a problem are far too specific. Part of the job is system design is saying no to suggestions and finding the deeper constraints.

This example is a great illustration of why booleans are usually a mistake.

	▲	4 days ago \| parent \| next [-]
		[deleted]
	▲	ZYbCRq22HbJ2y7 4 days ago \| parent \| prev \| next [-]
		> This example is a great illustration of why booleans are usually a mistake. It is not. You are ignoring hypothetical constraints to bolster your own hypothetical argument, which is apparently some permutation of, "tell people they are wrong, and do some imputing of imaginary data. repeat until you have ideal 'system design'"
	▲	4 days ago \| parent \| prev [-]
		[deleted]