NYCPHP Meetup

[David Krings]

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