Antonio Gallardo wrote:
IMHO, for normal fields, yes. Calculated fields are more often
transient. So, the default for them should be to not store them in the
database.
Reasonable, but some calculated fields need to be stored, e.g. for
auditing reasons and to be used as a data item in itself.
An example: the calculation of BMI (body mass index = length^2/weight)
is an excellent example of enhancing user experience, but storing it is
necessary because it's often used in making decisions (-> audit trail)
and because it can be used in charts (-> data item).
- 0 -
I know this is not the normal pattern we see in a bunch of application
that try to autogenerate code. And they often fail, because they are not
able to build a little bit more complex forms as a simple invoce. Since
day 1, my cocoon involvement is more related to web-enable DB
applications. I know cocoon is often also percieved as a publishing
framework. A lot of people use cocoon mostly to build CMS or websites.
Michael Wechner told me last year he think in cocoon are main two groups
(publishers [CMS-ers] and DB webapp-ers) and that this two groups
inevitable push in different ways. My cocoon experience involves already
an account system, a payroll system between others. They normally
involve more than 50 tables..... Maybe this is the case Michael pointed
out and we have different needs of what a better Db support should be.
While you some people is happy with few simple tables to finish the
application, for others it is just the beginning.
So true. I suppose I'm in the DB-webapp "camp".
Bye, Helma
