atw: Re: DB terminology (Was: ASTCs etc)




I'd try to phrase it in terms of the user's goal, not the underlying
mechanism:
Add a user; Delete a scenario; Search job history

...rather than: Insert user record; Delete record from scenario file;
Query job history

The goals are the things that don't change, even if the implementation
were to change. To take an extreme example, if the customer decided
to throw out all their computer systems and revert to ledger cards and
quill pens, the goal would still be 'Add a user', not 'Insert a record' or
even 'Inscribe new card in user box'.

I worked on a product that had a swag of maintenance screens in a
standard form:

  Add row to backup item table
  Clone row in backup item table
  Change row in backup item table
  Delete row from backup item table

They certainly were all stored as rows in a table, and in this case
the audience wouldn't have been troubled by the DB terminology,
but there was just no advantage to rubbing their noses in the fact.
'Add backup item' is shorter, clearer, and closer to the actual goal.

---
Stuart Burnfield
Information Developer
Australian Programming Centre

> The product has a database at the back end.  The user has to
> perform standard database operations, such as add records,
> search, sort etc.

**************************************************
To post a message to austechwriter, send the message to 
austechwriter@xxxxxxxxxxxxxx

To subscribe to austechwriter, send a message to 
austechwriter-request@xxxxxxxxxxxxx with "subscribe" in the Subject field.

To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx with 
"unsubscribe" in the Subject field.

To search the austechwriter archives, go to 
www.freelists.org/archives/austechwriter

To contact the list administrator, send a message to 
austechwriter-admins@xxxxxxxxxxxxx
**************************************************

Other related posts: