Olaf Schmidt wrote:
> "Petite Abeille" schrieb
>
>> On Nov 11, 2010, at 8:30 PM, Olaf Schmidt wrote:
>>
>>
>>> If such an "encapsulation of business-rules" is sitting in the
>>> DB itself - written in a proprietary "DB-dialect", then you
>>> cannot call such a thing a "business-layer" anymore.
>>>
>> Nonsense :))
>>
>
> Of course... ;-)
>
> Nah, seriously... you know, how I meant that and what
> the context was ... *if* somebody decides to handle
> DB-Interaction (and his "set of business-rules") *not*
> directly "in the client" (or alternatively "in the DB-Server") -
> then he obviously does so, to decouple the Client-Application
> from the DB(-Backend) - allowing then (if done right),
> to "connect" this intermediate layer to different clientside
> Implementations (GUIs) - as well as different DB-Backends.
>
> Encapsulated in a Dll with the right interfaces, one can
> use it either serverside (e.g. behind a WebServer, to
> talk to Browser-Clients - delivering JSON- or XML-
> serialized Resultset-Content) - or behind a "real AppServer",
> to talk to "Fat Clients" (delivering Resultset-Content
> in a serialized "Object-Container" - as for example
> disconnected ADO-Recordsets on Windows, which
> are then understood by a large Set of languages, easily
> bindable with mostly only one line of code to a
> DataGrid or whatever GUI-Widget).
> Heck, you can put such a layer-Dll even at the clientside,
> to support a standalone App or alternatively a more
> Client/Server-like approach, capable to work against
> a different set of DB-engines even then (in the standalone
> App for example, against SQLite).
>
>
> ["Helsinki Declaration(s)"...]
> Cannot disagree more with these articles, sorry.
> >From my experience his main-assumption is just
> not true, that it is more difficult to develop such
> a layer with "modern languages or environments" -
> compared with a proprietary DB-dialect and
> some DB-specific enhancements or features.
>
> Perhaps you should give an example of a certain
> stored procedure (not too complex, to keep
> things more simple), describe what it does - and
> then compare it with the implementaion-code,
> done in a "normal language", which does use
> ODBC/JDBC/ADO or whatever and is using
> only "common SQL-statements", to achieve
> the same thing in a DB-engine-independent way?
>
>
> Olaf
>
>
>
I can't resist adding my little opinion to yet another "business logic
in stored procs vs. app layer" holy war...
I usually prefer keeping the business logic in the application layer and
leaving the DB tier to be just
a data provider. In actual practice, this is not always practical.
Let's say you implement a service where the client can retrieve a set of
top-level records,
each has an id; then for each id, you get additional detail records from
numerous
detail/line-item tables. If you implement this as a collection of
fine-grained services,
i.e. each piece is a round trip from client, through web services layer,
through to db layer;
and for each top-level id in the result set - the performance will be
abysmal.
With Sybase stored procs, you can stack multiple result sets in one
call, so in the above
scenario, you invoke the lookup proc for each top-level id and the proc
performs all
the secondary detail queries and stacks it all together in a
multiple-results result-set,
such that there's only one round-trip through the tiers for each
top-level id in the set.
I don't see how this is pertinent to SQLite, since it's generally not
used in multi-user
client-server configurations.
-Chris
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
