[martimoose]

I also meant that either way, I would not grant a end user the possibility to modify the data structure, be it through the modification of the schema, or through the addition of an EAV definition.

Granted one is more dangerous than the other, but to me it's no reason to give them access. It's still a headache.

If only the developers have access to modify the structure, the way it is done is not important (it can be done through a webform that alters a database, though the addition of a json definition, through coding, etc.) After all, you can modify the schema through PHPMyAdmin. It's some kind of admin interface. You just don't grant your users the right to do it. Just as you don't grant them the right to add custom fields, unless they know what they are doing, which is seldom the case :)

I think that EAV gives a false sense of security, in that it does not "break" much if done by a non-knowledgable user. But still, if it is done badly, good luck reconciling the data.

[emodendroket]

"Reconciling" the data isn't my job; the user can use the custom fields for whatever they want.

It's certainly true that life is easier if you never implement certain kinds of features but at that rate why make a program at all?

[mason55]

> "Reconciling" the data isn't my job; the user can use the custom fields for whatever they want.

I disagree strongly here and see this attitude a lot. It's easy to say "not my problem, you fucked it up, you fix it" but that is a very customer-hostile attitude.

Instead we should be giving users functionality they want in a way that prevents them from screwing things up through a combination of feedback and constraints. Sure, if a user types in blatantly incorrect data there's not much you can do. But you can do a lot more than say "here's a narrow ledge and a pit of snakes, if you fall in it's not my fault". This just results in unhappy customers who don't care whose fault it is, all they know is that your software ate their data.

[mgkimsal]

> I disagree strongly here and see this attitude a lot. It's easy to say "not my problem, you fucked it up, you fix it" but that is a very customer-hostile attitude.

Very in agreement here. Almost without fail, if they knew enough how to 'fix' it, they wouldn't have fucked it up in the first place.

Much of this attitude depends on org structure. Are you talking about paying end-customers? Or joe in accounting 3 doors down who consistently never follows any directions you give him re: data?

[emodendroket]

I mean, I realize this discussion is abstract, but I can't think of a lot of ways I could possibly enforce normalization on data when I don't even control what the fields are.