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

Relevant Pages

  • Re: need help designin a report
    ... you would have to design your tables along the lines ... I suggested in the earlier thread in this newsgroup (the subject was query ... I think that this is my last report. ...
    (microsoft.public.access.gettingstarted)
  • Re: dead group?:
    ... That newsgroup has gone to the dogs, ... see more design, post it. ... .design and not reading before asking questions), ... have had some of the common background to have a proper discussion. ...
    (sci.electronics.basics)
  • Re: multiple db query - join recordsets?
    ... open your database in Access, create a new query in Design view, switch to ... this query in Access, you need to replace the %'s with *'s. ... Please reply to the newsgroup. ...
    (microsoft.public.inetserver.asp.db)
  • Re: Remote Web and IIS
    ... Thanks for updates. ... It is mainly design for security reason. ... This newsgroup only focuses on SBS technical issues. ... you may want to contact Microsoft CSS directly. ...
    (microsoft.public.windows.server.sbs)
  • Re: Amplifier design pre-consultation consultation
    ... and then take that design and punch ... we want the lowest noise possible so that we can measure signals at ... they'll get stuck here and there and for that case you should line up a consultant. ... Given the capacitance of the detectors in question, ...
    (sci.electronics.design)