In the last section we put together a first rough draft of our survey schema.
But the very end I was looking at this recipient's property right here and I was kind of wondering if
it was going to work out in the end for us or not.
So in this video we're going to talk about some considerations around the schema we've put together
so far and we're going to decide whether or not we'd really approach this the right way.
We're going to do this by pointing out two little deficiencies in the way that we've laid out our schema
right now.
And once we look at both those I think you'll have a better idea of how we're going to tweak this thing
just a little bit to make sure that it better suits our application.
So first thing I want to talk about is a very simple consideration and that is where do we store our
feedback.
So remember that same tire purposes entire application when the user clicks on yes or no right here.
We eventually at some point in time have to make sure that we update this record of this survey to say
hey someone clicked yes they like it.
Hey someone clicked No they don't like it and so on and so on over and over again.
At this point our survey has absolutely no property on it.
That would really be appropriate for saying OK we've got another yes we got another no we got another
yes.
And so on some thinking that maybe we should add in two additional properties to our survey model.
Ok so very simply named.
You're at the bottom.
I think that we should add in a property called Yes and that's a record.
Every single time that someone clicks Yes.
And then another one of no.
And that's a record every single time someone clicks.
No.
Both of these can be integer or number types.
We'll start them off at zero.
And then every single time we detect one of these clicks we can increment either yes or no.
Very similar similarly to how we handle the credits on the user model.
Earlier in this course.
So this is definitely getting us to making sure that we record feedback as it is provided to us.
But now if you look at what we have you'll realize that there might be a another little deficiency inside
of our model.
I want you to imagine for a second that a user opens up on these emails and then they click the Yes
button right here 20 times in a row or 50 times or a hundred times in a row.
Right now looking at our survey right here we don't really necessarily have anything that says hey a
given user has already provided some amount of feedback.
There's really nothing inside this flow that we've spoken about so far that somehow prevents someone
from clicking on a button multiple times just again and again and again.
So I think that we need to introduce some additional property to our survey model that somehow records
whether or not a given survey or someone who received this e-mail right here has submitted some feedback
to us.
Now as we start to think about this is very important to realize that we don't have a lot of identifying
information about the people who receive these surveys.
So how are we going to uniquely identify each one and then detect when a given person has voted and
less like discount any future vote that they do for a particular survey.
Well really the only piece of information we have to identify the people who receive these surveys is
the recipients list right here at present that recipients list is an array of strings which is really
not appropriate for storing any more information.
We can't like just put some arbitrary property on the string or something like that or like attach some
little character to it that says hey this person voted no there's definitely a better way of handling
this.
So here's what we're going to do inside of our recipient's property right here we are going to embed
a sub document collection.
So that is a term that is used by Mongo and Mongoose a sub document collection inside of this list of
recipients.
We are going to store a bunch of little models called recipients every single recipient will have one
of two will have two properties in total they'll have an email property that is the email that belongs
to them and then they will have a simple boolean flag of clicked clicked will either be true or false.
We can started off as false and then whenever a given recipient or a given person with a particular
e-mail clicks on a link yes or no we will flip that clicked flag over to true then any point in time
in the future.
Whenever someone clicks on the button we'll always check to see if the person just clicked on it with
the given e-mail has clicked on the button before and if they have discarded the vote otherwise do count
it.
So I think that this will be a reasonable way of approaching this.
So the only thing we have to do is figure out how we take care of embedding a set of documents like
this.
Well that's going to be its own little talk about exactly how we do this type of design with mongoose.
So how about we just pause for a minute on worrying about this recipient list right here and for right
now let's think a little bit about implementing these.
Yes and no counters.
So they're going to be pretty straightforward.
It'll be very much like how we put together the credits counter previously.
So let's take care of both those right now.
I'll flip back over to my survey's schema file and I'm going to add on a property of yes we want to
pass some configuration options to this thing specifically.
I want to give it a type of number and I want to default its value to always start off as zero.
And then we will do the exact same thing for no as well.
So we'll see a type of number and we'll default it at 0 2.
Okay.
So this is looking pretty good now that we understand exactly what.
Yes and No.
Properties are doing for us.
Let's take a break.
When we come back in the next section we'll talk a little bit about this sub document collection thing
and how we are going to make use of it inside of our survey schema.
So I'll talk to you in just a minute.