Question: I have a simple task to achieve and I don't know what's the best way of going about it.

I have a Listings table in my DB and I need to associate a list of specification which is a checkbox list the agent has to select.

The table looks something like this.
- id
- size
- type
- location

Now how do I go about storing the checkbox values?
Do I create a new table "Listings\_Specs" and associate each row with "Listings" table via "listing\_id" or should I keep it in "Listings" table and add additional fields to it.

I am using Laravel 4 by the way.

Answer: 
It's hard to tell your the best way to go without knowing the specifics of your needs. In general, it is better to create a new table and associate it with the "Listings" table via "listing\_id" like you mentioned. This gives you much more flexibility. Remember to index the "listing\_id".

Anther way to do it is by including all the checkboxes directly in the "Listings" table. You can add a column for each checkbox. This is the easiest, but least flexible way. If the number of your checkboxes changes over time, you have to keep modifying the table.

Alternatively, you can add one single field for all checkboxes. Each byte of this field represents a checkbox, so the number of bytes should be the same as the number of your checkboxes and with the same order (or you have to specify the order somewhere). This is a little more complex and is also not very flexible because you have to modify this field every time you change the checkboxes. However, the advantage is that you use one field which can be handy if you have many checkboxes. If you prefer more readability, you can use characters (i.e. 1 and 0) instead of bytes.

Example: Let's say you have 5 checkboxes, the "Listings" table will look like:

```
ID | specs
1  | "10110"
2  | "01100"
3  | "11100"
4  | "00010"
5  | "01010"

```

So, I'd go with the first solution that you mentioned, but it really depends your needs.
This totally sounds like the kind of thing they might want you to add more of in the future. I'd shy away from creating columns for each specification you plan on tracking.

Instead, it would be a good idea to create a new model called `Specification` with a many-many relationship to `Listings`.

Checked state would then be dependent on a connection existing between `Specification` and `Listing` via the many to many join table.