We need bigint for date since int has up to 10 digits and current unix time stamp (in milliseconds is 13 digit). But I think int would suffice for user and has 2 times less bytes.

Please see the users table... the id column is defined as id bigint(20) NOT NULL, so we should have the same here.

For policy table - are we sure 255 is enough and all characters will be UTF-8 valid?

I think so, this is just some string constant

I guess the thinking is that;

1. If the user has never accepted policies (before we run second migration described by @tomek here), then there is no row for them
2. If the user has accepted policies, but we change them by running the script in D5310, then the date will have the time of the old acceptance, but confirmed will be 0
   • If we want, we could consider updating that diff to also set date to NULL, but I'm not sure how important that is
3. After the user has accepted the new policy, date will be updated to the time of the latest accept

Open to changing this but I think that's the reason for the current design.

Thanks for clarifying! That's exactly what I had in mind while implmenting

For now, I think we will query only based on user and policy so it's probably better not to add another index to save some resources