If the only difference is that some rows may have certain data elements updated and others can't, I'd say they belong in the same table (there are bound to be exceptions, but I can't think of an example).

Say you have a business rule that says element X is one of those which can (or can't) be renamed? Then someone high up changes their mind on that If they're all in one table, you have a flag which identifies this. You change it. Job done.

Now, think about the pain you've got if you have two tables and you have to switch the data from one to the other, updating all dependencies to keep referential integrity.

That could get painful by comparison.

Basically, if you see a fk which references two tables at the same time ... how does that work? It doesn't, if it's in one table it can't be in the other, so all your inserts to the child table fail.

If anyone replies to this with "Well you could triggers .. ", please just shoot them and do us all a favour. They're just trying to do something stupid to allow themselves to do something stupid.

If they suggest dummies in each table. Shoot them twice.

hth

Edit for clarity on one point