Database question: 60 boolean fields + string:list or all string:list?

[Management Backoffice]

App has a venue listing feature. Many boolean fields (let's say it's 60, not sure whether it'll be 12 or 30 or 60, so I'll guess high) exist from the start: Has pool, has changing room, has washer/dryer, etc. These will be part of the model schema for  venus.

On top of that the user will be able to add features not there, in a tag cloud format using string:list (I assume that's the best method for freeform data of this sort). So for example, you can add tags that say 420-friendly or piano

Goal is for a client searching  to find both of them. If I search for pool and piano both, it should return your venue that uses the existing boolean for pool, plus your added string:list for piano.

Should I just make it all one giant string:list for the built-in options and another string:list for the indivdual's added options or what?

At best this site will have thousands, not hundreds of thousands, of venue listings, and not too many clients. I assume performance won't be a huge problem either way, but I'd still like to stay efficient. I just don't know which is better, or if I'm missing a third option.

[Anthony]

If performance is not likely to be an issue, two list:string fields might simplify the logic. You could even combine them into a computed field for easier searching.

Anthony

[Management Backoffice]

Thank you, Anthony. I will mull over the computed field idea, which I've skirted over in my web2py reading. I don't quite understand it & think it's time to hit the books again.

[Leonel Câmara]

> On top of that the user will be able to add features not there, in a tag cloud format using string:list (I assume that's the best method for freeform data of this sort). So for example, you can add tags that say 420-friendly or piano

There's your answer. Forget the 60 boolean fields and just have tags.