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

Shamil Salakhetdinov shamil at users.mns.ru
Mon May 7 11:35:01 CDT 2007


Charlotte,

That would have been great if we have been able to develop a database model,
a software functionality,... once then deliver it and then forget it...

But "the only constant thing in the modern software development is the
constant change"...

--
Shamil
 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust
Sent: Monday, May 07, 2007 6:57 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Lazy,or Agile: that is the question... - Was Re:When
to Use aJunctionTable

I'vve never run into INSTEAD OF triggers, Shamil, since I don't actually
program SQL Server.  Thanks for pointing them out.  

For RAD, your point of view is perfectly justified, but for me the
"lazy" way is the way that only needs developing once, so I have to
disagree with you there.

Charlotte Foust 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil
Salakhetdinov
Sent: Friday, May 04, 2007 2:37 PM
To: 'Access-D'
Subject: [AccessD] Lazy,or Agile: that is the question... - Was Re:When
to Use a JunctionTable


Hi All,

I'm aware that the subject of this message could be a new and
potentially "flame provoking" therefore I have to tell you in the very
beginning that my only intention is to find what are weak and what are
strong positions of proposed below Lazy/Agile database development
approach...

Here it's - an agile (?!) non-traditional(?!!) modern(?!!!) approach to
the original subject question: "Re:When to Use a Junction Table"

- do not care what will happen tomorrow - use simplest possible solution
and make your customer happy today ASAP. When tomorrow comes and your
customer will change their minds you'll get your customer promptly happy
again because you know some "secrets" of modern agile development: for
database-centered development and MS SQL one of these "secrets" are
INSTEAD OF TRIGGERS:

- imagine your customer wanted to keep information about his Customers,
Products and Quantities of Products used/ordered by Customers;
- classical/traditional solution is to create (at least) three tables:
tblCustomer, tblProduct and tblProductsOfCustomer;
- but you're agile developer and you create just one table
tblProductsOfCustomer (yes, with natural compound (CustomerName,
ProductName) primary key!) and one view - ProductsOfCustomer on
tblProductsOfCustomer table.

That's it for "database design" - I quoted "database design" because a
professional traditional database designer/developer can hardly call
what I have just done as database design - he will call that "design"
something like "1-st grade botanic student garbage collection table"...

Then you create a form (MS Access form using linked view or VB2005 form
with
Gridview) on ProductsOfCustomer view to enter customer and products
information - and you're done in 15 minutes. Your customer is happy. He
pays you 100 bucks for this your agile 15 minutes work: another
consultant planned to charge your customer 300 bucks because they
planned to create three tables, with identity primary keys and "all that
jazz" - so your customer is even double happy - he saved 200 bucks. And
he is ready now to use your solution in his real life business and this
promptly made solution will save your customer even more money...

But then tomorrow comes and your customer realizes that he sometimes
enters different names for the same customer or the same product by thus
getting "dirty" data. Usual story isn't it?

Yes, it is, but by the moment your customer realizes he has some
problems with your solution he has already saved quite some bucks
because of the first version of the system you developed for him so
quickly - therefore he is ready to pay you some more bucks for your
agile development...

And here you're - you tell him, OK, no problem but this solution will
cost you this time 300 bucks because I need to do more work than
previous time.
And your customer doesn't argue - as I told you he saved already quite
some bucks because of the usage of your system in his real life business
and another developers planned to charged him this time 500 bucks to
"fix your work and to implement the new flexible advanced solution"...

And you do the "trick":
 1. create this time three tables with identity keys (5 minutes);  2.
modify ProductsOfCustomerView using joins (5 minutes);  3. write instead
of insert, update and delete triggers - couple of hours if you do that
first time and 15 minutes (5 minutes for each trigger) if you do that
kind of work on regular basis;  4. modify GUI design - create a form to
enter customer information, a form to enter product information and
modify the form to enter product quantity information to use combo-boxes
(or something like that)...

And you're done in approx. 1 hour if you're experienced agile developer
and in 3 hours if you're a novice one but know agile "secrets" and
"tricks"...

Your customer is happy again.

You are happy too - you outperformed your competitor and you have got in
total 400 bucks where your competitor planned originally to do all the
work for 300 bucks.

And what is important - from financial point of view the fact that you
was paid 100 bucks more doesn't influence/impact badly your customer's
business somehow because he got your first solution very promptly and
used it in his business and got his profit (instead of waiting super
duper costly original solution of your competitor)...

Of course I do (over-)simplify here the possible real life development
scenario but I do think that using INSTEAD OF TRIGGERS in MS SQL lets
developers to become "lazy" or "agile" - how you call them depends on
your point of view...

Interesting to hear now your opinions, dear all, on this optimistic
agile development practices I described above - what potential
bottlenecks do you see with that non-traditional(?) agile, flexible,
effective and always(?) more efficient and more profitable for all
involved parties approach comparing it with going traditional way your
competitors' development approach?...

Thank you.
 
--
Shamil
 

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list