I have started using a third party reporting application (PHP Report Maker 9, which I love by the way). I’m trying to figure out how to populate ENUM values from the keys. I have to think there is a table, somwhere in the database, with a list of keys, values, languages, and drop down names, but darned if I can find it.
The goal, obviously, is to join that table into my result set so that I can see the values rather than the keys as a result of my query.
If you consider the extensibility of SugarCRM, the possibility of add-ons, the Studio where you go and change the app, the language packs with different messages for users logged in in different languages, etc., I’m not so sure it’s not a good idea to do it like this. Think of how much database access you’d have for everything that’s going on in the app.
This might be a perfectly defensible architecture. I’m not saying it is the best possible, I’m just saying it’s not easy to quickly discard it as something that sucks. : - )
I will agree to disagree. Any sort of access to this information or modification of this information would be faster and have less resource impact via database calls that reading/writing text files. Especially when so much information comes from the database on every single page where this data is used.
Are you proposing that, when you rebuild, these values are coded into the php that serves the pages? I guess that would be faster. I haven’t looked at the code to see if that is what happens or not. It seems unlikely, considering I don’t have to rebuild to update dropdowns…
SplendedCRM, a complete rewrite of SugarCRM on .NET framework, does this through the database. And when using 3rd party reporting, it sure is nice.
Anyhow, I appreciate that you answered in the first place, and I respect you perspective.