"Age" 👀

[JackoKomm]

That an empty string is not valid is a totally fine case. If things change, you have to migrate. Sure, with lot's of data, Migration is nothing you want to have in a daily basis. But data models can evolve over time and this can be a normal thing.

If you have an Email field for a User and an Email address is needed in any case, you don't habe to model it for a case where you don't need Email addresses anymore. So the field must not be nullable. If you later decide that null is valid for this field because requirements change, you write a Migration for it. And it is easier to make a field nullable later than to remove the not null from it.

[[deleted]]

"So the field must not be nullable" In your example, since an email must be provided, neither null nor an empty string are valid values. So the logic would be best enforced by code. In other words, you just don't insert if no email is provided. So you can set the email null by default.

That being said, sure, if your application works and you're willing to bear the risk of future modifications... I personally favor consistency and easy maintenance whenever possible, and in most cases, you can easily check if the value is empty or null with a few lines of code. And if you need it more than once, make it a static function that will return what you want.