Re: Redeveloping the system - was Thoughts on payment handling in 1.4.x

["Chris Travers" <..hidden..>]

Hi David;

I appreciate your efforts to clarify the dialog.  As always, speaking
precisely is vitally important to these endeavors.

> I have very rarely raised issue
> because I did not want to appear to be too disruptive.

With all due respect, this is actually one of the post positive posts
as a whole I think you have brought to the discussion.

> Discussion in the past day has been extremely good. All you need now is
> a development infrastructure/method(ology)/process to capture and use
> the results ie to agree and define (record formally as an agreed basis
> for the system) these sorts of items: eg -

I agree.

I think we need to stop thinking in terms of rows.  Rows, tables, etc.
are what makes up a mathematical model for expressing the data.  From
the logical application perspective, they make very little sense.
This is one of the reasons for putting the methods of the objects in
stored procedures (so the programmer doesn't have to think in terms of
the relational math).

In my view, we need to separate thinking of things into three areas:

1)  Math/Data model:  Here we have sets of structured data sets which
interrelate to eachother in meaningful ways.  This is mostly a math
area but hidden from the rest of the appliction so we only need to
think of sets of structured data sets when looking at physical layout.
Business rules are expressed mathematically here wherever
appropriate.

2)  Application "Data" concept: Here we have documents and entries.
Some business rules may exist here.

3)  Workflow/User Experience concept:  Here we have screens and
workflows.  Some business rules may exist here.


> > On Fri, 2007-04-27 at 08:18 -0700, Chris Travers wrote:
> >
> > > > Invoices are accounting transactions.  Sales orders and quotes are not.
>  [)Proposed?) Business rule.]

Definition. As a document, an invoice is considered a financial
transaction.  Orders and quotes may have legal significance, but they
are not financial documents.

> > >
> > > In particular, when you convert an order to an invoice it becomes a
> > > financial transaction.
>  [)Proposed?) Business rule.]

Definition.  Basic Accrual accounting principle.


> > > Having said this, they are still phases of the document
> [Terminology: one proposed definition of the meaning of the term
> 'document', ie 'an instance of a business transaction as it flows
> through an instance of one "business workflow"'?]

A document in this case is a "data unit for presentation to others
inside or outside the buisness" and relates 1:1 to a printable item.

> [Terminology: one proposed definition of the meaning of the term
> 'phases']
> This example uses words in what I consider to be unusual, so if accepted
> as a valid usage for this project, it is important that the terms by
> formally defined, so others understand what you are on about.
>
> Its really important to define terminology concisely and unambiguously,
> plus as much as possible to have as few different meaning for a term as
> possible.

Actually, I would slightly quibble with this point.  Rather than
define terms precisely (since natural language is descriptive rather
than prescriptive), it is a good idea to discuss what we mean by what
we say and challenge eachother to find better words.  But we see the
same need for clarity.

> One key way to do this is to be very vary about picking up odd
> buzzwords and "mots de jour" or terms from foreign domains. Its a common
> problem in IT for people to think its cool to impress others with
> obscure terminology, and this is a big problem in system design. Stick
> to common meaning for terms as much as possible.

Hence my point above :-)
> I could give dozens more examples of this from the recent past here, but
> I am sure everyone gets the idea. Oh a couple of important ones though:
> my understanding/experience of relational data and database modelling
> results in these terms being understood as follows:
> In a physical schema/physical database -
>  1. Fields do not exist. They are called columns. Exception maybe:
> Microsoft Access database programming, (heaven help you). Fields exist
> in views of columns, eg on screens and in reports (views of data).
> Conversely on screens and in reports columns do not exist: they are
> fields.

If a field in the database is TOASTed, is it still a column?  What is
the difference between a field on a report and a column in a tabular
report?

Actually to be most precise, there are neither fields nor columns in
the database.  Only sets and members of sets.

>  2. Records do not exist. They are rows. Similarly on screens and in
> reports rows do not exist: they are records.
> Why is this important? Because if you mix the terms up, you start having
> a discussion about a logical/business model/users' requirements and end
> up sounding like you are making decisions about the way the physical
> database is going to be defined, all in one discussion, ie you get
> discussion about the nature of the problem(requirements) expressed as
> the answer(system design).

Agreed with the principal.

> In summary: terminology is vitally important. Ignore this at your peril.
>
> A final thought:
> If no development method (process plus artifacts) is agreed, how is
> everybody going to work together?

Areas of expertise, precise communication, etc?  Development of
appropriate processes?

Best Wishes,
Chris Travers