relational reasoning -- why two tables and not one?
lawpoop
poster asked about a single-table database structure. It was to track
donations, and that thank-you letters had been sent in reply.
A couple folks ( myself included ) thought that there should be at
least two tables -- 'donors' and 'donations' . But the poster argued
that no, there would never be a holiday fund drive appeal sent out to
all donors, or a year-end statement, or anything of that sort. So a
single table would suffice.
I tried to argue the point that having 'donors' and 'donations' more
accurately modeled 'reality' , and failed. Another poster, who was in
fact in favor of two tables, argued against the 'modeling reality'
argument, saying that theorists would it's wrong to have
'donation_dates' as a separate table, even though the relationship "in
reality" is one date for many donations. If it meets the functionality
specs, it's fine.
( There was talk of needing Donors as an entity later on, but there
was no need for it in the specs now, so it's moot ).
I couldn't think of a good argument against it, so I must be wrong.
But my gut instinct or intuition is telling me there is some
understanding of relational theory or something that I am not
grasping, which would prove insightful in this discussion.
Thoughts and comments?
Bob Badour
I don't see any particularly compelling reason for donors and donations
relations based on the meager information available from your post.
However, I suspect a compelling argument can be made for the necessity
of donations and replies relations.
lawpoop
> I don't see any particularly compelling reason for donors and donations
> relations based on the meager information available from your post.
> However, I suspect a compelling argument can be made for the necessity
> of donations and replies relations.
Care to expound? :)
Bob Badour
Insofar as someone might not yet have replied, the cardinality of
donations and replies differ.
The donations relation is historical data so there is no particular
reason to assume anything depends on donor should a donor donate at
different times and you made no mention of a temporal database.
paul c
Whose reality? Also, theory doesn't dictate requirements. As Ralston
Saul suggests, there has been no such thing as absolute reality since a
few hundred years ago. When Date writes about modelling reality, I
think he means it very loosely. Reality as a target risks inventing
imaginary requirements although I realize there is a going industry
based on foisting that on users. Apparently the poster eliminated a
number of possible requirements so a single table doesn't seem
unreasonable given the 'meagre' information as Bob B put it, even if
some donors are repeat donors.
Bob Badour
Even then, it is historical data. For the same donor, all the
information might be the same from one donation to the next, or it might
all be different. Assuming one wants to record the information as it was
(or as it was reported by the donor) at the time of the donation, few
if any functional dependencies are likely to exist.
Unless, of course, one creates a temporal database, but even then, the
charity seems to collect no information about intervening points of time
so a temporal database seems inappropriate too.
paul c
>...
> Even then, it is historical data. For the same donor, all the
> information might be the same from one donation to the next, or it might
> all be different. Assuming one wants to record the information as it was
> (or as it was reported by the donor) at the time of the donation, few
> if any functional dependencies are likely to exist.
>
> Unless, of course, one creates a temporal database, but even then, the
> charity seems to collect no information about intervening points of time
> so a temporal database seems inappropriate too.
I presume 'historical' means rows are 'written once', normally not
replaced. If so that would be a good word to use if it is in fact one of
the requirements.
Bob Badour
We don't really have requirements. All we have are a handful of 3rd hand
comments, but those comments do suggest the relation is historical. The
database records donations made and replies sent. All past tense.
Nothing to change or keep up to date. Just what happened at some point
in the past--much like an audit trail.
Roy Hann
Having a single table amounts to having a constraint that says that
the two facts (the fact about a specific donor and the fact about a
specific donation) are incapable of being learnt separately by the
business.
Can one have a donor who has not donated (yet)? Can one have a donation
without it comes from a donor? Can one have multiple donations by one
donor? If the answer to ANY of these questions is yes, then one
appears to need two tables. If the answer to ALL these questions is
no, then one appears to need a single table in order to enforce an
always correct representation of the business knowledge.
Of course my argument appears to break down if one is willing to permit
nullable columns, but I'm not.
--
Roy
paul c
> ...
> Can one have a donor who has not donated (yet)? ...
That is a great question because it indicates the rampant database
mysticism in the semi-literate so-called developed world. I'm sure
there are db's where prospective donors are called donors and a donor
isn't required to actually donate! Managers without budgets are similar.
Bob Badour
I am not sure what you mean by mysticism. What part is mystical? What
makes it mystical?
Keith H Duggar
I wonder too. For example, if one is a registered organ
donor but has not yet died and donated their organs, are
they mystical?
KHD
Bob Badour
He might be saying it's mysticism that says a donor must have previously
donated. After all, these are just names. As far as the DBMS is
concerned, they might as well be X and Y as any other name.
But I think we should probably let Paul answer for himself.
paul c
The label that means what someone wants it to mean instead of what it
means to everybody else.
Bob Badour
In the dbms, the label is merely a name for a relation: no more and no
less. One might as easily use D as Donor.
I am confused. Are you disagreeing with that?
You refer to mysticism a lot, and I remain unsure what you mean by it.
Does that make me a mystic?
paul c
> paul c wrote:
>
>> Bob Badour wrote:
>>
>>> paul c wrote:
>> The label that means what someone wants it to mean instead of what it
>> means to everybody else.
>
> In the dbms, the label is merely a name for a relation: no more and no
> less. One might as easily use D as Donor.
>
> I am confused. Are you disagreeing with that?
Not at all, "D" might even be preferable. But when designing tables as
the unmentioned poster was, it is a good idea to be precise so the
people in the room who don't know this, aka the small charity, aka the
man in the street, can better pin down their requirements. That was
surely the starting context in this thread. I'll grant that it's hard
for me to put this without sounding as if I'm talking out of both sides
of my mouth.
> You refer to mysticism a lot, and I remain unsure what you mean by it.
> Does that make me a mystic?
No. Although I hesitate to talk about literacy, not having been
appointed arbiteer by anybody I know, I will anyway. Being human
encourages the tendency but unlike many you have probably disciplined
yourself to resist the urge to portray the db as being more than it is.
What I resent is the widespread usage of vague and mysterious and
contextual words so that they become innately secretive words, such as
"reality", associating them with simple (db) abstractions, especially
when they generate spurious requirements, as it seemed to in lawpoop's
mind. He as much as said that his "reality" was unique within the
discussion he referred to.
Besides spreading it, it's also human to fall for mysticism. Western
citizens mostly accept the term "freedom of information act" literally
when the typical application involves secret databases and with-holding,
not freedom. The list of such terms is nearly endless and much of
society is inured to the distortions. This doesn't even touch the
rampant pomposity, at one time "lever" was both a noun and a verb, but
the verb is no longer sufficient, most people have some strange need to
make "leverage" into a verb.
I wouldn't argue if you associated my use of "mystical" with your use of
that "anthropo..." word I can't spell.
paul c
Okay, let me take another stab at it: making up a place-holder to stand
for something we aren't sure of (okay), then pretending we are sure
without recasting the place-holder (not okay). It always seemed to me
that the most valuable result of requirements meetings (maybe the only
result!) was discovering what we were really talking about. I think
it's fair to expect a reasonable common reading of such terms. Donor
doesn't mean volunteer!
Every so often somebody posts a link here to a new "technology" (a very
over-used word, the discovery of fire certainly meant a new technology
but I doubt if, thousands of years later, the Swedish "Match-King",
forget his name, would have made that claim about his matches because
the result, what people could do with his matches, wasn't novel at all).
Usually the only thing that is new is somebody's pet re-phrasing of an
existing computer language. Nine times out of ten the write-up is full
of grammatical, spelling and definition errors, making it at least
confusing and more likely incoherent, so it only serves to demonstrate
the author doesn't understand what he saying and probably doesn't
understand what he's writing about. I once complained to a bright
support programmer for a database compiler about a feature description
and he replied "Jeez, we have CS degrees, not English degrees."
I don't think db design is as difficult as language design but it does
have its own subtleties (to be fair, I think the biggest problem in db
design lies not within the subject itself but comes from the
inadequacies of the typical dbms product). Like language design, db
design is likely to go awry without precise language.
Russell made the same point as Bob B when he said of pure math,
something like it is the subject in which we don't know what we are
talking about, or whether what we are saying is true. He was talking
about the excision of meaning to allow application of logical rules.
That is part of the programmer's province. The programmer is tested
when users receive his result. I don't mean to sound as if I'm
lecturing the regulars here but vocabulary is important for user
understanding and agreement.
paul c
half a million words in English, the language with the most words, it is
rare for one person to have a vocabulary of more than thirty thousand
and most people operate with fewer than ten thousand. I have no idea by
what means these were counted, but I'd guess that if we throw out the
prepositions, adjectives, adverbs, conjugations and so forth we might be
left with a couple of thousand nouns of which only a few hundred are
used every day. Being cynical by upbringing, I'm sure that number is
declining, certainly it is among the rap generation. (For database
purposes, I assume we can throw out all but a handful of verbs since
computers are incapable of enacting much more than the boolean logic
operators.)
I remember when the large canned db apps came out, about twenty years
ago. They were described as 'enterprise-scale', being successors to the
specific narrow apps such as payroll, ap, ar, gl that had been around
since the early 1970's. Never had anything to do with them but I
gathered that they fell out of favour partly because they usually needed
massive customization that could be more expensive than "rolling your own".
I doubt if I'm going anywhere useful with this but I've often wondered
just how many data relationships an efficient economy really needs. I
can vaguely remember the early 'data dictionaries' from the 1970's
(usually they referred to non-relational data idealogies). Maybe
somebody can help me out as to what they contained, I seem to recall
there were many verb-phrases in them, which seems silly in retrospect.
Even if the average business needed a mere one hundred nouns to
encompass its operations, I guess that could still entail about
two-times-something-raised-to-the-power-of-a-hundred possible relations,
a very large number, intractable as they say, whereas I believe the very
largest databases are likely to number their relations in the hundreds.
But what if there were only one hundred base relations and no user
ever saw anything but views?
Maybe my question, if there is one, is this no doubt naive one: Why are
there so many different db's in the world? Is it for the same reason
that no two automotive marques use the same cranks for opening their
windows? I started to think about this when I spilled wine over my
little Linux laptop and apparently it has a permanent short-circuit.
For three-hundred bucks plus tax I found another laptop which has this
Vista OS on it. For my purposes the only difference is a bunch of
gew-gaws that periodically get in my way but which I can tolerate. I
gather that some people think it has better integration and some people
point out that certain interior functions have become slower and 'mpg'
has gotten worse but it mainly seems to me to be yet another window
crank design.
paul c
> ...
> Besides spreading it, it's also human to fall for mysticism. Western
> citizens mostly accept the term "freedom of information act" literally
> when the typical application involves secret databases and with-holding,
> not freedom. The list of such terms is nearly endless and much of
Regarding information suppression, before the 1970's, voter lists were
posted on lamp-posts and civic property-owner rolls were public. Now
they are secret, making it very hard to identify the landlord of the
obnoxious property next door. Ironically, the suppression is often
out-sourced to private companies, which have no public accountability.
Occasionally somebody is arrested for obtaining a million credit card
numbers from a private bank's cardholder database. From recent news, it
seems police forces put great effort into arresting people based on
photos they have stored on their computers, usually they are said to
involve paedophilia, once in a while they involve bomb-making techniques
but the public can't know for sure since the images 'must' be
suppressed. There is less publicity about how many perpetrators of the
acts pictured are arrested, so I assume that means fewer. Justice
administration has become heavily computerized seemingly at the same
rate as the time to trial has increased to four or five years, even for
crimes as serious as murder. No large property development can function
anymore without private police. About twenty years ago the leader of
the militant postal clerks union justified higher wages based on skill
but when questioned the only one he could come up with was the ability
to make change. I laughed at the time, but I don't laugh now while
waiting for the counter-person to check and double-check the register's
display. It seems to me that the proper, dare I say humanistic,
application of computers is progressing at an even slower rate than the
advance of db theory!
paul c
world's seas with about five hundred people in head office. Today it
manages not to rule the seas with tens of thousands of employees. He
said this advancement was made possible by computers.
(I suspect this progess was also aided by government aping of private
enterprise ideologies.)
Bob Badour
Are you sure it wasn't the loss of the finest traditions of the Royal Navy?
paul c
Heh heh, I believe the most unspeakable ones probably persist mostly in
secret even though more of them is spoken about because of the
wantonness of the modern media but let's not get into that. I still
have my mother's 1941 assignment order and 1945 permission to resign
from one of the Admiralty establishments, there must have been a typing
pool of some size and lots of carbon paper, but real signatures were
still needed and if I'm not mistaken there were several postal
deliveries a day. A few years ago after a long search I reached her
close friend from those days who had been a real-life spy. Very private
and swore me to secrecy about some remarkable and harrowing experiences,
but her accounts of those days emphasized how much administration was
done based on personal responsibility, where systematic thinking could
be discarded and nearly everybody took responsibility, no matter what
their position was. In the early 1990's I was booed by a crowd
listening to Robert Reich when I had the nerve to scoff at his
proclamation of the new service economy.
I never saw so much printed paper until personal laser printers were
invented, long after the systems they supported had been computerized.
The decision to click the print button is now taken by people who
basically have no responsibility at all.
The same boss told me there was more inefficiency in big business than
in any government, having worked in both on several continents I'm
pretty sure he was right. It's fashionable in N.A. and Britain to say
either otherwise or if one is in certain political camps to not try to
argue the point but it remains one of the big lies of the times. For
one thing, in spite of its proclaimed ideologies, private business
prefers not to compete with government on many fronts, especially for
money from the markets. Actually, I saw more technical creativity in
government whereas on the db side of business, all 'thought' was
copycat, except for the NIH syndrome which was copycat except for
implementation which was adhoc.
This guy was from Europe and he also remarked that he had never seen so
much political patronage as in N.A.
I should emphasize that I place the blame for computer misuse mostly on
the customers, not the vendors, even though my rants might suggest it's
all about vendor incompetence.
Clifford Heath
> I remember when the large canned db apps came out, about twenty years
> ago. They were described as 'enterprise-scale', being successors to the
> specific narrow apps such as payroll, ap, ar, gl that had been around
> since the early 1970's. Never had anything to do with them but I
> gathered that they fell out of favour partly because they usually needed
> massive customization that could be more expensive than "rolling your own".
That hasn't happened anywhere near me. SAP is very widely used, for example,
and more and more organisations have given up on bespoke development altogether.
SAP's configuration cost is very high, and there's a bad reason why organisations
pay that cost. No manager will sign a 7-figure check without a consultant's
report saying they made the right decision. Guess who gets to do the work
of configuring these behemoths? The very same consultants, of course.
> I doubt if I'm going anywhere useful with this but I've often wondered
> just how many data relationships an efficient economy really needs.
I've been told that the full SAP product install creates around 125,000 tables.
If someone can confirm that, I'd be keen to hear it.
> Even if the average business needed a mere one hundred nouns to
> encompass its operations, I guess that could still entail about
> two-times-something-raised-to-the-power-of-a-hundred possible relations,
Could, yes, but usually doesn't. As the number of nouns goes up, the number
of join tables goes up only as some logarithm. The thing that really can
blow up the complexity is the need to handle historical data in certain ways,
because many columns migrate into new tables.
> a very large number, intractable as they say, whereas I believe the very
> largest databases are likely to number their relations in the hundreds.
I hope the SAP example shows that's simply not the case. 500 tables is
considered to be medium-sized in my experience.
Last year I used CQL to model motor vehicle insurance claims. The model
had 100 nouns, though the database was only 18 tables. It did not include
most of the complexity of motor vehicle insurance, did not model the policy,
underwriting, insurance history, nor many other facets; and this organisation
handled more than twenty other types of insurance.
--
Clifford Heath, Data Constellation, http://dataconstellation.com
Agile Information Management and Design
paul c
> ...
> I've been told that the full SAP product install creates around 125,000
> tables.
> If someone can confirm that, I'd be keen to hear it.
Base tables? Really?
>> Even if the average business needed a mere one hundred nouns to
>> encompass its operations, I guess that could still entail about
>> two-times-something-raised-to-the-power-of-a-hundred possible relations,
>
> Could, yes, but usually doesn't. ...
Never does, I'd guess!
paul c
> paul c wrote:
> ...
> considered to be medium-sized in my experience.
>
> Last year I used CQL to model motor vehicle insurance claims. The model
> had 100 nouns, though the database was only 18 tables. It did not include
> most of the complexity of motor vehicle insurance, did not model the
> policy,
> underwriting, insurance history, nor many other facets; and this
> organisation
> handled more than twenty other types of insurance.
>
Thanks for that prompt, SAP was one of the products I had in mind. I'm
very curious to what extent SAP uses views. I gather that it runs on
SQL server, Oracle and perhaps other dbms'. Does it use some subterfuge
to update/insert/delete to/from views? Does it implement its own
integrity mechanisms to get around the various inadequacies of those dbms'?
Bob Badour
> Bob Badour wrote:
>
>> paul c wrote:
>>
>>> Bob Badour wrote:
>>>
>>>> paul c wrote:
>
> ...
>
>>> The label that means what someone wants it to mean instead of what it
>>> means to everybody else.
>>
>> In the dbms, the label is merely a name for a relation: no more and no
>> less. One might as easily use D as Donor.
>>
>> I am confused. Are you disagreeing with that?
>> ...
>
> Not at all, "D" might even be preferable. But when designing tables as
> the unmentioned poster was, it is a good idea to be precise so the
> people in the room who don't know this, aka the small charity, aka the
> man in the street, can better pin down their requirements.
You are mixing analysis and design. Clifford's recent Simsion reference
is interesting with respect to that distinction. Certainly, one has to
understand what the customer means before one can deliver anything the
customer needs. However, the symbol used for a relation is just a symbol.
> That was
> surely the starting context in this thread. I'll grant that it's hard
> for me to put this without sounding as if I'm talking out of both sides
> of my mouth.
I think I am getting a clearer picture of what you mean. It is a
mystical idea that one has power over something if only one knows its
true name. Whereas in reality, a name is just a convention we use for
distinguishing things. Reasonably intelligent creatures get conditioned
to respond to a name so the name becomes a means to evoke a response,
but that's as far as any power goes.
>> You refer to mysticism a lot, and I remain unsure what you mean by it.
>> Does that make me a mystic?
>
> No. Although I hesitate to talk about literacy, not having been
> appointed arbiteer by anybody I know, I will anyway. Being human
> encourages the tendency but unlike many you have probably disciplined
> yourself to resist the urge to portray the db as being more than it is.
> What I resent is the widespread usage of vague and mysterious and
> contextual words so that they become innately secretive words, such as
> "reality", associating them with simple (db) abstractions, especially
> when they generate spurious requirements, as it seemed to in lawpoop's
> mind. He as much as said that his "reality" was unique within the
> discussion he referred to.
>
> Besides spreading it, it's also human to fall for mysticism. Western
> citizens mostly accept the term "freedom of information act" literally
> when the typical application involves secret databases and with-holding,
> not freedom. The list of such terms is nearly endless and much of
> society is inured to the distortions. This doesn't even touch the
> rampant pomposity, at one time "lever" was both a noun and a verb, but
> the verb is no longer sufficient, most people have some strange need to
> make "leverage" into a verb.
I cringe when folks use "orientate" as a verb that has nothing to do
with cross-country running or using a map and compass. It's simply an
empirical fact that languages are fluid, though. ::shrug::
> I wouldn't argue if you associated my use of "mystical" with your use of
> that "anthropo..." word I can't spell.
That's certainly one type of mysticism. In this case, I think we have
someone acting more like Alice with Humpty Dumpty. The name "donation"
means exactly what the person who applied it to a table meant at the time.
paul c
> paul c wrote:
...
>> very largest databases are likely to number their relations in the
>> hundreds.
>
> I hope the SAP example shows that's simply not the case. 500 tables is
> considered to be medium-sized in my experience.
>
> Last year I used CQL to model motor vehicle insurance claims. The model
> had 100 nouns, though the database was only 18 tables. It did not include
> most of the complexity of motor vehicle insurance, did not model the
> policy,
> underwriting, insurance history, nor many other facets; and this
> organisation
> handled more than twenty other types of insurance.
>
A weak area in my generalizations is certainly the profusion of legal
'concepts', if such a dignified term is justified in the face of
lawyers' devices to increase business, and the pathetic obeisance of
business to cover itself by imagining it must 'model' those. Since the
management of businesses started to fall to people who had no stake,
most managers don`t understand the narrow purpose of the business they
are supposedly running. The lawyers I've met didn't seem to have been
taught the difference between nouns and verbs and they freely
proliferate both. Their so-called industry is generally a pox on
overall society too. Where I live, they have actually convinced most
people that they need a lawyer to sell a house, eg., sign a deed and
examine a certified cheque! I suppose other possessions will be next.
I knew an AVP in a financial company who had come up through the main
business ranks and then been promoted to head a computer department. He
was at his wit's end because the computer managers who reported to him
used techicalese he didn't understand and he let them use that to get
around his orders. I advised him to fire any underling who couldn't put
the problem in his terms. He was too weak-minded to do that, but I
still say business management should treat lawyers the same way.
The laws about retaining email amaze me. Even though I wasn't an
admirer of the US President Nixon, probably if it had been up to me he
never would have had to resign except because of personal testimony to
the US Congress, certainly not because of his own tape recordings. He
did plenty of damage, but I can`t see that his replacement improved
anything. I don`t understand what principle all this retention of
communication is involved, what good it does, blah, blah, blah.
paul c
...
> I cringe when folks use "orientate" as a verb that has nothing to do
> with cross-country running or using a map and compass. It's simply an
> empirical fact that languages are fluid, though. ::shrug::
Shrug though you might, they are getting fatter and more and more
sluggish and more vauge. That impedes our own `bandwidth`. Who`s in
charge, anyway, care to commentate�
Bob Badour
SAP foregoes any and all dbms constraint checking. It implements its own
flavor of SQL that gets translated to the underlying dbms. Views? Bwa ha
ha ha ha... let me regain my composure. No, they don't use views, and
anything that even remotely smells like database access goes through
some function call or another. Updates generally get queued in some sort
of unindexed or lightly indexed table where inserts are fast and then
processed after the fact. SAP very heavily overloads tables and the
side-effects can be staggering.
paul c
...
> That hasn't happened anywhere near me. SAP is very widely used, for
> example,
> and more and more organisations have given up on bespoke development
> altogether.
> SAP's configuration cost is very high, and there's a bad reason why
> organisations
> pay that cost. No manager will sign a 7-figure check without a consultant's
> report saying they made the right decision. Guess who gets to do the work
> of configuring these behemoths? The very same consultants, of course.
I think the main reason is that the typical manager is not competent to
organize rolling his own. He knows that too but is usually not
confident enough to admit it. The fact is, this field is still having
its learning pangs but it`s growing so fast that big mistakes are being
made that may take generations to undo. At the db technical level, the
phenomenon is almost the same, rolling your own, given a small enough
scale. gives similar security. The phenomenon in both cases amounts to
the acquired practice of secrecy. Outside of work, the same individuals
will trumpet open information and some imaginary democracy as long as it
doesn`t affect their personal wallet, except for token donations to the
real fanatics. Eg., they will espouse public education but send their
own kids to private school, espouse public transport infrastructure but
pay tolls for their own convenience, same goes for health care. In
other words, pretend they live to preserve one society but prefer to
live in one of two. This depends on secrecy, a concept that started as
a basic personal right until various human organizations started to
lever it on a large scale, certainly organized religion did that five
hundred years ago and probably there are equal earlier examples. About
twenty years ago, computer communication started to make the
manipulation much easier. Secrecy is one of the basic human motives
that no government as far as I know has yet dared to make a nominal
department for, yet all the others are more less covered, eg., public
and personal health. Admittedly they do have secrecy departments, but
they are usually called the `intelligence agency`. Often they will
anoint a `privacy commissioner` but that is usually a PR position.
Where I live, some large chain stores require me to provide a driver`s
licence in order to return an unopened package even though I have the
original cash receipt from yesterday. Why is this important to a
computer newsgroup� Answer: it`s all computerized!
paul c
Interesting, I have to conclude that any buyer who thinks it has
something to do with relational doesn�t know what he�s buying, let along
doing.
paul c
> paul c wrote:
...
>> of that "anthropo..." word I can't spell.
>
> That's certainly one type of mysticism. In this case, I think we have
> someone acting more like Alice with Humpty Dumpty. The name "donation"
> means exactly what the person who applied it to a table meant at the time.
Mysticism certainly encourages wilfullness and false certainty. Then
there is the Emperor�s New Clothes which plays on crowd psychology,
probably fear too, fear of disagreeing about anything when one is
basically pretending to be master of a field as long as other field
experts aren�t around. There is surprisingly little honest curiousity in
this field, except among the true newcomers, usually practically none
from newcomers with a non-db programming. It has been years since I saw
anybody ask why the result of a relational op is one relation.
Gene Wirchenko
<bba...@pei.sympatico.ca> wrote:
[snip]
>That's certainly one type of mysticism. In this case, I think we have
>someone acting more like Alice with Humpty Dumpty. The name "donation"
>means exactly what the person who applied it to a table meant at the time.
More like Humpty Dumpty:
"'When I use a word,' Humpty Dumpty said in rather a scornful tone,
'it means just what I choose it to mean�neither more nor less.'" --
"Through the Lookingglass"
Sincerely,
Gene Wirchenko
Bob Badour
I disagree. The person who created the donations table acted exactly
like Humpty. The name means exactly what he meant when he applied it to
the table. That person isn't here that we know of.
Lawpoop acted like Alice when she gave her age instead of describing
what she had (or in her case had not) said about her age. He inferred
something that was neither stated nor implied.
Now, had you quoted the part near where Humpty says a name like Alice
could mean almost anything when you suggested Lawpoop acted like Humpty,
I would have had to concede that Lawpoop acted like both Humpty and Alice.
Gene Wirchenko
<bba...@pei.sympatico.ca> wrote:
>Gene Wirchenko wrote:
>
>> On Thu, 15 Oct 2009 22:43:15 -0300, Bob Badour
>> <bba...@pei.sympatico.ca> wrote:
>>
>> [snip]
>>
>>>That's certainly one type of mysticism. In this case, I think we have
>>>someone acting more like Alice with Humpty Dumpty. The name "donation"
>>>means exactly what the person who applied it to a table meant at the time.
>>
>> More like Humpty Dumpty:
>> "'When I use a word,' Humpty Dumpty said in rather a scornful tone,
>> 'it means just what I choose it to mean�neither more nor less.'" --
>> "Through the Lookingglass"
>
>I disagree. The person who created the donations table acted exactly
^^^^^^^^^^^ ^^^^^^^^^^^^^^
>like Humpty. The name means exactly what he meant when he applied it to
^^^^^^^^^^^^
>the table. That person isn't here that we know of.
??? You disagree, but then you state my case.
[snip]
Sincerely,
Gene Wirchenko
Bob Badour
I disagree because the Humpty person is neither here nor practising any
sort of mysticism I can discern. That person has a single relation with
a single name. The name does not magically cause a need for a second
relation. The Alice character on the other hand...
Philipp Post
> A couple folks ( myself included ) thought that there should be at least two tables -- 'donors' and 'donations' . But the poster argued that no, there would never be a holiday fund drive appeal sent out to all donors, or a year-end statement, or anything of that sort. So a single table would suffice. <
From your description it seems to me that the poster would like to use
something quite simple, such as a wizard-generated bulk mailing which
for example is available in MS Word. Usually such data source is a
single table in MS Word, MS Excel or any database query on MS Access
or superior systems.
I agree that the single table solution will not scale up well, is not
properly normalized, but as you stated the OP was not interested in
that and apparently had no need for it.
I would therefore vote for that beeing a misunderstanding of some
kind.
brgds
Philipp Post
Roy Hann
> Lawpoop,
>
>> A couple folks ( myself included ) thought that there should be at least two tables -- 'donors' and 'donations' . But the poster argued that no, there would never be a holiday fund drive appeal sent out to all donors, or a year-end statement, or anything of that sort. So a single table would suffice. <
>
> From your description it seems to me that the poster would like to use
> something quite simple, such as a wizard-generated bulk mailing which
> for example is available in MS Word. Usually such data source is a
> single table in MS Word, MS Excel or any database query on MS Access
> or superior systems.
>
> I agree that the single table solution will not scale up well,
How do you figure that?
> is not
> properly normalized,
And how do you figure that?
> I would therefore vote for that beeing a misunderstanding of some kind.
If we get to vote on this, I vote that you're leaping to
entirely random conclusions.
--
Roy
Philipp Post
>
> How do you figure that?
If the requirements for this solution will be extended, you will have
to go splitting up that single table into two or more, depending on
the attributes on hand.
> > is not
> > properly normalized,
>
> And how do you figure that?
From what we have to guess from the description of the OP. E. g.
{donation_nbr, donator_name, donator_address, donation_amt,
donation_date}
> > I would therefore vote for that beeing a misunderstanding of some kind.
>
> If we get to vote on this, I vote that you're leaping to
> entirely random conclusions.
As random as possible based on what we were told about this case.
brgds
Philipp Post
Cimode
> I would therefore vote for that beeing a misunderstanding of some
> kind.
The only misunderstanding I can see here is the one you are spreading
by attempting to establish a relationship between a logical design
effort (a process called normalization) and a vague implementation
physical performance concept related to a direct image systems's
ilmitation called scaling up (related to the increase in time of
number of physical rows stored on disk and its impact on response
time).
Since you obviously ignore the difference between the two concepts
(also called independence between the logical and physical layer of
database modeling), I doubt that anything you are posting will add
anything of value since your premice is based on utter ignorance of
database design...
> brgds
>
> Philipp Post
Roy Hann
>> > I agree that the single table solution will not scale up well,
>>
>> How do you figure that?
>
> If the requirements for this solution will be extended, you will have
> to go splitting up that single table into two or more, depending on
> the attributes on hand.
Although that is not the usual notion of what it means to "scale up"
I guessed that's probably what you had in mind. But in the absence of
any good reason to prefer one random guess at a future conceptual model
over any other, you are just firing from the hip and not improving the
design.
>> > is not
>> > properly normalized,
>>
>> And how do you figure that?
>
> From what we have to guess from the description of the OP. E. g.
> {donation_nbr, donator_name, donator_address, donation_amt,
> donation_date}
Well, with just as much justification, my guess is that the OP's single
table is already 5NF.
--
Roy