no no no
grep "foo.bar" finds all instances of the "foo.bar" message.
Yes, but if you have "x = 'my foo bar is here'", it may also pick up that message.
and in fact has some disadvantages as I have named
Very minor.
And the message tables can be used with other languages and systems.
Once the bulk job is done, changes will be minor and are best handled through existing revision control tools.
In my experience, vast change requests may come out of left field so that there is a lot of rework to be done.
And I certainly wouldn't give a bunch of people located off-shore access to a database used by the production system.
You don't give them database access, only access to a web application. And, it does not have to be a production system. Besides, why is file access safer than database access? A file system *is* a database, just not a relational one.
Something that large isn't using XBase, I can guarantee you. And they are bulkier and harder to use than resource files.
I am not necessarily talking about the production application language. One can build tools in a different language than final applications.
I must be high if I think that's better than a bunch of SQL select statements. And calling into a remote database for thousands of strings isn't practical.
You got it all wrong. Each message does not necessarily issue a Select statement.
Have you actually worked on a large-scale system? Say something with a few hundred tables, a million lines of stored procedures, and millions of rows of dynamic data? The kind of thing you're proposing introduces unneeded, unwanted complexity into an already complex system.
So we should chuck databases and go back to flat files to manage everything? How 1960's of you. The bigger the project, the more a database HELPS! Keeping tons of attributes in a bunch of hard-to-query and hard-to-find flat files is really annoyining.
How about this. We start out with a file-based approach. If message management becomes a headache, then we DB-tize the config file generation. Deal?
