Further discussions on SQL and tiers

> From: Pete Hall
>
> You lost me a little here. Aren't you agreeing with John? Doesn't a view
> that implements something like the CASE statement he suggests align itself
> well with your concept of a data deployment layer?   Wouldn't a group of
> views be one way to implement it? I'll bet a modifiable trigger
> buffer on a
> read trigger be a great help in implementing such a system. I'm not sure
> how you'd get from an integer  enum to a string value. Maybe THAT would
> require a view.

I have absolutely no problem with SQL in the data deployment layer.  My
concern is that the CASE statement John was proposing is more than likely
going to be used up in the presentation layer, in order to avoid IF/ELSE
logic.  I think this particular CASE statement crosses too many tiers.
Instead, I suggest something like this:

Data Deployment: SQL SELECT statement
Business Entity: One or more data deployment calls to populate entity
Business Logic:  Convert attribute to text ID
Presentation:    Convert text ID to human-readable

Business logic converts the attribute to a text ID (such as a message ID),
which the presentation layer converts to the appropriate text based on the
locale.

The conversion to human-readable could be done in the business logic layer,
provided the business logic is able to query the job attributes and
determine the user's locale information.  Alternately, you can skip the text
ID and convert straight from attribute to human-readable in the presentation
layer; that really depends on the application.

Joe