RE: Update Problem

Tech-Archive recommends: Speed Up your PC by fixing your registry



1) I did state the generally accepted principles of database design* call for
the 'avoidance' of calculated fields being stored as opposed to the
'prohibition' of such.

2) "And I'd insist on *objectively demonstrated* inadequate performance
using the
normalized design, with the value being calculated on the fly. " I'm not
getting your post. Are you saying that you prefer performance in a
non-normalized schema to be tested first for comparision?

3) I used AGE within the context of the person's age since DOB. I would say
that the age at which a woman birth'd a child would be appropriate to store
as it represents a fixed point in time unlikely to change. (But if you're
dealing with a medical application, all medical events have an associated
billing code and as such the date of the birth could be entered as a child
record with the billing code. The mother's age could then be calculated. My
dad was a doc.)

4) I'd have to concur about the storing the something calculated if there's
sorting and searching on it for a huge number of records. I personally
believe that a 100% Normalized database is a theoretical objective, but not
practical in the world especially given that there are times were you might
want to duplicate data for audit trail purposes. Or if you're dealing with an
accounting application, having the client's account balance in a header table
for easily lookup as opposed to having to total the detail. In another
example, if user dch3 enters a record, you might want to permanently capture
the user name 'David' as the person to avoid a situation where the user name
dch3 is changed to a different name or deleted to preserve the data. (I
worked with a PMS where the structure of the database was such were a user
could be created, transactions executed and the user subsequently deleted or
assigned to another person breaking the audit trail. BAD! BAD! BAD).






*The phrase 'generally accepted principles of accounting' has been stuck in
my head for some innane reason.

.



Relevant Pages

  • Re: 3vl 2vl and NULL
    ... >>Dot as everyone else, including Uncle Vernon in this 2VL scenario, has ... >>If the data are changed so that Aunt Marge also has a null set age, ... >>someone whose age (in this database) is less than or equal to Marge's ...
    (comp.databases.theory)
  • Re: 3vl 2vl and NULL
    ... >>>someone whose age (in this database) is less than or equal to Marge's ... >Uncle Henry's age is unknown ... the handling of missing data changes as well. ...
    (comp.databases.theory)
  • How to move data in Column A into seperate columns / rows
    ... I have just started a book website, part of the site is a database. ... BI paperback ... SR FIELD GUIDES ... DE It was an age of Empire, an age of contrast, and an age of dramatic ...
    (microsoft.public.excel.programming)
  • Re: Relationships. Does anyone use them?
    ... If you do not care to "go in into the relationships window to set the relationship" you are, quite simply, going to fail badly any relational database course. ... Relationships are the constraints that are needed to be set up to ensure database structural integrity. ... You really need to go over this in detail, because right now I can tell you, no offence intended and with the greatest of respect, that you are NOT DOING RELATIONAL DATABASE DESIGN WORK at present. ...
    (comp.databases.ms-access)
  • Re: Table design - reducing number of entities
    ... I've looked at a lot of crappy code written against databases. ... lot of that code is crappy, because the database design itself was crappy. ... > look at all the constraints on the putative entities--not forgetting the ...
    (comp.databases.theory)