Message of the day:
Welcome. Latest release: https://www.silverstripe.org/download Community Forum: https://forum.silverstripe.org Features: https://forum.silverstripe.org/c/feature-ideas Archive: https://slackarchive.silverstripe.org
If you have any SilverStripe related questions, please supply the version of Framework you're using.
Did you flush? 🚽 =
Archive temporarily at https://archive.codingplayground.nl (redirect)
I would, however, especially when using MariaDB or MySQL, stick to Enums for given sets
not so useful for
$db but definitely a useful way to work with enums
In short, Enum's are great, but only if you know the values will never ever change
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
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.
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
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.
Year, there's the
DBYear object to help you out, which is basically a slightly smarter int.
That's what I always do as well, except for in some cases where the data is stored/handled elsewhere like for an api