Re: SQL for presentation

frebe73_at_gmail.com wrote:

> It is also
> claimed that the "business logic" should be implemented in the database
> as views and the application on top of the database only should be
> responsible for presentation (and communication).

I cannot speak for every participant in the forum, but speaking only for myself I would restate this as: All business rules *can* be implemented in the server using triggers. All business rules *should* be implemented in the server for the advantage of centralization. It should also be noted that security should be considered a class of biz rules which also gain by this centralization.

AFAIK I am alone in advocating use of server-controlled derived values placed directly into tables and not views. There are many reasons for this which I won't go into just yet.

>
> In web applications, the presentation - HTML - is a data structure. If
> select statements could make almost any kind of data transformation,
> why couldn't we use select statements to produce the HTML text?

Two answers. First is public sites. HTML for public sites is usually a marketing or sales tool besides being a presentation tool. It is often hand-crafted on a page-by-page basis in consideration of its vital sales role. Jumping from a SELECT to HTML is difficult to picture here.

Second would be internal-use admin screens, commonly called CRUD screens. We have a zero-code solution there, but it is based on a small amount of library code that reads a data dictionary and generates things like inputs, selects, and textareas. Jumping from a SELECT to HTML is also hard to picture here.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)