Re: All hail Bob!

Jay Dee wrote:

> One day, while perusing
>
> Newsgroup: comp.databases.theory
>
> I came across:
>
> Subject: Entity Overlap and Relationships
>
>
> The soon-forthcoming presumption that the evasive general
> solution might involve a "trigger" which maintained a
> "relationship entry" confirmed what I suspected may have
> caused the poster to turn to the newsgroups with such a trivial
> problem: "Too many tools, not enough knowledge."
>
> The first reply was spot-on advice. And line 3 contains a bit
> of prophecy that, once you watch this newsgroup for a while,
> really isn't all that prescient.
>
> From: BB
>
> 1 With all due respect, the answers to your questions
> 2 will depend on the myriad requirements you have not
> 3 mentioned. Anyone who pretends to have answers is a crank.
>
> The OP politely thanked BB for his response, ignored it,
> and pressed on with more magic dust: GUIDs!
>
> *sotto voce* Do you know how many problems GUIDs have
> solved? Here's a clue: the value's less than one.
>
> Another optimistic contributor tried to get the original poster
> back on track. Without sounding dogmatic, and quietly restating
> the fact that too many requirements are still unstated, JH
> suggested a strategy for discovering a solution.
>
> From: JH
>
> 1 You first of course need to establish whether that
> 2 actually correctly models the situation. For example, is
> 3 there really such a concept of *the* address of an entity
> 4 (or *the* set of addresses) or could this depend upon
> 5 the context (working address, billing address, shipping
> 6 address, private address, et cetera). After you've
> 7 established this you then have to think about what is
> 8 the more efficient option. What are the typical queries
> 9 that will be asked. What integrity constraints can the
> 10 DBMS maintain and do you want them maintained? All these
> 11 things might might play a role in deciding what is the
> 12 best option, and I probably forgot a few.
>
> Words like "first" and "after" have well-known meanings.

What I don't understand is: Why isn't this topic called "All hail Jan!"?

All I did was warn someone against listening to cranks who pretend to have solutions without knowing requirements. Jan, at least, provided pointers on how to flesh out the requirements.

> My turn at a prediction: this project isn't going to get very
> far "down the road [before the designer will have] to change
> something after [he has] migrated the data over." Too, I'm
> sure that the designer believes the impact of such a retrofit
> will be mitigated because, it seems, work is underway using a
> design that will have to be enhanced to accommodate those other
> "addressing issues."

There are other possibilites. There is always the small chance, like a lightning strick or Superball lottery win, that the resulting design will actually match all of the requirements that were never considered. In this case, the person will have an ideal design and will no doubt eagerly proclaim to the world that he has solved all their problems.

In this situation, there is a high probability he will become a consultant where he can earn a lucrative fee for repeating the design and then move on before the client has to deal with the headache of implementation.

There is of course a much, much larger chance that after the database is populated with data and the applications are all written and rolled out that the person will discover that some important users will actually want to see some reports based on the data. At this time, there is the very high chance of complaints due either to incorrect results, delays and difficulties writing correct reports, or performance issues.

In this situation, there is a high probability he will decide that normalization is the cause of all the world's ills. He can then become a consultant and earn a lucrative fee by telling people that the consultant who designed the database messed everything up by overnormalizing or failing to denormalize. Take your pick. Received on Fri Apr 21 2006 - 16:43:47 CEST