Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Architecture ideas for n-tier app with diff backends

Re: Architecture ideas for n-tier app with diff backends

From: Alexander Nickolsky <nickol_at_nospam.ru>
Date: 16 Jun 1999 08:56:45 GMT
Message-ID: <01beb7d5$d0ad7be0$0a00a8c0@nickol>


The most seroius problem with n-tier architecture that some existing end-user tools (MS Access for example, or Oracle data mining tool) are developed to be connected to the certain tier in your design (to say, to directly use the actual data via ODBC). So, the design of the whole system becomes more complicated. The most common solution is to allow read-only access for the underlying levels.

Peter Daniels <peterd_at_snapsystems.com> wrote in article <3766A024.B4962E4E_at_snapsystems.com>...
> We are in the proccess of converting our MS Access 97 based application
> to a 3+ tiered app that will be able to use either an Access 97, Access
> 2000, SQLServer7, or Oracle 8.0.5 backend. I would like to open a
> discussion about the caveats, tricks, and tips involved in such an
> architecture. Currently, we are only concerned with the data tier. I
> have a few ideas to fuel the fire:
>
> 1) separating the tiers into presentaion, business rules, data access,
> dbms

I'll assume presentation - business rules - object model - data access - dbms.
At object model level you can do some generalisation of data and provide the better multi-user capabilities.

> 2) breaking the data access tier into a single interface for the
> presentation layer and possible multiple child interfaces for actually
> talking to the different dbms.

Those child interfaces usually turn into specific SQL statements for different dbms'es. In this case your data access level should provide necessary transaction control. Anyway, it can do it better than dbms.  

> 3) The compromise between leveraging dbms specific functionality and
> maintaining easy revision control for conceptually similar data access.

For just SQL scripts it is easy. The automated testing is also possible (load the same data - get the same responce), but you will need very detailed description of the stored procedures for developers.

> 4) (a continuation of 3) using straight ANSI SQL in data tier components
> vs dbms specific stored procedure languages.

There ain't such thing as an ANSI SQL.

> I hope this thread will provide insight for the armys of developers
> required to design for multiple dbms.
>

Alexander Received on Wed Jun 16 1999 - 03:56:45 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US