This is required by law.
I do not know why i have this value and the tax amount in the database,
but the payment percent and the number of days are hardcoded. I guess i
am such an inconsistent mess.
This is easier to read and requires less unit tests, but i only used
them in the new relations and fields for HEAD, because i do not see any
point on creating migrations just for that.
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.