On Thu, Jan 23, 2014 at 7:34 PM, Bizt <martyn....@gmail.com> wrote: > In the book it demonstrates very well how to sign users up, validate, etc. > Usually in my PHP apps I have a process of allowing the user to signup, then > they are sent a link to confirm their email address, then (from that link in > the email) they can activate their account. In the backend, I use two tables > - user_pending (for users who have signed up, but not yet activated their > account), and user (for activated users). I decided a while back that I > would use two tables as I didn't want the user table to get bogged down with > users who never activate their account. Perhaps this is not too important, > and I'm giving myself more work.
I agree with Fredrick that this is a very premature optimization, considering it will not hurt your tables at all and by the time it does you will know enough to partition or shard or both and even if it wasn't two tables is an excessive waste. To me the idea should never to remove a user if they are not "validated" but simply to limit their actions and annoy them (not by email, with a big ass annoying yellow box on the site,) which can all be done on a single table. We don't remove users (valid or not) unless they explicitly request (because it's only fair that if I collect data on them they have the right to remove it -- irregardless of what the law says it's a moral decision we make.) The moral of the story is that if you have one or two tables you are still going to have to hit the db to clean up if you need to clean up, why make it a separate table at that point when you can just adjust the where clause to check another column that is a boolean field? That's useless decoupling. > Anyway could someone perhaps comment on what is the most commonly practiced > technique for activating users - I'm assuming via email activation as this > is what I see most when I sign up for new apps myself. If I do this process, > should I use one table (user - with "activated" flag column) or two tables > (user_pending and user - when users activate, the row is copied to user). > Any comments welcome, especially if their is a newer better way to perform > this process. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAM5XQnyJ1u-b6S1q%2Bz07L3NpoejtgECDTuyFSpWs_%2BC7yF9U5A%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
