[Info-Ingres] String Manipulations

[Emiliano]

On 2007-03-19, On Web <ac297 at dial.pipex.commm> wrote:
> Emiliano might have different views, but anyway..
>
> It might be that there's a sales promotion valid only between two dates, 
> with a coupon code. If you try and order using the coupon outside the dates, 
> you might wish to reject that order. A simplistic example, certainly. In 
> database terms, most business logic is probably concerned with validation 
> and business rule enforcement.

Stuff in this realm I would call BL, yes. In the example above, I
would (personally) only add this business rule if this scenario
happens regularly, and I'd capture such a promotion as data itself,
and validate the sale against that data.

> One of the real problems with putting business logic into a database is in 
> reflecting back to the front end what is happening. Of course, the advantage 
> with embedding logic into the database is that it's used even when people 
> are hacking away with SQL..

That's true if you use BL in the DB as your *only* line of defense. I
see BL in the DB as the *last* line of defense; if your application
didn't gracefully handle the actions that lead to invalid business data
interactively with the user, I'll rather have the DB handle it
ungracefully by refusing it with a somewhat generic error than accept
invalid data.

> I think that in general the trend is not to have business login in the 
> database, but I always think there's a good argument  for very basic logic 
> to be in place inside the database.

I do agree that it is 100% fine for the application to handle all the
finer points of complex BR in interacting with the user. In the end,
the DB gets the final say on what is right and what isn't and reserves
the right to reject your transaction in toto. I don't see this as
different from basic FK and check constraints, and i"m not assuming
you'd argue to have *those* handled by the application layer.

> Lets be honest, most evil programmers, think about databases as a commodity 
> afterthought, not as a cornerstone of their design except as a persistence 
> mechanism.

Which is *exactly why* the DB needs to protect the data and enforce BL.

-- 
Emiliano