Gustav Brock
Gustav at cactus.dk
Tue May 8 03:45:39 CDT 2007
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/c3761.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