hepabolu wrote:
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).
Exactly, http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112940209004427
Best Regards,
Antonio Gallardo.
- 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
