On 7/15/2011 9:55 AM, David Mintz wrote:
Pondering how to approach a situation where the application needs to count on
a certain string to be in certain database rows in order to know what to do.
Without going into excruciating detail, let me ask if you think there are
cases where it's good practice to basically hard-code in some rows of a table
certain data that your application needs, and somehow mark them as immutable
-- at the application level, stop the user from touching them. Other rows in
the same table would be fair game -- they can add, modify and delete.
Comments?
Why not simply add a second table, one that is free game and one that is set
to read-only. They will have the same structure and technically the same
function, but the permissions are different. May not be the best approach, but
strikes me to be better than mushing it all into one table. Or is there a
technical need for this?
Then again, if those records are never to be changed by users, why have them
in the database to begin with. Some may disagree, but I think that anything
static has no place in a database. Put it in flat file somewhere or if it
truely is never to change hard code it.
David
_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/Show-Participation
