[AccessD] On DB Bloat, Bad DB Design, and various

Martin Reid mwp.reid at qub.ac.uk
Mon May 24 14:31:55 CDT 2004


Reminds me of building web sites. Any fool can write a web page but takes an
expert to design a web site!

Martin


----- Original Message ----- 
From: "Jim Lawrence (AccessD)" <accessd at shaw.ca>
To: "Access Developers discussion and problem solving"
<accessd at databaseadvisors.com>
Sent: Monday, May 24, 2004 8:23 PM
Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various


> When a database has been completely normalized then to improve the
> performance, the DB has to be 'carefully' de-normalized. This is where the
> art comes in, like tuning a guitar.
>
> There are many photographers out there who claim to be professional. It is
> not enough to simply know all the rules of composition, design and colour.
> There is an indefinable property that makes a photographer a master of
their
> craft. Their ability to interpret what they see and produce can is not
fully
> qualified; if it could be we would all be Masters.
>
> The same is true with programming and database design.
>
> IMHO
> Jim
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Rocky Smolin -
> Beach Access Software
> Sent: Monday, May 24, 2004 10:19 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] On DB Bloat, Bad DB Design, and various
>
>
> I think it might be useful to separate db design from user interface
design.
> db design, following the discipline of normalization, seems amenable to a
> fairly objective judgment of good and bad, right and wrong.  So that seems
> to me like science, or really engineering.
>
> But the design of the forms, so they they work smoothly and efficiently
for
> the user, and reports, so that they are easily read and give the
information
> the user is looking for, that seems more like art, or more precisely
> design - like a commercial artist does.
>
> Rocky
>
> ----- Original Message -----
> From: <DWUTKA at marlow.com>
> To: <accessd at databaseadvisors.com>
> Sent: Monday, May 24, 2004 8:52 AM
> Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various
>
>
> > I would have to say that db design is 90% science, 10% art.  I would
agree
> > that in most cases, there is either the right way, or the wrong way.
But
> > the 'art' portion is the ability to see the grand picture, and create
it.
> >
> > Kind of like drawing.  I can picture a horse, I just can't draw one very
> > well.  I might get close to what my 5 year old can draw, but a good
artist
> > is going to draw something that is immediately recognizable as a horse.
> >
> > Knowing what good db design is, doesn't necessarily mean that you can
take
> a
> > particular business application and actually get it into a good db
design.
> > In an abstract sort of way, art is really about expressing something in
a
> > different media.  Paintings, sculptures, peoms, stories, are all
thoughts
> > and emotions that are taken from a 'mental' media, to a physical media.
> So
> > taking a business practice, and converting it into a database is also
> > expressing something in a different media.
> >
> > As for programming, I think is the opposite.  90% art, and 10% science.
> > Certain tasks in programming can certainly seem as mundane as
auto-repair.
> > However, your more complex projects can easily be compared to a
symphony,
> > getting all of the peices to work in harmony.
> >
> > Drew
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Arthur Fuller
> > Sent: Saturday, May 22, 2004 12:20 PM
> > To: 'Access Developers discussion and problem solving'
> > Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various
> >
> >
> > I respectfully disagree, at least regarding the design of the database.
> > As to the programming, I'm agnostic.
> >
> > While at the same time admitting artistic pretensions (published poems,
> > screenplays sold and made, short fiction published, tabla-player and
> > classical guitar wannabe), I don't see the connection. I used to
> > subscribe to your opinion but I do no longer. Long ago, I used to think
> > programming was an art. Now I hold it in not much greater regard than
> > auto-mechanics. As I see it now, db design is strictly science: for any
> > given database there is one correct design, a collection of
> > close-to-correct designs, and a larger collection of incorrect designs.
> > These stages correspond to the correct scientific theory, the
> > almost-correct theories, and the flat-earth society.
> >
> > Arthur
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence
> > (AccessD)
> > Sent: Saturday, May 22, 2004 12:16 PM
> > To: Access Developers discussion and problem solving
> > Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various
> >
> >
> > It seems to be that database designing and programming is as much a art
> > form as a science. Science can be learned but it all needs an artistic
> > bend to apply it, properly...IMHO.
> >
> > Jim
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Arthur Fuller
> > Sent: Friday, May 21, 2004 8:32 PM
> > To: 'Access Developers discussion and problem solving'
> > Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various
> >
> >
> > This is a thread worth pursuing, IMO. Given db1 with its (bad)
> > structure, how does one create the queries and execute them to create
> > db2 with its (good) structure? I've been fighting this problem for the
> > last few months, and it is decidedly non-trivial. There has to be a
> > correct way to do it. I'm certain of that. But I haven't found it yet.
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby
> > Sent: Friday, May 21, 2004 9:05 PM
> > To: Access Developers discussion and problem solving
> > Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various
> >
> >
> > "Colbyize the user" - Out the door, 20,000 feet, without a parachute.
> >
> > For those who were wondering.
> >
> > It actually came from the practice of certain South American "leaders",
> > when dealing with the Shining Path guerrillas (or suspected guerrillas
> > in too many cases).
> >
> > Back to the subject, the unfortunate reality is that the typical
> > application designed by the typical user often simply can't be
> > transitioned economically.
> >
> >
> > I "transitioned" one of these things at one of my current clients - a
> > call center for the Disability Insurance industry.  The main table was
> > over 120 fields that represented about 5 different major entities
> > (Insurer, Policy Holder, Policy, Claimant, Claim, Physician1, Physician2
> > etc.) plus dozens of "lookup" tables (city, state, Policy Type etc).
> > They started with a "flat file" data dump from their client (the
> > insurance company) which they just started adding new fields onto the
> > end of.
> >
> > Needless to say, it took months to analyze the entities and write the
> > queries to extract the data (normalize the thing).  Then it took more
> > months to build the forms to allow data entry, reports to report the
> > data etc.  Had I been called in at the start it would have been a far
> > less imposing task.
> >
> > They hired me 1/2 time for almost a year to get the thing ported and
> > running, with more than 1/2 of that time just extracting data.  They
> > USED that data every day and couldn't run the business without it.
> >
> > I had to build a system of queries that I could sequence in exactly the
> > correct order to normalize everything.  I had to test it and test it
> > again to get it all exactly right.  Then I had to build up the forms
> > they would be using after the port.  I had to run the normalization and
> > have a handful of testers do double entry (in the new and the old) to
> > ensure that it worked, then I had to train the users in the new system
> > (it simply didn't and COULDN'T look or work like the old).  Finally I
> > had to "throw the switch" one night porting the data, and make sure I
> > was available on site for the next several weeks to handle in real time
> > the inevitable issues that arose, to keep the system running and their
> > client (and the claimants calling the database users) happy.  On top of
> > all THAT I had to keep the old db running until I could throw the
> > switch.
> >
> > Perhaps this isn't a "typical" power user database gone wild, but it
> > could very well be.  And the results are VERY expensive.  The company
> > just doesn't function without the database and the cost of
> > "transitioning" is astronomical compared to a gradual building up of a
> > system the right way from the start.
> >
> > On a humorous note... the previous "developer" at the company was in
> > waaaaaay over her head trying to accomplish this stuff.  She just
> > "disappeared" one day, never to be heard from again.  My client was very
> > nervous that I might do the same thing.
> >
> > John W. Colby
> > www.ColbyConsulting.com
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Hale, Jim
> > Sent: Friday, May 21, 2004 5:47 PM
> > To: 'Access Developers discussion and problem solving'
> > Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various
> >
> >
> > Thanks, Susan- you hit the nail on the head and have prompted me to put
> > down some thoughts that have been bothering me for awhile. Hide the
> > women and children, here goes :-)
> >
> > <rant mode on>
> > I have to start by saying upfront my career evolution has been from the
> > finance/accounting user-to power user-to developer lineage and NOT the
> > IT side of the world. Frankly, I developed programming skills in self
> > defense to have control over my own destiny because the IT side of the
> > business couldn't/wouldn't keep up (even when it reported to me). My
> > understanding of Access has been need-based and evolved slowly over
> > time, i.e. I discovered Access and relational databases when Excel
> > "database" tables could no longer satisfy my needs. For several years
> > Access wizards and macros were my "state of the art" and I was happy as
> > a clam. My little databases received "raves" and made me the office guru
> > to the point I decided to take a college course in Access. It was at
> > that point I realized I really didn't understand relational databases
> > and that in fact my "wonderful" databases were all wrong except for the
> > fact they produced useful results. While I have since gone on to develop
> > my skills much further (yes, Virginia, I eventually discovered VBA!) the
> > point is I believe my evolution is more the rule than the exception. I
> > am willing to wager that in terms of sheer numbers the vast majority of
> > useful, results producing Access databases have been created by the
> > user/power user cadre rather than developers. I know of a major
> > insurance company whose IT group recently did a nose count of personal
> > Access apps that were floating around the company. The numbers
> > absolutely shocked them. Here at my company we have several people who
> > know a lot about the business but only a little about Access.
> > Nevertheless they are using the tool to produce very useful results.
> > This is the true "silent majority" of Access users who are attempting to
> > solve problems on a day to day basis. This should not surprise anyone
> > because after all the product was designed as a personal app. It is a
> > tribute to the strength of the product and the creativity of developers
> > such as those on this list that Access has evolved far beyond a simple
> > personal tool. The fact remains, however, personal databases account for
> > the vast majority of its use.
> >
> > With this as background I am very disturbed by Microsoft's apparent
> > intent to remove Access from the mainstream of evolving apps.  I also
> > was disappointed in Getz's column a few months ago summarizing a wish
> > list for the next Access version. It seems to me Access must stay true
> > to its roots and those roots are as a personal app. What does this mean
> > at the practical level? The self taught user runs into trouble not with
> > the small apps that, however constructed, they can still get their arms
> > around and validate the results. Its when these apps morph into mission
> > critical monsters that have grown in size and complexity to the point
> > where the non IT professional can no longer ensure valid results that
> > things usually hit the fan. Typically these apps spin off into space
> > before developers are called in for pooper scooper patrol. So what is
> > the solution? It would be tremendous if Access could be given additional
> > tools/wizards/internal training screens/magic to ease the transition in
> > the database life cycle from user app to developer maintainable code.
> > While it might be fashionable to always say we should "colbyize" the
> > users, on their side of the fence they have even harsher terms of
> > endearment for the IT crowd. It is  certainly not realistic to say users
> > should keep hands off and leave all the development to the pros. I
> > believe the more understanding users gain about relational databases by
> > hands on efforts the better off we all are. Having users in effect
> > "prototype" apps by taking a shot at building it also can save time
> > compared with a blank sheet of paper where the developer is forced to
> > play 20 questions trying to divine what users "really" want. If tools
> > could somehow be developed to smooth the user-to-developer transition we
> > would all be winners IMNSHO.  So I throw it out to the group, what sort
> > of improvements could be made to Access to lower the user learning curve
> > and smooth the handoff of projects from user to developer?
> >
> > <rant mode off>
> > That's my story and I'm sticking to it
> > Jim Hale
> >
> > -----Original Message-----
> > From: Susan Harkins [mailto:ssharkins at bellsouth.net]
> > Sent: Friday, May 21, 2004 8:55 AM
> > To: 'Access Developers discussion and problem solving'
> > Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various
> >
> >
> > Arthur -- do you know who wrote the original app? Was it someone
> > in-house that had to put together something because s/he was told to?
> > Access is as much a user database as a development tool -- that's what
> > makes it so alluring to such a wide audience. If the boss tells you the
> > department needs such and such, and you're not a database developer,
> > know onlyh a little about Access, you might come up with crap from a
> > developmental perspective
> > -- but if the crap works... Of course, eventually, they probably are
> > going to have to call in someone that really understands the issues, but
> > for awhile -- it works. That's not a bad thing -- and I don't know that
> > that's even the situation in your case Arthur -- but I think it happens
> > a lot.
> >
> > And a lot of so called developers produce crap -- especially the
> > geniuses in other areas that think Access is a toy and that anyone can
> > "do it." Those folks irritate me because invariably their stuff is
> > inefficient and laborious -- but it "looks" difficult and that's what
> > people expect to see, so they must know what they're doing, right? :)
> >
> > My personal favorite is developers that claim it can't be done without
> > code. Yeah... Right...
> >
> > But, the crap issue -- it's why I don't do it -- I'd produce more crap
> > than good stuff in today's environment. I can sling out little stuff
> > with the best of you, but once you get into the multi-user issues, I'd
> > rather visit a dentist.
> >
> > Susan H.
> >
> > I don't think certs are the answer either Arthur--it is too easy to get
> > a certification, and they push you through to fast. You don't even have
> > to produce anything original to get a cert--just do their stupid
> > exercises in the back of the chapters. And, I have seen certified
> > people, both programmers and network admins, do stupid stuff.
> >
> >
> > --
> > _______________________________________________
> > 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
> >
> >
> >
> > --
> > _______________________________________________
> > 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
> >
> > --
> > _______________________________________________
> > 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
> > --
> > _______________________________________________
> > 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
>
> -- 
> _______________________________________________
> 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