From the previous mockups, we can pretty comfortably design out what the schema for our chat information should look like. We'll want to store enough information to be able to rebuild the display when a user goes to the page, as well as information related to who said what and when. We'll stick with that to start since it is the simplest implementation:

table: messages
--------------------------
  id : integer, primary key
  message : string, not null
  author : string, not null
  poll_id : integer, references polls, nullable
  inserted_at : timestamp
  created_at : timestamp

We have the standard columns that are created as a part of every Ecto table (id, inserted_at, and created_at), so we'll skip those. The key fields in this implementation are message, author, and poll_id. Message is pretty straight-forward, so I don't think we really need to spend too much time dissecting that and what it's used for. It'll store some arbitrary length of string and it shouldn't be null (so that people can't just spam empty messages).

Next, we have author, another string. This one also disallows null values, since we should know who wrote what and when. Again, nothing too particularly tricky or anything. We're starting off with a very simple implementation here, so we're not tying a specific message to a specific user. We may end up wanting to do that for auditing purposes, but for right now, we'll stick with just storing the author as a string representation.

Finally, we have the poll_id, which is a reference to the polls table. This will help us link the message back to a specific poll so that we know which poll to display the message under. We need this column, in particular, to be nullable and not-required because we're also going to implement a chatroom lobby into our application.