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

DWUTKA at marlow.com DWUTKA at marlow.com
Tue May 25 11:54:01 CDT 2004


What is art anyhow?  Art is simply the manipulation of known sciences.  I
was a music major in college. (For a time). I played trombone, and was on a
jazz scholarship.  Got to meet lots of people in the jazz world.  It was
neat.  But I turned my love of math (which is what music is based on), into
a passion for computers.  To me they are very similar.  I was a good
musician, but I was never able to 'improvise' very well, at least I didn't
like what I would improvise.  However, I do like what I can 'improvise' on a
computer.

Science, engineering, art, etc, all work on systems with rules.  When you
are building a bridge, you have all sorts of factors that are involved, and
modern engineers have tons and tons of experience to overcome the normal
mundane issues.  However, science, engineering and art are also expanding.
This isn't done strictly through building upon past experience.  Every so
often an 'out of the box' solution is required, and when it arrives, that is
when science, engineering, and art are alike.

Granted, when I have to display records on a web page, or create a data
entry form, those are pretty mundane, cut and dry processes.  However, when
I built the archives for the AccessD list, and found searching through the
memo fields to be too lengthy of a process, I built the memo field indexer.
That was something I considered art.  Sure, it uses the same 'tools' that
the mundane processes use, but it was (if I may say so) 'Out of the box'
thinking.

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Arthur Fuller
Sent: Monday, May 24, 2004 9:47 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various


This is equivocation pure and simple, Drew... Though if you wish to
persist with it go ahead. There is IMO no comparison between designing a
bridge and writing a sonnet. Not least because in the former case if you
f**k up many people will die, while in the latter case no one will read
you.

I grant you that GUI design is art. But database design is pure science.

Arthur

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
DWUTKA at marlow.com
Sent: Monday, May 24, 2004 1:48 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various


Ah, but engineering is also an art.  

Granted, there are cut and dry cases, that require nothing more then
practical knowledge.  But when creativity is involved, then you have to
have the ability to create, not just 'define'.  That is an art.
Creating a table to represent an employee doesn't require creativity.
Creating a complex table structure to handle something more involved
will require creativity.

Drew

-----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 12:19 PM
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

-- 
_______________________________________________
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