Firesphere

I would, however, especially when using MariaDB or MySQL, stick to Enums for given sets

andante

not so useful for $db but definitely a useful way to work with enums

andante

we use https://github.com/marc-mabe/php-enum in our codebase - its a sick way of using enums in a non-DB way, and you can enforce them with strict types

Show 1 attachment(s)
marc-mabe/php-enum

Simple and fast implementation of enumerations with native PHP

Hide attachment content
Firesphere

In short, Enum's are great, but only if you know the values will never ever change

Firesphere

Another, more complex one, would be ages. If a client would want to select the age at signup, you can suggest "let's use the signup date plus the date of birth, to mathematically determine the age", removing the need for even having the age field

Firesphere

Examples of that, are clients being sure they'll never need more vehicles than cars, bikes and busses. You just, in the back of your head, know trains will come in to play, or taxis. So that's where a relation is the smart solution.

Firesphere

For anything that is not set in stone, a relation is 90% of the time the most sensible way to go, so you can give the client management if needed, and until then, leave it as be

Firesphere

An Enum is useful for a given set that'll never change. The order can easily be determined through an array of data. Things that shouldn't change soon~ish, are for example weekdays, months, or number of the week. For Year, there's the DBYear object to help you out, which is basically a slightly smarter int.

nils

That's what I always do as well, except for in some cases where the data is stored/handled elsewhere like for an api