Yes, but if you have "x = 'my foo bar is here'", it may also pick up that message.
grep "foo.bar="
And the message tables can be used with other languages and systems.And a text resource file can't? You're stretching.
In my experience, vast change requests may come out of left field so that there is a lot of rework to be done.Ah, your vast experience doing internationalized systems. I see.
You don't give them database access, only access to a web application. And, it does not have to be a production system.Ah, so now you're maintaining TWO databases for the sake of this labor-saving scheme of yours. Got it.
Besides, why is file access safer than database access? A file system *is* a database, just not a relational one.Because the changes are being checked in and managed by me, not the guy on the other end of the wire whose only talent is converting English into Swahili.
You got it all wrong.No, it's called "covering all bases" since you're being so vague about "might" and "doesn't necessarily" and so forth. You oh-so-conveniently didn't quote "And if you cache them, that's more coding and database maintenance overhead just to match the same functionality provided by resource files." So just exactly how does this system of yours work? Or haven't you thought it through properly? Does it issue a single select? "Not necessarily." Does it cache them on the first hit? Who knows. Does it cache them for each page? Can't tell you.
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.No, but they're damn nifty for internationalized messages. How very binary of you.
"hard to query" Er, no. Got grep or find? Got an editor? Everyone does. Better that than "oh, to work on the messages you need to set up ODBC like so, and install Access, and search for them here like this. Oh, wait, you wanted to see the messages in QA, not DEV? Well, you need a different ODBC source then..." Seems to me the database version is a lot more of a pain in the ass for someone who just wants to edit a bit of text.
"hard to find" Care to back this up? They're right there in the same place as the JSP files that use them, as opposed to way off in database land, completely unrelated to the code that references the messages. Seems to me the database version is a lot more of a pain in the ass for someone who just wants to edit a bit of text.
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?What's this "we", Kemosabe? Message management hasn't become a headache yet. You've not demonstrated that it will be, and given that you have no experience in the matter... and since I'm working on a system right now that has nearly 2000 similar text resource files, I'll keep my own counsel on that one, capicé?