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 On Wednesday, May 9, 2018 at 2:52:49 PM UTC-4, Management Backoffice wrote: > > 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. > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
