Let's start with one of the most important introductory steps for adding a new table and schema into our application—designing the database table. This isn't just about designing the table, because you don't want to just think about the database impacts of creating/adding a new table and shaping the data model for this table; you also want to give a lot of thought to how the data model will impact your application's design and structure over time.

We'll start by figuring out what questions our application is trying to answer in regards to our new users schema. First off, we ask WHAT information we want to store:

Users
-----
-* id
- username
- email
- encrypted_password
- active
-* inserted_at
-* updated_at

(* means it is a default column created as part of the Ecto migration process)

This design gives us the minimal amount of user information that we can comfortably store without asking for too much storing too little. To start, we'll separate the idea of the user's username and email from each other to provide a way for a user to change their email address in the system without affecting their login information.

Next, we'll store the email address for the user, because maybe someday we'll want to add support for emailing a user a link to reset their password or send them information about the polls they created. Maybe there will be some other thing we'll need down the line, like the ability to send them marketing emails to get them to use the site more or upsell some sort of premium memberships! The sky is the limit for us!

Then we have our encrypted_password field. This will not store a human-readable (usually referred to as the plaintext) representation of our password, but rather one that has been encrypted through an algorithm using some sort of internal secret key. We'll later introduce the concept of virtual fields later that we can use for things like the password and password confirmation values that won't actually get stored anywhere in the database but still need to be tracked in some temporary way by the application.

active will be used to determine if a user has been logically deleted (but not actually deleted) from the database. If we only logically delete a user, it will prevent weird scenarios later on in the life of our application where old polls and votes are attributed to some user that no longer exists with any sort of representation in our system anymore!

inserted_at and updated_at are timestamp columns that Ecto adds to most migrations and tables by default. These help keep track of when information in the database is either added or changed so that we can keep track of at least some form of basic audit information.