It's a matter of presentation. Frankly speaking, after going through the "how do we consolidate tags into something consistent" for Scimitar, I'd say that of any large group of readers and writers... about half will go along silently, of whom you'll find out a significant chunk didn't actually like it but preferred to grumble amongst themselves. The remainder will be split into a vocal group that loathes it, and a vocal group that loves it, and if you're really lucky, no one will start slinging privilege about loving it versus the oppressed who hate it.
But the presentation is key, it seems. To explain, plainly and simply, that databases just cannot have multiple tags in every direction if the information will be easily and quickly findable does shut up most of the complaints. It's not something negotiable, really, when it comes to setting up a database to be efficient: consistency is key. Present it as, "do you want the tags to find results quickly and easily, or do you want the site to crash and/or your browser to freeze while the server chugs through sixty extra tables"...
People quickly realize that the trade-off is NOT between "speshul snowflake tags" versus "we are the OPPRESSED tag-users"; it's between "efficient and reliably quick search results from a well-organized database" and "mass chaos, dogs and cats living in sin, servers crashing, readers who can't find jack and won't stick around for a second attempt". Or, at least they realize that once you present those as the real options. And draw a line, and make an executive decision. This is not something I'd put up for a vote. It's a boundary set by intelligent developers and their managers, and like boundaries, is there for everyone's good and not something that requires anyone else's permission to negotiate. There's plenty else to negotiate on (like, say, the UX of your UI), but the database design? No.
The developers -- if there are any who, y'know, can develop -- are used to being the bad guys. Usually in most projects: sorry, dev says that just can't be done. Period. Have a workaround, but here, there may not be dragons but there will be a catastrophic database failure. Which is pretty much the same thing as terrifying monster just over the horizon, if you ask me.
no subject
But the presentation is key, it seems. To explain, plainly and simply, that databases just cannot have multiple tags in every direction if the information will be easily and quickly findable does shut up most of the complaints. It's not something negotiable, really, when it comes to setting up a database to be efficient: consistency is key. Present it as, "do you want the tags to find results quickly and easily, or do you want the site to crash and/or your browser to freeze while the server chugs through sixty extra tables"...
People quickly realize that the trade-off is NOT between "speshul snowflake tags" versus "we are the OPPRESSED tag-users"; it's between "efficient and reliably quick search results from a well-organized database" and "mass chaos, dogs and cats living in sin, servers crashing, readers who can't find jack and won't stick around for a second attempt". Or, at least they realize that once you present those as the real options. And draw a line, and make an executive decision. This is not something I'd put up for a vote. It's a boundary set by intelligent developers and their managers, and like boundaries, is there for everyone's good and not something that requires anyone else's permission to negotiate. There's plenty else to negotiate on (like, say, the UX of your UI), but the database design? No.
The developers -- if there are any who, y'know, can develop -- are used to being the bad guys. Usually in most projects: sorry, dev says that just can't be done. Period. Have a workaround, but here, there may not be dragons but there will be a catastrophic database failure. Which is pretty much the same thing as terrifying monster just over the horizon, if you ask me.