Surprising that everyone has failed to mention that serializing data and stuffing a representation of multiple values into a single column breaks first normal form. Generally speaking you should not be serializing data and tossing it into a single column. What happens when you want to filter entities by specific amenities? I will tell you what if your not the person who has to deal with that problem the person who does will curse your incompetence. There are only very rare cases that multiple values should be stuffed into a single column and even those instances would be debatable. Read up on proper normalization so you don't end up like one of the many posters on this very forum dealing with a problem later down the road that is the result of not properly normalizing the database. If you need some help I'm sure people over in the database section of the forum will set you straight. Especially if you believe first normal form is insignificant.
Instead of saving the selected values as plain text in the db, I would suggest to store them as a serialised array, since it's going to be more flexible. When you retrieve them, you can unserialise them, and search in them for the value of a specific checkbox. If it's present, you can mark it as selected.
Never mind… I see where you got that idea from. Completely ignore this. On the contrary serialized data in a relational database schema is a nightmare to manage. Especially when it comes to filtering, aggregating, and sorting by segments data stored within the serialized array that would be better off represented with 1:m or m:n relationship.
In this specific case it would seem appropriate to use a m:n relationship. One table for the amenities and another to relate an amenity to another table (entity). I've dealed with my fair share of real estate system in all cases this is how the data is stored in the simplest forms – not serialized arrays.
You could even use surrogate key of the amenity table if that is what floats your boat but I do prefer using surrogate keys for many reasons. This architecture is now flexible enough to filter, sort, and group by specific amenities. Where as serializing crap and throwing it into a single column will be a gigantic clusterf**k down the road in regards to performance, accuracy, flexibility, and maintainability.
I know there are always exceptions but in general never serialize data and toss it into a single column. Especially, when you are just starting out. Once you know some of rules and what not than perhaps in some cases where a lot of magic is needed it is "ok"… ish.
Also, in this day and age if you find yourself working a lot with key/value pairs than perhaps a relational database is not the best option. Perhaps a NoSQL storage facility is better like MongoDB. Something to consider.