Herman Slagman wrote:
> Unless we are talking about massive amount of objects, I'd opt for data
> replication, it makes the child object self-contained *and* you can use SQL
> without any nasty stored procedures.
Do you consider calculated fields to be nasty in SQL?
> The most important thing is to keep the data in-synch, for that I use a
> generated method (UpdateChild) that propagates all property values to its
> children.
This doesn't sound any easier to me than using calculated fields to find the
parent values on retrieval.
> it also keeps track of any overridden values in the children through a
> Overridden array.
This is very interesting. I like it.
I see now a hybrid between my <property>Actual solution and yours.
I would still use the calculated properties.
But rather than having <property>Actual, I could just use the array as you did.
(I suppose it could even be multidimensional so that arrays could be overridden.)
> Do A.SetProperty("A","By A")
I think a big advantage of my technique is that this would be
S A.A="By A"
which is more conventional.
