title: How to avoid defining two extra tables for an object that can have only 3 possible values and is part of a many-to-many relationship?
body: <p>I tried to search this online but found this question quite difficult to formulate in a concise &amp; intelligible way.</p>
  <p>I am developing an application which enables users to choose from 3 types of authentications: Password, Finger Print &amp; Face Recognition. Each user may opt for multiple types of these 3 and I need to store their picks in a relational database. So theoretically, there exists a many-to-many relationship between users and authentication_types.</p>
  <p>I know this seems quite trivial and probably I am overanalysing things, but which would be the optimal way to model this at a relational database level? What I am trying to avoid but seems to be the only reasonable solution in a relational DB setting, is to create a table for login types (say LoginTypes) in which to store the 3 login types mentioned above and create an intermediary table for the many-to-many relationship (say UsersLoginTypes).</p>
  <p>What's frustrating a little for me is that for only 3 types of login, I need to create one table to store them and another one for the many-to-many relationship. And any time I want to get the login types chosen by a user, I cannot simply select the user and extract the login types from the user's object, but I need to make a query that involves two another tables (LoginTypes &amp; UsersLoginTypes). Do I miss a simpler solution here?</p>
  <p>I thought of maybe assigning each login type a digit (eg. Password - 1, Fingerprint - 2, Face Recognition - 3) and have a field in the User's model for the login types, where to store a string containing the digits corresponding to what the user chose. And eventually, this is perhaps what I would go for if no better solution exists.</p>
  <p>PS. I am using Ruby on Rails with ActiveRecord, if this changes something.</p>