Charlotte Foust
cfoust at infostatsystems.com
Tue May 8 10:15:31 CDT 2007
Charlotte's system is n-tier, but basically 3-tier. Our "data tier"
holds no data, it holds the business logic and information about the
shape and manipulation of data. It is, in fact, a middle tier. The
programmers don't have to deal with the true back end, we program to
that middle tier. Of course, when the app is in early stages, we're
receiving curve balls from the back end DBA, but that's par when
creating some new and complicated. But once the dust has settled on the
schema, we only have to modify data providers in minimal ways to deal
with whatever backend is thrown at us. We currently support either
Access or SQL Server backends using a common OleDb provider. There is
logic buried in there to check on what kind of BE we're talking to and
make any necessary substitutions of things like date delimiters as
needed. Eventually, we'll support Oracle too, but we started with the
familiar. Instead of SQL Server triggers, we use code that will also
work against other backends, since it doesn't depend on the server to
execute it.
This isn't exactly agile, but the apps we're building couldn't be done
that way because the demand for precise historical information is both
exhaustive and intense. The gradual development took place over years,
and what we're doing now is putting a new face on it, adding things we
couldn't do in Access alone, and adding sizzle to make it competitive.
It also works quite well and our testers are reduced to finding things
that only fail on Wednesdays when the wind is right.
Charlotte
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Tuesday, May 08, 2007 1:46 AM
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
>>> shamil at users.mns.ru 07-05-2007 17:54 >>>
Hi Gustav,
Thank you for your reply.
Yes, "Agile" can be considered as a buzzword but experienced developers
following agile development methodologies achieve results, which I think
can't be achieved when using "traditional" phased application
development.
There are similarities but the main difference is that an agile
developer is always ready to embrace the change - any change requests or
requests to implement new functionality: as we all know within
traditional, even phased development change requests and requests for
new functionality are often becoming big problems...
<<<
I've never felt I understood it fully
>>>
I must say I do not feel I understand it fully, I will probably never
will but the more agile development practices I learn and I apply in
real life development the more I see this is the way to effectively
manage modern software application development complexities, especially
for small software development shops with limited resources...
<<<
I'm surprised of the low level at which some "experts" are moving.
>>>
Gustav, may I disagree here? I'd think this guy is thinking / operating
on rather high level (sometimes abstract/conceptual - i.e. applicable to
a broad range of real life database development cases) - his goal is to
effectively "unbind" developers and DBAs allowing both parties to work
in parallel but separately on the same project, without interfering each
other work - IOW his goal is effective teamwork...
<<<
when he stuffs them with all kinds of expressions to return formatted
data - a boo boo as formatting belongs to the frontend.
>>>
Gustav, may I disagree here also? There are at least two+ ideas "this
guy"
explores:
- 1) propagating updates through (non-updatable) views;
- 2) creating common (set of) views on top of datamodel/database base
tables
- the (set of) views to be used:
2.1) as abstraction layer for developers for agile database
development;
2.2) as a common (set of) views to be used for different types of
FEs:
desktop application FE, web application FE, Web services, mobile
application Fes, reporting services etc
And for the case (2.2) formatting should belong in my opinion (mainly)
to the views to have coordinated results presented on all types of
FEs...
As for non-updatable views - the idea in my opinion is that while an
application evolves, the views, which were originally updatable because
they were based on just one base table or on a joining of the base
tables, which updates (inserts, updates, deletes) MS SQL server is able
to unambiguously handle by itself - these views become non-updatable
because they get some calculated values or because MS SQL starts to
translate their updates (because of the base tables and their
relationships changes) not the way developers wanted/expected - and here
INSTEAD OF triggers, which help to solve ambiguities...
Your turn now :)
Thank you.
--
Shamil
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Monday, May 07, 2007 2:17 PM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Lazy,or Agile: that is the question... - Was
Re:When to Use aJunctionTable
Hi Shamil
Thanks for winding this up. You really keep us awake. I truly appreciate
all your findings which I in many cases not even would know where to
look for.
One should be careful when buzz words pop up. "Agile" is one of these.
I've never felt I understood it fully, neither haven't I cared much, but
from your description I can see, we've always worked after that
principle though we normally just call the partial implementations for
"phases". Phase One gets the client going, Phase Two implements the next
step when he is ready, and at last you have the final Phase which rounds
up the project. An important thing is that this way you may adjust
phases based on experiences from the previous.
I'm surprised of the low level at which some "experts" are moving. In
the first link:
http://www.tdan.com/i034ht03.htm
the guy has discovered that Views (like Select queries in the Access
world) may be created in the database, and when you do, he says, you
adopt to agile programming! However, it takes some time before he
realises that many views are not updatable, indeed not when he stuffs
them will all kinds of expressions to return formatted data - a boo boo
as formatting belongs to the frontend.
/gustav
>>> shamil at users.mns.ru 06-05-2007 12:07 >>>
Hi Gustav,
The point is agile development - to implement and to deliver ASAP
requested *functionality*. Customers most of the time do not care how
you achieve the
result: there are exceptions but these are few - these *exceptional^
customers who force you to use this or that *development
method(ologies)* are another subject and we can discuss it in another
thread not here.
<<<
... the client may call on others to judge your quick'n'dirty
delivery...
>>>
No problem with that at all, Gustav.
I can find many arguments to "defend" my agile position/approach: you
know I'm a professional "old-school BDUF" developer with rich experience
in this BDUF forcing a developer to foresee all the future change
requests and requests for new functionality. Yes, I do know that
customers change their mind often and I'm ready and I do know what to do
to promptly convert/refactor "quick'n'dirty" solution to the "right"
one...
Therefore no problem with my customer calling other developers to check
- if he will decide he needs "right" solution from the very beginning I
will try to explain him that he will get it promptly when his business
will urge for this "right" solution but currently, I will tell him,
"quick'n'dirty"
solution is all he needs....
Yes, my approach is risky but USD100 vs. USD300 for other solutions
should make the difference for customer to charge me with this project.
And this my sample case is just a sample and of course USD200 not a big
difference but in real life case that could be EUR10,000 vs. EUR30,000
and one month of work until delivery vs. three months of work until
delivery - that bigger financial and time difference, I expect you
agree, will "play on my side"...
<<<
Second, programming should be fun
>>>
Agile development is a lot of fun, Gustav. Much more fun than BDUF or
"right" development are. (I know what I'm saying having spent most of my
development carrier working on projects using BDUF or "right"
development
methodologies) And agile development needs a good portion of courage -
and when you see how you "refactor" this courage into useful delivered
on time and on budget applications then you get even more fun from that
software development business activity...
And agile development is not easy. And it needs a lot of experience to
be effective. I'm leaning it by doing my customers' projects. And it
works.
Still there are a lot to learn - in a nutshell agile is a natural for
software development trial'n'error procedure but unlike traditional BDUF
or "right" approaches agile constantly gives "perceivable" results and
these "perceivable" results feedback is a fun also: everybody who worked
on large projects could remember months (and years?) of design and
development before delivery and who experienced such projects do
remember that the more months
(years) a project takes before delivery the less is the team and
customers'
optimism, the higher is the probability that the finally delivered
software will not satisfy customers' business needs...
And "right" solutions are also constantly changing - that is the fact,
and the more "right" is the solution delivered using traditional
development methodologies the less easier to refactor such "right"
solutions into "proper" ones and then again to the "right" one and so
on...
Agile gives you experience and courage (and fun from this courage) I
mentioned above to react promptly on change requests delivering new
functionality when it's needed. And "right" and BDUF approaches do not
give/do not develop in you this experience and courage. I know that
Gustav and I know you know that too of course - the more complex
software you develop becomes the less courage you have while fixing bugs
in it or implementing new functionality, which results in changing
existing code - "don't touch it when it works well to not make it
broken" mantra is far from being called a "courageous developer slogan"
:)
And modern development needs a lot of courage because modern software is
becoming more and more complicated and because change requests are
becoming "a never ending storm" around you and a developer has to work
in that "stormy environment" and deliver useful functionality in time
and on budget...
<<<
Personally I hate when I have to make "quick" solutions - it happens -
and such work may even tend to take longer time than it should.
>>>
Yes, Gustav - "been there seen that", well, I must say I'm still "one
leg there and one leg here": I think this "hatred of quick'n'dirty
solutions", which is still living in hearts of experienced software
developers as you and me and many developers here are - this hatred
comes from fear to fail to deliver "right" software on *fixed* time and
budget, resulting in many hours of overwork, badly affecting private
life and finances...
But when "right" solution is getting fallen as "playing cards home" a
few hours, days, months after delivery this sad picture results in even
more hatred and fear not fun... I can be wrong, but I guess I'm not -
this is what happened many times in the past with me and still happens,
this is what described in many books on agile software development I
read, this is what should happen with everybody except a few genius
developers who I have never met/seen - have you?
As for the subject and my proposal to use INSTEAD OF triggers for "agile
database design and development" - I have searched Internet and as far
as I see I'm not alone :) - well, of course I'm not talking about
"silver bullet"
- and I asked, dear all, in my first posting what weak positions you see
in this approach: could it result in less reactive application system -
very slow system reaction compared to the traditional "right"
development/database design practices? I think that from financial point
of view proposed agile approach is (much) more attractive or that point
is also questionable? I assume that being experienced an agile developer
will not fail to refactor his "quick'n'dirty" solution into the "right"
one when needed on the same or slightly higher but in long run for sure
considerably less time and budget. Less in long run because agile will
deliver only what is needed not what "could be needed in the future".
My search on Internet has returned these useful links - I did do this
search after my first posting here:
VIEWS: THE KEY TO DATABASE AGILITY
http://www.tdan.com/i034ht03.htm
Chapter 37 - Extending Triggers with INSTEAD OF
http://www.microsoft.com/technet/prodtechnol/sql/2000/reskit/part10/c376
1.ms
px?mfr=true
Exploring SQL Server Triggers
http://msdn.microsoft.com/msdnmag/issues/03/12/DataPoints/
Exploring SQL Server Triggers: Part 2
http://msdn.microsoft.com/msdnmag/issues/04/01/DataPoints/
Making use of INSTEAD-OF triggers in SQL Server 2005
http://articles.techrepublic.com.com/5100-9592_11-6113179.html
As you can find if you read through the articles from the above links
proposed approach could fail for large systems. But nobody did try to
check how well/bad it will work for such large systems. If I will find
free time in the near future I will try to check that but first I will
try to collect all possible information on this subject to not waste
time to "reinvent the
(bad) wheel"...
And of course similar agile "quick'n'dirty" approach can be applied by
using stored procedures as an abstraction layer. In this latter case
there is no doubts that there will be no any system reaction degradation
but using SPs could be more laborious than INSTEAD OF triggers and what
is also good with triggers from conceptual point of view is that they
will *physically* belong to the objects(/VIEWs) depending on them - i.e.
they will implement business rules for the business objects owning
them...
There are other advantages and disadvantages of views with INSTEAD OF
triggers - you can read about them by following the above URLs...
That's it for today.
Your turn now :)
Thank you.
--
Shamil
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Sunday, May 06, 2007 10:20 AM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Lazy,or Agile: that is the question... - Was
Re:When to Use a JunctionTable
Hi Shamil
I see your point. The perfect solution that takes forever to implement
is useless.
However, it is my experience that once you've pinpointed if not the
perfect solution then a "right" solution, it doesn't take that much
longer to develop than a quick and dirty.
Add to this two topics: first, the client may call on others to judge
your quick'n'dirty delivery with the result that you are stamped as a
non-pro.
Second, programming should be fun. Personally I hate when I have to make
"quick" solutions - it happens - and such work may even tend to take
longer time than it should.
/gustav
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com