[AccessD] Lazy, or Agile: that is the question... - Was Re:When to UseaJunctionTable

Gustav Brock Gustav at cactus.dk
Tue May 8 08:54:56 CDT 2007


Hi Shamil

I must believe you here as I haven't done much programming in SQL Server and you have so much more experience in this area.
However, to me a middle-tier can be made from anything that fits the purpose, and if that calls for another instance of SQL Server, that's fine with me. Actually, it sounds like it could be a very clever solution.

/gustav

>>> shamil at users.mns.ru 08-05-2007 12:34 >>>
Hi Gustav,

<<<
Also, I have the opinion that only very basic programming should be carried
out in the database server itself
>>>
We definitely are on the very "different sides of barricades here" :)

I'd put as much as possible programming on server side. And if talking about
middle/business tier then for MS SQL that would have been just another (and
another etc. if needed) MS SQL server using attached data-tier MS SQL Server
database and only when absolutely not possible or very expensive to use
T-SQL for middle-toer/business logic programming then I'd use programmatic
middle tier objects...

<<<
It is a nightmare to keep track of the different combinations of the backend
(the db server engine) versions and the frontend versions.
>>>
Well, you're talking about different database engines - I rely on just one
MS SQL Server. My reason is that solutions keeping as much as possible
programming on server side are by definition more reactive and scalable. 

If system reaction and relatively inexpensive scaling isn't an issue with
your solution then you can set as the main goal supporting of different
backend database engines but again the high cost of this goal would be less
reactive and often not scalable at all solution or scalable but resulting in
many versions of the same functionality for different usage
scenarios/"scaling factors" - "support nightmare" will be there anyway...

"Never believe Microsoft" I know - if they change the rules of the game (I
doubt it happens now because IMO they are changing to the better) with MS
SQL ("skyrocket"/set prices even on MS SQL Express) then MS SQL based
solutions can be relatively inexpensively ported to other back-end...

And I evaluate MS SQL together with Visual Studio 2005 as the most powerful
well integrated modern application development platform allowing to
considerably cut costs and time on application development - and the savings
from these cuttings of development costs can be used by customers to
purchase MS SQL licenses...

--
Shamil
 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com 
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Tuesday, May 08, 2007 12:46 PM
To: accessd at databaseadvisors.com 
Subject: Re: [AccessD] Lazy,or Agile: that is the question... - Was Re:When
to UseaJunctionTable

Hi Shamil

On a general note, I think a DBA should stay so - this may certainly be a
full-time job on its own. 

Also, I have the opinion that only very basic programming should be carried
out in the database server itself - like triggers for creating special keys
or maintaining materialized views and so on. I know that fancy things can be
done but should you need that outside the frontend, create a middle tier.
One strong reason for this is maintenance if this is for an app that is
deployed in many places. It is a nightmare to keep track of the different
combinations of the backend (the db server engine) versions and the frontend
versions. And DBAs hate to be involved in this, so you will have to create
utilities to perform the updates of the backend automatically. It can be
done, of course, but it is more work for you.

It could be interesting to learn how other listers take hand of this?
Charlotte's system is a three-tier system if I recall correctly.

/gustav





More information about the AccessD mailing list