Currently there will be no solution without tradeoffs. In most cases I tend to pick approaches which provides good UX and best convenience for the users.
To get something user friendly multiselect picklists doesn't come close. They give me a feeling of the year 2003, more than a few choices end up in scrolling tapestries and selecting+deselecting feels like crap. Fiddeling through 200+ fields will be a task for which the users are not likely to fall in love with you.
From the perspective of the datamodel standard (multiselect) picklists lead often to not normalized structures. Take the countries or languages for instance: it's likely you'll need them on multiple entities and you end up declaring them redundantly again and again with the challenge keeping them in sync. Dataquality r.i.p.
Actually fromthe UI perspective one of the better examples for a nice multiple picklist is the selection of tags here at SFSE:
- supports typing and auto complete
- perfect usage of screen real estate
- comfortable handling
- quite common and intuitive
To get this on a SF layout you need some kind of javascript. There are many to choose from. If you like jquery have a look on this
To keep the datamodel clean and normalized I strongly agree with @DanielHoechst to use custom objects. Expose an editable list page e.g. for language-choices only for admins. Reuse them everywhere. Add and maintain languages on a single place. Alternatively you can use Custom Settings instead. The overall implementation pattern will be roughly the same.
To fetch the choices you could use JS remoting
https://www.salesforce.com/us/developer/docs/pages/Content/pages_js_remoting_example.htm
To store the selected values on the object I would use a text(255) if possible (easier reporting but need for overrun protection plus limits) or you go for a longtext(128000) if necessary. Since the JavaScript is doing the aggregation, there is no need for a trigger.
Now how to get this most conveniently on the layout? And how on edit? This in the end is at the moment the hardest part. To get the custom JS integrated the solution to embed a VF page rules out: a separate save button is clearly not nice.
If you want to be a good citizen you end up in overriding the entire view and edit with vf-pages. apex:detail helps a bit to reuse layouts. But even that's quite radical, it's still best practice. From the admin perspective unfortunately not perfect.
If you're not afraid to get your hands dirty have a look at this
End of javascript sidebar workarounds? - eventually this would provide a solution to wire it nicely into the standard view and edit without VF override - but it likely won't last forever.
For the future all my hope is on Aura Components to get it done right.
Finally reporting is still an issue. But also is with standard multiple picklists. So having a text field with delimiters is not too bad either.
Best Answer
You're pretty much going to have to use one of those techniques as you need to split at least one of the lists into values to search for.
If you're concerned about complexity it seems to me that you should be using another method to do this search. Take the code you've got and wrap it in a nice utility function so that it can be called simply:
Then call it like so:
It seems you're worried about the wrong things, simple refactoring can take care of complexity and make code easy to read.
Also notice how you can simplify some of the code you posted by doing away with temporary variables (and also not creating a new list which gets discarded anyway):
Finally, if these are standard picklists you should be splitting on
;
, not on a comma (,
).