Client server design question.
Date: 15 May 2003 01:05:59 -0700
Message-ID: <c97b9fa.0305150005.10c54b11_at_posting.google.com>
Has anyone had experience with a similar system to the following, or can offer some pro's and con's to the argument.
My company is recently undertaking a major project to develop a database driven accounting system. The current design sees a relational database backend with a data access layer in C# through which client programs access the database. The data access layer will contain all the functionality that would otherwise be in stored procedures and all programs are supposed to get/put data to the database via this data access layer. The RDBMS does support stored procedures quite well.
The whole system essentially is comprised of multiple pc programs accessing a central database driven program via a WAN.
Essentially the database is treated as a set of tables with relationships.
The downsides to this approach that I see are:
1) The data model and business logic will be split between tables,
relationships, some triggers and the external data access layer
written in c#.
2) Possible consistancy problems in the data model as the external
code may refer to views that don't exist etc.
3) The RDBMS would not be able to optimise the functionality that has
been moved to an external c# program, whereas with stored procedures
it can.
Pro's
1) Easier to move to a different RDBMS as the stored procedure syntax
and capability varies between vendors.
2) Richer object model using c#.
Any thoughts
Sello
Apologies if this is the wrong forum. Received on Thu May 15 2003 - 10:05:59 CEST