Re: SQL and defining data structures

[Mike Jones <mike.jones.sysdev@xxxxxxxxx>]

Hi Daryl,

The point I was trying to make, is not that specific example, but that
views, and a data access layer in general, can be transforming your data to
be more user friendly.

Circling back to that example, if the codes were 01, and 02, and 01 meant
INACTIVE, and 02 meant ACTIVE, perhaps the users would prefer to see codes
IA for INACTIVE and AC for ACTIVE.

That isn't the greatest example, I admit.  Don't get hung up on that
specific example.

The important concepts are:
1) A data layer can be transforming your data, and
2) With the right designs in place, some changes can be accomplished, in
some cases transparently, in a data layer, without changing the database or
the application.
3) A data layer can insulate from some changes, but it can also speed up
some changes.

In many cases, the presentation layer should present data differently than
the physical database structure.  To make that happen, some transformation
is required.  While one can make redundant copies of those transformations
up in the presentation layer, it is better to centralize them in a data
access layer.  One copy of code is almost always better than many.

Mike

On Thu, Aug 31, 2017 at 2:45 PM, Darryl Freinkel <dhfreinkel@xxxxxxxxx>
wrote:

> This can get confusing. There is an example quoted above where you can
> replace a code with a value to be more user friendly. What happens then if
> the code is 2A and the description is 20A.
>
> Did I get it wrong?
>
> Darryl.