I have a simple tracking application that seems to only require one 
table with fields that can be updated and tracked.  So far I can see no 
reason for any other tables, because even the status fields are binary 
(not done/done, yes / no, etc.).

It seams this shouldn't require a relational database, but why recreate 
the wheel writing all the data manipulation functions when MySQL has 
already done the legwork?

I guess I could satisfy my conscience by creating a second table to 
archive completed items, though I could just as easily move archived 
items to a flat file.

Anyone have any thoughts on single table databases?

-- 
Bill

William Gill: 

> Anyone have any thoughts on single table databases?

Just go ahead if you wish.

From your description, it's not clear what the situation is, and 
whether or not you already normalized. What does your data model look 
like? How many entities do you have, and what relationships exist?

-- 
Erick

Erick T. Barkhuis wrote:
> From your description, it's not clear what the situation is, and 
> whether or not you already normalized. What does your data model look 
> like? How many entities do you have, and what relationships exist?
> 
Yes it is normalized with one deliberate violation (trantype).  There is 
no customer table, or any need for one, so custname is not a lookup or 
foreign key.

Here's the CREATE

CREATE TABLE  donations (
   ID int(10) unsigned zerofill NOT NULL auto_increment,
   trantype enum('CASH','CHECK','CREDIT') default 'CASH',
   custname VARCHAR(45),
   amount float NOT NULL,
   trandate date NOT NULL,
   mailed date NOT NULL,
   fundsCleared date NOT NULL,
   complete date NOT NULL,
   PRIMARY KEY  (ID)
)

'mailed' is used to track thank you letters.

'fundsCleared' is to track when credit or checks are deposited.

'complete' lets them know the thank you has been sent and the funds have 
cleared.  I could eliminate it in favor of testing for both 'mailed' and 
'fundsCleared' having valid dates.

At present 'complete' with dates older than n days are simply deleted, 
but could be moved into an archive.

-- 
Bill

On Oct 13, 1:01=A0pm, William Gill <nos...@domain.invalid> wrote:
> Erick T. Barkhuis wrote:
> > From your description, it's not clear what the situation is, and
> > whether or not you already normalized. What does your data model look
> > like? How many entities do you have, and what relationships exist?
>
> Yes it is normalized with one deliberate violation (trantype). =A0There i=
s
> no customer table, or any need for one, so custname is not a lookup or
> foreign key.

You never want to track the history of a particular donor, know what
they donated, or send them a year-end statement?

William Gill:
> Erick T. Barkhuis wrote:
> > From your description, it's not clear what the situation is, and 
> > whether or not you already normalized. What does your data model look 
> > like? How many entities do you have, and what relationships exist?
> > 
> Yes it is normalized with one deliberate violation (trantype).  There is 
> no customer table, or any need for one, so custname is not a lookup or 
> foreign key.

So, no customers donate twice (or if they do, you don't have to make 
sure that this can be reckognized)?
OK...in that case, why do you have doubts? It is not mandatory to have 
more than one table in a database. 
As you said, you could as well save every record in a sequential file, 
but if you need filtering, I think it's a good idea to make use of 
'prefab' database queries.


-- 
Erick

lawpoop wrote:
> You never want to track the history of a particular donor, know what
> they donated, or send them a year-end statement?
Not at this time.  If that changes they'll have to go to something more 
sophisticated.  All they want is to be able to do a couple simple 
reports like totals, average clearing time on non cash, frequency and 
impact of funds that don't clear, and to be sure thank yous go out in a 
timely manner.

-- 
Bill

Erick T. Barkhuis wrote:
> So, no customers donate twice (or if they do, you don't have to make 
> sure that this can be reckognized)?
Not at this time.

> OK...in that case, why do you have doubts? It is not mandatory to have 
> more than one table in a database. 
It just seemed wrongheaded :-)

> As you said, you could as well save every record in a sequential file, 
> but if you need filtering, I think it's a good idea to make use of 
> 'prefab' database queries.
My rational exactly, "why recreate the wheel?"

-- 
Bill

On Oct 13, 1:38=A0pm, William Gill <nos...@domain.invalid> wrote:
> lawpoop wrote:
> > You never want to track the history of a particular donor, know what
> > they donated, or send them a year-end statement?
>
> Not at this time. =A0If that changes they'll have to go to something more
> sophisticated.

I've been in this situation before. It might seem like a big time-
savings to go with a single table, instead of two or three, but it
almost immediately presents a whole host of problems ( clients expect
a bunch of implicit functionality which they are never able to
articulate beforehand ).

If that changes, and it will soon, you will have a mess trying to
chunk out the data into proper tables. Doing it right from the outset,
where it's very easy to do, will save you much consternation later. I
can't fault you for choosing a "simpler" one-table database ( which is
actually a more complex mess of data ) -- I've had to re-teach myself
this lesson by doing things the hard way many times ;)

Also, what do you mean by re-inventing the wheel? What specifically
are you referring to?

lawpoop:

> Also, what do you mean by re-inventing the wheel? What specifically
> are you referring to?

Although I'm not the OP, I think it's quite obvious.
If he used a sequential file (CSV type), he would have to
- use array- or CSV application functions to filter on separate fields
- use a custom function for sorting data
- write a custom program if he wanted to add a field or change the 
field order/type in order to reorganize the existing data

With a mySQL table and tools like phpMyAdmin, he can manipulate his 
data and file structure more easily.


-- 
Erick

Erick T. Barkhuis wrote:
> lawpoop:
> 
>> Also, what do you mean by re-inventing the wheel? What specifically
>> are you referring to?
> 
> Although I'm not the OP, I think it's quite obvious.
> If he used a sequential file (CSV type), he would have to
> - use array- or CSV application functions to filter on separate fields
> - use a custom function for sorting data
> - write a custom program if he wanted to add a field or change the 
> field order/type in order to reorganize the existing data
.... or selecting transactions over n days old that haven't been 
answered, or completed, and so on, and so on.

> 
> With a mySQL table and tools like phpMyAdmin, he can manipulate his 
> data and file structure more easily.
.... and if, as suggested elsewhere, the client's needs evolve adding 
additional fields and tables isn't a major project.


-- 
Bill

"William Gill" <nospam@domain.invalid> wrote in message 
news:zT5Bm.56773$bP1.46142@newsfe24.iad...
> Erick T. Barkhuis wrote:
>> lawpoop:
>>
>>> Also, what do you mean by re-inventing the wheel? What 
>>> specifically
>>> are you referring to?
>>
>> Although I'm not the OP, I think it's quite obvious.
>> If he used a sequential file (CSV type), he would have to
>> - use array- or CSV application functions to filter on separate 
>> fields
>> - use a custom function for sorting data
>> - write a custom program if he wanted to add a field or change the 
>> field order/type in order to reorganize the existing data
> ... or selecting transactions over n days old that haven't been 
> answered, or completed, and so on, and so on.
>
>>
>> With a mySQL table and tools like phpMyAdmin, he can manipulate his 
>> data and file structure more easily.
> ... and if, as suggested elsewhere, the client's needs evolve adding 
> additional fields and tables isn't a major project.
>
>
> -- 
> Bill

You can just say that you have a relational database with some virtual 
tables and a 0:n relationships...
Or does this sound too much like politics? ;-)

I wouldnt even think twice of putting this into a database. So many 
advantages.


Richard 

Richard wrote:

> You can just say that you have a relational database with some virtual 
> tables and a 0:n relationships...
> Or does this sound too much like politics? ;-)
> 
> I wouldnt even think twice of putting this into a database. So many 
> advantages.
I won't get into the politics or theology.

There is a saying that when the only tool you have is a hammer, 
everything looks like a nail.  I was afraid I might be guilty of the 
MySQL version.  :-)

Thanks for confirming it's not a tunnel vision issue.


-- 
Bill

William Gill wrote:

> I have a simple tracking application that seems to only require one
> table with fields that can be updated and tracked.  So far I can see no
> reason for any other tables, because even the status fields are binary
> (not done/done, yes / no, etc.).
> 
> It seams this shouldn't require a relational database, but why recreate
> the wheel writing all the data manipulation functions when MySQL has
> already done the legwork?

For something that seems rather simple, if you don't need intensive
concurrent acces why don't your choose sqlite ?

http://www.sqlite.org/whentouse.html

"Situations Where SQLite Works Well : 

Replacement for ad hoc disk files

Many programs use fopen(), fread(), and fwrite() to create and manage files
of data in home-grown formats. SQLite works particularly well as a
replacement for these ad hoc data files."

On Oct 13, 5:00=A0pm, William Gill <nos...@domain.invalid> wrote:

> ... and if, as suggested elsewhere, the client's needs evolve adding
> additional fields and tables isn't a major project.

Simply adding a field or a table isn't a major project, but splitting
out the design you posted into 'donors' and 'donations' will be a
nightmare. I guess you'll be trying to do it by name, which will never
be spelled consistently. I note that there's only one field for name
-- is that last name first, or last name last? What about titles?

Trying to identify the 'same' name in that single field, spelled any
way the data entry person felt like at that moment, is not
automateable ( no script or query will be able to match "O'Donnell,
Patrick" to "patrik odonnel" or "Dr. Amir Rashid" to "Rasheed Amer" ).
You'll have to compare every record to every other record *manually*.
Imagine how long this will take if there's more than a few dozen
donations.

And you know what isn't very difficult? Just setting up
'donors'  ( with `last_name`, `first_name`, `title`, etc ) and
'donations' from the get-go.

lawpoop wrote:
> Simply adding a field or a table isn't a major project, but splitting
> out the design you posted into 'donors' and 'donations' will be a
> nightmare. I guess you'll be trying to do it by name, which will never
> be spelled consistently. I note that there's only one field for name
> -- is that last name first, or last name last? What about titles?
> 
> Trying to identify the 'same' name in that single field, spelled any
> way the data entry person felt like at that moment, is not
> automateable ( no script or query will be able to match "O'Donnell,
> Patrick" to "patrik odonnel" or "Dr. Amir Rashid" to "Rasheed Amer" ).
> You'll have to compare every record to every other record *manually*.
> Imagine how long this will take if there's more than a few dozen
> donations.
> 
> And you know what isn't very difficult? Just setting up
> 'donors'  ( with `last_name`, `first_name`, `title`, etc ) and
> 'donations' from the get-go.
The original question was about a single table db.  You suggestions on 
improving the fields in that table are worth implementing (though 
renaming 'amount' to 'donations' doesn't seem to buy much).  It might 
even be a good idea to add a couple address related fields to make 
sending the thank you notes a little easier. :-) However I don't see 
anything in their application that warrants additional tables.  They 
aren't going to maintain a donor list.  They just want to be sure they 
thank John Doe for his donation whether it is the same John Doe they 
thanked a month ago or another John Doe.


-- 
Bill

Alarch wrote:
> William Gill wrote:
> 
>> I have a simple tracking application that seems to only require one
>> table with fields that can be updated and tracked.  So far I can see no
>> reason for any other tables, because even the status fields are binary
>> (not done/done, yes / no, etc.).
>>
>> It seams this shouldn't require a relational database, but why recreate
>> the wheel writing all the data manipulation functions when MySQL has
>> already done the legwork?
> 
> For something that seems rather simple, if you don't need intensive
> concurrent acces why don't your choose sqlite ?
> 
> http://www.sqlite.org/whentouse.html
> 
> "Situations Where SQLite Works Well : 
> 
> Replacement for ad hoc disk files
> 
> Many programs use fopen(), fread(), and fwrite() to create and manage files
> of data in home-grown formats. SQLite works particularly well as a
> replacement for these ad hoc data files."
> 
Actually I am looking into SQLite, but it adds a whole new learning 
curve. :-)

-- 
Bill

On 10/14/2009 09:29 PM, William Gill wrote:
> lawpoop wrote:
>> Simply adding a field or a table isn't a major project, but splitting
>> out the design you posted into 'donors' and 'donations' will be a
>> nightmare. I guess you'll be trying to do it by name, which will never
>> be spelled consistently. I note that there's only one field for name
>> -- is that last name first, or last name last? What about titles?
>>
>> Trying to identify the 'same' name in that single field, spelled any
>> way the data entry person felt like at that moment, is not
>> automateable ( no script or query will be able to match "O'Donnell,
>> Patrick" to "patrik odonnel" or "Dr. Amir Rashid" to "Rasheed Amer" ).
>> You'll have to compare every record to every other record *manually*.
>> Imagine how long this will take if there's more than a few dozen
>> donations.
>>
>> And you know what isn't very difficult? Just setting up
>> 'donors'  ( with `last_name`, `first_name`, `title`, etc ) and
>> 'donations' from the get-go.
> The original question was about a single table db.  You suggestions on
> improving the fields in that table are worth implementing (though
> renaming 'amount' to 'donations' doesn't seem to buy much).  It might
> even be a good idea to add a couple address related fields to make
> sending the thank you notes a little easier. :-) However I don't see
> anything in their application that warrants additional tables.  They
> aren't going to maintain a donor list.  They just want to be sure they
> thank John Doe for his donation whether it is the same John Doe they
> thanked a month ago or another John Doe.

That's sad on their part; I for one would love to contact, send
greetings and, or calls for raising more funds if that NGO and, or
Religious organization needs some more for yet another great cause,
possibly by email, snail mail and, or phone.

-- 
Balwinder S "bdheeman" Dheeman        Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe)        Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India         Plan9, T2, Arch/Debian/FreeBSD/XP
Home: http://werc.homelinux.net/      Visit: http://counter.li.org/

On Oct 14, 11:59=A0am, William Gill <nos...@domain.invalid> wrote:

> The original question was about a single table db. =A0... However I don't=
 see
> anything in their application that warrants additional tables.

User specs shouldn't include things like "Have 10 tables" or "have 1
table". It's not in their design specs where you find the reason to
create an additional table, it's in relational theory itself. The
reality you are modeling is one donor makes many donations, not that
each donation has a unique donor. If you have a unique donor for each
donation ( which is what you described in your CREATE TABLE ), you are
making an inaccurate model of the situation.

Now, if the users came to you and said "We have a situation where a
person can only make a single donation or our organization, ever",
then yes, that would be a reason to have a single table, from a
relational point of view ;)

lawpoop:
> On Oct 14, 11:59�am, William Gill <nos...@domain.invalid> wrote:
> 
> > The original question was about a single table db. �... However I don't see
> > anything in their application that warrants additional tables.
> 
> User specs shouldn't include things like "Have 10 tables" or "have 1
> table". It's not in their design specs where you find the reason to
> create an additional table, it's in relational theory itself. The
> reality you are modeling is one donor makes many donations, not that
> each donation has a unique donor. If you have a unique donor for each
> donation ( which is what you described in your CREATE TABLE ), you are
> making an inaccurate model of the situation.

I believe this is too simply put.
After all, you (and most application developers) won't have any problem 
with defining 'date of birth' as an attribute of ClubMember. The 
'reality' is, that on one date, more than one ClubMember is born. It's 
a one-to-many phenomenon. Now, you still won't make DateOfBirth an 
entity in your Data Model, are you?

It is a misconception, that the 'reality' has a certain structure, that 
developers must find and project into a data model. A structure 
(entities and relationships) is _defined_ by the analist, based upon 
the processes that are taking place and the information requirements 
that exist. Most importantly, it's the _output_ of the system that 
dictates, which structure elements (entities) are to be defined, and 
what relationships (of all existing ones) are to be selected for the 
Data Model. A Data Model is _always_ a simplified projection of the 
reality, and the requirements lead you to what to keep, and what to 
ignore. In other words: the same 'reality' can lead to different Data 
Models, depending on how the application is to be used.

====

That said, I was also surprised, that the OP insisted that Donor will 
not ever become an entity of importance ("and if it would, then it's no 
big deal to introduce the entity"). I agree with you, that introducing 
this entity (creating this table) afterwards would become a pain in the 
ass. The data conversion would be non-trivial.

====

In summary:
- the 'reality' does not dictate a separate table 'Donor', because the 
developer and the project customer decide what the reality looks like.
- in this specific case, I would rather be safe than sorry, and define 
the Donor entity (and thus a second table), anyway.
 

-- 
Erick

On Oct 14, 2:33=A0pm, Erick T. Barkhuis <erick.use-...@ardane.c-o-m>
wrote:

>
> In summary:
> - the 'reality' does not dictate a separate table 'Donor', because the
> developer and the project customer decide what the reality looks like.
> - in this specific case, I would rather be safe than sorry, and define
> the Donor entity (and thus a second table), anyway.

Erick, you bring up a lot of good points.

I want to believe that there is a better 'relational' answer of why
you have one date per donation and not a separate table, but I don't
know what it is. My intuition is telling me something like, "I would
never want to query the table of dates by itself" -- because it's not
the set of all dates, it's the set of all donation dates ( a subset of
all dates ) -- it doesn't exist independently of donations, so there
is a one-to-one relation... or something like that.

Anywho, then how would you go about convincing a novice that `donors`
and `donations` is the right way to go? What is the safety here, and
where could the sorry arise? Your argument is that the output dictates
the database structure. Well, the OP has outlined the output, and the
Single Table meets the criteria. For what reason, then, would you make
two tables?

I can agree that the donor as an entity may never become of
importance, but if it does, there is a big mess in the Single Table,
and it's hard to clean up. I've been there before.

Erick T. Barkhuis wrote:
> lawpoop:
>> User specs shouldn't include things like "Have 10 tables" or "have 1
>> table". It's not in their design specs where you find the reason to
>> create an additional table, it's in relational theory itself. The
>> reality you are modeling is one donor makes many donations, not that
>> each donation has a unique donor. If you have a unique donor for each
>> donation ( which is what you described in your CREATE TABLE ), you are
>> making an inaccurate model of the situation.
> 
> I believe this is too simply put.
> After all, you (and most application developers) won't have any problem 
> with defining 'date of birth' as an attribute of ClubMember. The 
> 'reality' is, that on one date, more than one ClubMember is born. It's 
> a one-to-many phenomenon. Now, you still won't make DateOfBirth an 
> entity in your Data Model, are you?
> 
> It is a misconception, that the 'reality' has a certain structure, that 
> developers must find and project into a data model. A structure 
> (entities and relationships) is _defined_ by the analist, based upon 
> the processes that are taking place and the information requirements 
> that exist. Most importantly, it's the _output_ of the system that 
> dictates, which structure elements (entities) are to be defined, and 
> what relationships (of all existing ones) are to be selected for the 
> Data Model. A Data Model is _always_ a simplified projection of the 
> reality, and the requirements lead you to what to keep, and what to 
> ignore. In other words: the same 'reality' can lead to different Data 
> Models, depending on how the application is to be used.
> 
> ====
> 
> That said, I was also surprised, that the OP insisted that Donor will 
> not ever become an entity of importance ("and if it would, then it's no 
> big deal to introduce the entity"). I agree with you, that introducing 
> this entity (creating this table) afterwards would become a pain in the 
> ass. The data conversion would be non-trivial.
> 
> ====
> 
> In summary:
> - the 'reality' does not dictate a separate table 'Donor', because the 
> developer and the project customer decide what the reality looks like.
> - in this specific case, I would rather be safe than sorry, and define 
> the Donor entity (and thus a second table), anyway.
Before this gets too far afield.  I appreciate everything discussed thus
far, and considered many, if not all points mentioned.

The customer spec did not decide the number of tables.  Why should they
care I don't charge by the table.  Come to think of it I don't charge
them period.  Their spec was quite simple.  "We need a simple way of
tracking that we acknowledge each donation in a timely manner, and
knowing that checks or charges have cleared in a timely manner."  From 
that I did a preliminary design and was surprised that if I used a 
database (to take advantage of available functionality) I only needed
one table.  This struck me as interesting, ergo I posted.  Unfortunately
when I whipped up a poor example CREATE for purposes of this thread it 
may have misled everyone.

As stated and planned the only entity is a donation.  To elaborate, they
didn't want to track (or harass) donors, only insure every donation was 
deposited and acknowledged in a timely manner.  So from the standpoint 
of their needs; John Doe making a donation on Jan. 23 is one entity, 
when he donates again in March it's another entity (same John Doe or not).


-- 
Bill

William Gill wrote:

> Alarch wrote:
 
>> For something that seems rather simple, if you don't need intensive
>> concurrent acces why don't your choose sqlite ?
>> 
>> http://www.sqlite.org/whentouse.html
>> 
>> "Situations Where SQLite Works Well :
>> 
>> Replacement for ad hoc disk files
>> 
>> Many programs use fopen(), fread(), and fwrite() to create and manage
>> files of data in home-grown formats. SQLite works particularly well as a
>> replacement for these ad hoc data files."
>> 
> Actually I am looking into SQLite, but it adds a whole new learning
> curve. :-)

Not exactly, SQLite understand a very standard SQL, has implemented the most
important SQL features, and sqlite connexion functions are present in
TCL/Tk, Php, Python, Perl, and of course C/C++ and I suppose a lot of other
languages. If you are able to write a program using MySQL, you can easily
write a program for SQLite, the learning curve is not very important. But
we are on a MySQL list, so I stop here with this subject ! ;-D

William Gill wrote:
> Erick T. Barkhuis wrote:
>> lawpoop:
>>> User specs shouldn't include things like "Have 10 tables" or "have 1
>>> table". It's not in their design specs where you find the reason to
>>> create an additional table, it's in relational theory itself. The
>>> reality you are modeling is one donor makes many donations, not that
>>> each donation has a unique donor. If you have a unique donor for each
>>> donation ( which is what you described in your CREATE TABLE ), you are
>>> making an inaccurate model of the situation.
>>
>> I believe this is too simply put.
>> After all, you (and most application developers) won't have any 
>> problem with defining 'date of birth' as an attribute of ClubMember. 
>> The 'reality' is, that on one date, more than one ClubMember is born. 
>> It's a one-to-many phenomenon. Now, you still won't make DateOfBirth 
>> an entity in your Data Model, are you?
>>
>> It is a misconception, that the 'reality' has a certain structure, 
>> that developers must find and project into a data model. A structure 
>> (entities and relationships) is _defined_ by the analist, based upon 
>> the processes that are taking place and the information requirements 
>> that exist. Most importantly, it's the _output_ of the system that 
>> dictates, which structure elements (entities) are to be defined, and 
>> what relationships (of all existing ones) are to be selected for the 
>> Data Model. A Data Model is _always_ a simplified projection of the 
>> reality, and the requirements lead you to what to keep, and what to 
>> ignore. In other words: the same 'reality' can lead to different Data 
>> Models, depending on how the application is to be used.
>>
>> ====
>>
>> That said, I was also surprised, that the OP insisted that Donor will 
>> not ever become an entity of importance ("and if it would, then it's 
>> no big deal to introduce the entity"). I agree with you, that 
>> introducing this entity (creating this table) afterwards would become 
>> a pain in the ass. The data conversion would be non-trivial.
>>
>> ====
>>
>> In summary:
>> - the 'reality' does not dictate a separate table 'Donor', because the 
>> developer and the project customer decide what the reality looks like.
>> - in this specific case, I would rather be safe than sorry, and define 
>> the Donor entity (and thus a second table), anyway.
> Before this gets too far afield.  I appreciate everything discussed thus
> far, and considered many, if not all points mentioned.
> 
> The customer spec did not decide the number of tables.  Why should they
> care I don't charge by the table.  Come to think of it I don't charge
> them period.  Their spec was quite simple.  "We need a simple way of
> tracking that we acknowledge each donation in a timely manner, and
> knowing that checks or charges have cleared in a timely manner."  From 
> that I did a preliminary design and was surprised that if I used a 
> database (to take advantage of available functionality) I only needed
> one table.  This struck me as interesting, ergo I posted.  Unfortunately
> when I whipped up a poor example CREATE for purposes of this thread it 
> may have misled everyone.
> 
> As stated and planned the only entity is a donation.  To elaborate, they
> didn't want to track (or harass) donors, only insure every donation was 
> deposited and acknowledged in a timely manner.  So from the standpoint 
> of their needs; John Doe making a donation on Jan. 23 is one entity, 
> when he donates again in March it's another entity (same John Doe or not).
> 
> 

That's a dangerous assumption to make.  From my perspective, the 
client's requirements are insufficiently defined.  I'd be asking more 
questions before starting to design anything.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jerry Stuckle wrote:
> That's a dangerous assumption to make.  From my perspective, the 
> client's requirements are insufficiently defined.  I'd be asking more 
> questions before starting to design anything.
If this was a corporate, paying client I would have expended a great 
deal of time and effort defining and refining their requirements before 
doing anything else, but as it is even if I have to start all over from 
scratch it's no big deal.  This is an exception to my normal operating 
parameters.  I donate a couple hours, and they get away from keeping 
track on scraps and post-its.


-- 
Bill

William Gill wrote:
> Jerry Stuckle wrote:
>> That's a dangerous assumption to make.  From my perspective, the 
>> client's requirements are insufficiently defined.  I'd be asking more 
>> questions before starting to design anything.
> If this was a corporate, paying client I would have expended a great 
> deal of time and effort defining and refining their requirements before 
> doing anything else, but as it is even if I have to start all over from 
> scratch it's no big deal.  This is an exception to my normal operating 
> parameters.  I donate a couple hours, and they get away from keeping 
> track on scraps and post-its.
> 
> 

I handle my pro bono clients the same way I handle paying corporate 
clients.  I get the information up front and do it right the first time 
(at least until the requirements change).  It saves a lot of time in the 
long run.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

lawpoop: 
> On Oct 14, 2:33�pm, Erick T. Barkhuis <erick.use-...@ardane.c-o-m>
> wrote:
> 
> >
> > In summary:
> > - the 'reality' does not dictate a separate table 'Donor', because the
> > developer and the project customer decide what the reality looks like.
> > - in this specific case, I would rather be safe than sorry, and define
> > the Donor entity (and thus a second table), anyway.
> 
> I want to believe that there is a better 'relational' answer of why
> you have one date per donation and not a separate table, but I don't
> know what it is. My intuition is telling me something like, "I would
> never want to query the table of dates by itself" -- because it's not
> the set of all dates, it's the set of all donation dates ( a subset of
> all dates ) -- it doesn't exist independently of donations, so there
> is a one-to-one relation... or something like that.

That's fair enough. 
I think it would be equally fair to say that an entity Date doesn't 
have any attributes. That holds, as long as you really don't want any 
attributes. However, if you want to know what Donations were done on 
Easter Sunday, or on Mother's Day, it is a different issue. Then all of 
a sudden, one might consider Date an entity, worth having its own table.


> Anywho, then how would you go about convincing a novice that `donors`
> and `donations` is the right way to go? What is the safety here, and
> where could the sorry arise? Your argument is that the output dictates
> the database structure. Well, the OP has outlined the output, and the
> Single Table meets the criteria. For what reason, then, would you make
> two tables?

Exactly for the same reasons you would do so:
1. You expect that, like in many organizations, the requirements will 
expand, and business managers will _expect_ that they can come back 
after a year, and say "We have a database, don't we? Let's have a list 
of our Donors, and...." or "How many Donors offer us money more than 
once a year?". These people will look bewildered if the programmer 
replies: "won't be possible...you never mentioned that as a 
requirement, and now, it's too late."
2. For more experienced developers, it's just the gut feeling: we are 
talking about people donating money...that sounds like at least two 
entities.

> 
> I can agree that the donor as an entity may never become of
> importance, but if it does, there is a big mess in the Single Table,
> and it's hard to clean up. I've been there before.

We agree on that.
However, I can understand William as well. All they want to have is a 
list of donations and make sure the thankyou note gets out. Who are we 
to second guess how that organization is run? The organization and 
William will, together, know best what they need.

On one hand, I think ICT developers are smart people who can offer 
bright suggestions....on the other hand, I'm afreed they go too far 
once in a while (at least I do) by telling the business people:
- how to run their business
- what they Really (Have To) Want. :-)



-- 
Erick

On Wed, 14 Oct 2009 21:43:37 -0400, Jerry Stuckle wrote:
> William Gill wrote:
>> Jerry Stuckle wrote:
>>> That's a dangerous assumption to make.  From my perspective, the 
>>> client's requirements are insufficiently defined.  I'd be asking more 
>>> questions before starting to design anything.
>> If this was a corporate, paying client I would have expended a great 
>> deal of time and effort defining and refining their requirements before 
>> doing anything else, but as it is even if I have to start all over from 
>> scratch it's no big deal.  This is an exception to my normal operating 
>> parameters.  I donate a couple hours, and they get away from keeping 
>> track on scraps and post-its.
>> 
>> 
>
> I handle my pro bono clients the same way I handle paying corporate 
> clients.  I get the information up front and do it right the first time 
> (at least until the requirements change).  It saves a lot of time in the 
> long run.

Because, oddly, the ones getting the work for free don't tend to
value the time spent on the job as much as those paying for each
precious hour... An aquaintence won't talk to free "client" on the
phone or answer their emails. He meets them in a restaurant, with the
understanding that the client picks up the check every time.

-- 
Yes, Java is so bulletproofed that to a C programmer it feels like being in a
straightjacket, but it's a really comfy and warm straightjacket, and the world
would be a safer place if everyone was straightjacketed most of the time.
			    -- Mark 'Kamikaze' Hughes

On Thu, 15 Oct 2009 08:08:52 +0200, Erick T  Barkhuis wrote:
> That's fair enough. 
> I think it would be equally fair to say that an entity Date doesn't 
> have any attributes. That holds, as long as you really don't want any 
> attributes. However, if you want to know what Donations were done on 
> Easter Sunday, or on Mother's Day, it is a different issue. Then all of 
> a sudden, one might consider Date an entity, worth having its own table.

That's pretty much the whole point: whether some kind of data are
are mere attributes of other data or are entities on their own depends
entirely on what you want to DO with them.

Comparably, more what I do commonly is addresses: often DB designers
will think an address is an attribute of a person. That's where they
get their mail. But where they get their mail may be different from
where they live (like they have a postal service box instead of home
delivery), and different from where they work. And they'll work for
organizations that may have several buildings scattered around the city,
so many people working for the same organization will get mail at any of
several offices (often with individual routing codes then joining to
that common address), or prefer to get mail deliver to their home or
post box, but couriered mail never goes to post boxes, etc, etc. Which
ends up meaning that the database has a table for ORG, that has an 1:n
relationship with PERSON, which has a routing column and a n:n
relationship (with attributes of "preferred") with ADDRESS (that has a
purely descriptive type and flags for "courierable"), and ORG also has
n:n relationship with ADDRESS. It's far more complicate than people
expect thinking about "addresses" but that's what's necessary to model
the data in ways that's useful to the client. Phone number is almost as
bad, once you start looking at how many can be used to reach a given
person, and how likely it is that a more than one person may share a
number, who gets charged for the call, permissions to call, etc.. 

-- 
Yes, Java is so bulletproofed that to a C programmer it feels like being in a
straightjacket, but it's a really comfy and warm straightjacket, and the world
would be a safer place if everyone was straightjacketed most of the time.
			    -- Mark 'Kamikaze' Hughes

Jerry Stuckle wrote:
> I handle my pro bono clients the same way I handle paying corporate 
> clients.  I get the information up front and do it right the first time 
> (at least until the requirements change).  It saves a lot of time in the 
> long run.
As a rule so do I.  However, "right" is often situational.  When I see 
someone struggling with scraps of paper and offer a simple solution, I 
don't tell them "In order for this to work "right" I need to do a 
complete analysis and you have to change a lot of how you operate." 
It's one thing to use the tools and skill set available to improve a 
process, and quite another to think a fairly small voluntary group is 
going to be able to operate like a multi-national corporation (even if 
they think they are).

Bottom line, I hear and appreciate everything discussed here, but the 
situational's will dictate the actual implementation.  I could go point 
by point and say "That's a good point, but that's not the case here." 
but that would appear argumentative, or defensive, and might put off 
valued input in the future.

I posted to foster a semi-philosophical discussion, and have appreciated 
the entire exchange.  However, I don't want this to descend into a 
"religious" discussion that holds that there is only one "right way" and 
all that don't follow it are infidels. :-)

One Usenet problem is striking a balance when pointing out something the 
a poster might not have considered.  Pointing it out can easily offend 
because the recipient may think "I know that, what kind of nit wit do 
you think I am."  On the other hand they might just as likely say "Oops, 
I missed that."  Conversely, someone offering advice, can easily assume 
the questioner doesn't know, or hasn't already considered a (valid) 
point, or worse just isn't listening.  It's simply not possible to 
condense a lifetime of experience (i.e. management experience in a 
multi-national corporation) or all the situational details into a Usenet 
post, so we muddle along.  In this case, I oversimplified requirements, 
and would have regretted the oversight.  However the final complexity 
will in no way approximate a "normal" business implementation.


-- 
Bill

Erick T. Barkhuis wrote:
> lawpoop: 
>> On Oct 14, 2:33 pm, Erick T. Barkhuis <erick.use-...@ardane.c-o-m>
>> wrote:
>>
>>> In summary:
>>> - the 'reality' does not dictate a separate table 'Donor', because the
>>> developer and the project customer decide what the reality looks like.
>>> - in this specific case, I would rather be safe than sorry, and define
>>> the Donor entity (and thus a second table), anyway.
>> I want to believe that there is a better 'relational' answer of why
>> you have one date per donation and not a separate table, but I don't
>> know what it is. My intuition is telling me something like, "I would
>> never want to query the table of dates by itself" -- because it's not
>> the set of all dates, it's the set of all donation dates ( a subset of
>> all dates ) -- it doesn't exist independently of donations, so there
>> is a one-to-one relation... or something like that.
> 
> That's fair enough. 
> I think it would be equally fair to say that an entity Date doesn't 
> have any attributes. That holds, as long as you really don't want any 
> attributes. However, if you want to know what Donations were done on 
> Easter Sunday, or on Mother's Day, it is a different issue. Then all of 
> a sudden, one might consider Date an entity, worth having its own table.
I might consider an additional table, then again I might consider a 
SELECT if date = Easter.

Even if I consider a Holiday table and Easter and Mother's Day as 
entities, I have to take into account that they fall on different days 
each year.  Does that argue a date is an attribute of both tables, and 
select when it is found in both?


-- 
Bill

Peter H. Coffin wrote:
> On Wed, 14 Oct 2009 21:43:37 -0400, Jerry Stuckle wrote:
>> William Gill wrote:
>>> Jerry Stuckle wrote:
>>>> That's a dangerous assumption to make.  From my perspective, the 
>>>> client's requirements are insufficiently defined.  I'd be asking more 
>>>> questions before starting to design anything.
>>> If this was a corporate, paying client I would have expended a great 
>>> deal of time and effort defining and refining their requirements before 
>>> doing anything else, but as it is even if I have to start all over from 
>>> scratch it's no big deal.  This is an exception to my normal operating 
>>> parameters.  I donate a couple hours, and they get away from keeping 
>>> track on scraps and post-its.
>>>
>>>
>> I handle my pro bono clients the same way I handle paying corporate 
>> clients.  I get the information up front and do it right the first time 
>> (at least until the requirements change).  It saves a lot of time in the 
>> long run.
> 
> Because, oddly, the ones getting the work for free don't tend to
> value the time spent on the job as much as those paying for each
> precious hour... An aquaintence won't talk to free "client" on the
> phone or answer their emails. He meets them in a restaurant, with the
> understanding that the client picks up the check every time.
> 

Overall, I would say that's true.  There are exceptions, but those are 
rather rare.

I like your acquaintance's idea - some people want to bug you several 
times a day over the smallest things :)

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Oct 15, 10:46=A0am, William Gill <nos...@domain.invalid> wrote:

> I posted to foster a semi-philosophical discussion, and have appreciated
> the entire exchange. =A0However, I don't want this to descend into a
> "religious" discussion that holds that there is only one "right way" and
> all that don't follow it are infidels. :-)

Thank you for letting us use your scenario to have a civil,
philosophical discussion! I know I drove you pretty hard, but you kept
your cool. :)

William Gill:
> Erick T. Barkhuis wrote:

> > ... However, if you want to know what Donations were done on 
> > Easter Sunday, or on Mother's Day, it is a different issue. Then all of 
> > a sudden, one might consider Date an entity, worth having its own table.

> I might consider an additional table, then again I might consider a 
> SELECT if date = Easter.
> 
> Even if I consider a Holiday table and Easter and Mother's Day as 
> entities, 

Hold on. That sounds strange.
Before we go into any what-ifs, or enter data modeling discussions: are 
you familiar with data modeling and terms like entities, cardinality, 
etc.?

From this:
> I have to take into account that they fall on different days 
> each year.  Does that argue a date is an attribute of both tables, and 
> select when it is found in both?
....frankly, I believe you are not quite into the topic.
Shouldn't we rather leave it as is? I think you've got several useful 
answers to your initial question, and my impression is, that you are 
very well capable of making up your own mind about the proper solution, 
now. 

-- 
Erick

Erick T. Barkhuis wrote:
> William Gill:
>> Erick T. Barkhuis wrote:
> 
>>> ... However, if you want to know what Donations were done on 
>>> Easter Sunday, or on Mother's Day, it is a different issue. Then all of 
>>> a sudden, one might consider Date an entity, worth having its own table.
> 
>> I might consider an additional table, then again I might consider a 
>> SELECT if date = Easter.
>>
>> Even if I consider a Holiday table and Easter and Mother's Day as 
>> entities, 
> 
> Hold on. That sounds strange.
> Before we go into any what-ifs, or enter data modeling discussions: are 
> you familiar with data modeling and terms like entities, cardinality, 
> etc.?
Not an expert but I have a working familiarity.

> 
> From this:
>> I have to take into account that they fall on different days 
>> each year.  Does that argue a date is an attribute of both tables, and 
>> select when it is found in both?
> ...frankly, I believe you are not quite into the topic.
> Shouldn't we rather leave it as is? I think you've got several useful 
> answers to your initial question, and my impression is, that you are 
> very well capable of making up your own mind about the proper solution, 
> now. 
> 
Apologies, you are correct I have gotten enough to resolve the initial 
post which was more a curiosity, than a problem. I had never designed 
(in my relatively limited experience) a database that didn't require 
more than one table before.

I was responding here to the proposition that once you distinguish one 
date from another by naming some dates that changes dates from an 
attribute to an entity.  I was simply proposing that I saw no need that 
queries couldn't fill.

At the risk of using improper terminology.  In the original app a date 
only exists as an attribute of a donation.  That means that if no 
donation was made, no thank-you mailed, no funds cleared, or record 
completed on a specific date, it does not exist.  It doesn't mean Sunday 
May 10, 2009 never happened, it means it doesn't exist in this 
application.  Calling May 10, 2009 Mother's Day doesn't seem to change 
that.  Where am I wrong?

-- 
Bill

William Gill:

> At the risk of using improper terminology.  In the original app a date 
> only exists as an attribute of a donation.  That means that if no 
> donation was made, no thank-you mailed, no funds cleared, or record 
> completed on a specific date, it does not exist.  It doesn't mean Sunday 
> May 10, 2009 never happened, it means it doesn't exist in this 
> application.  Calling May 10, 2009 Mother's Day doesn't seem to change 
> that.  Where am I wrong?

I think your perception of what an entity is, is not fully correct.
An entity is not a collection of all possible values of some 'object', 
but it's the definition of the object itself.

Simply put: if there's anything you want to store information about 
(any object that plays a role in your model of the world), it's an 
entity. So, a CalenderDate _can_ become an entity, as soon as you want 
to keep track of several of them, and assign them attributes. 

An example: if you have a radio station which has a few dozens 
transmission days a year, you have the entity TransmissionDay, possible 
with the date as Primary Key, and several attributes. Also, you will 
have another entity, called DJ, with all available diskjockeys 
(attributes: name, sex, voice pitch, etc.)
In this example, not every date on the calendar will become a record. 
Neither will every DJ on the World be entered in this table of 
diskjockeys. Still, TransmissionDay and DJ are entities.


In your case, if you want to have attributes for certain days, Date can 
become an entity in your ER Model. Attributes may be:
- specialDay  (e.g. "Easter" or "MothersDay")
- sunRise (e.g. 05:15am)
- todaysMotto (e.g. "<your favorite motto>")

-- 
Erick

Erick T. Barkhuis:

> I think your perception of what an entity is, is not fully correct.
> An entity is not a collection of all possible values of some 'object', 
> but it's the definition of the object itself.

For the OO developers here: I am using the word 'object' loosely, as 
you may understand. 

-- 
[just to avoid confusion]

Erick T. Barkhuis wrote:
> An entity is not a collection of all possible values of some 'object', 
> but it's the definition of the object itself.
> 
> Simply put: if there's anything you want to store information about 
> (any object that plays a role in your model of the world), it's an 
> entity. So, a CalenderDate _can_ become an entity, as soon as you want 
> to keep track of several of them, and assign them attributes. 
I may not have been as clear, but yes I understand what an entity is.

What I don't understand is your statement "However, if you want to know 
what Donations were done on Easter Sunday, or on Mother's Day, it is a 
different issue. Then all of a sudden, one might consider Date an 
entity, worth having its own table."

How is that any different than wanting to know what donations were done 
on May 10, 2009. Unless you are saying that by defining an entity 
Holiday (with a name attribute, and a date attribute) I wouldn't need to 
know Mother's Day was May 10, 2009.

In theory I can agree one might consider Holiday, not Date, an entity, 
worth having its own table.  In reality, I see the Holiday entity effort 
work than it is worth.

Am I missing something?

-- 
Bill

William Gill wrote:
I should clean my glasses more often.  I missed "So, a CalenderDate 
_can_ become an entity, as soon as you want to keep track of several of 
them, and assign them attributes. "

I think we are in agreement.


-- 
Bill

Erick T. Barkhuis wrote:
> I think your perception of what an entity is, is not fully correct.
> An entity is not a collection of all possible values of some 'object', 
> but it's the definition of the object itself.

I said "Even if I consider a Holiday table and Easter and Mother's Day 
as entities..."

I meant "Even if I consider a Holiday table and Easter and Mother's Day 
as instances of Holiday..."


-- 
Bill

William Gill:

> What I don't understand is your statement "However, if you want to know 
> what Donations were done on Easter Sunday, or on Mother's Day, it is a 
> different issue. Then all of a sudden, one might consider Date an 
> entity, worth having its own table."
> 
> How is that any different than wanting to know what donations were done 
> on May 10, 2009. 


Table: MyDates
- thedate     DATE (PK) NOT NULL
- holiday     ENUM(Easter,Thankg,Xmas) 
- shortnote   VARCHAR(80)


If you want to select all donations made on March 10, 2007, you don't 
need a table MyDates, since it's sufficient to have this date as an 
attribute of Donations.

However, if you want all Donations made three days around any Holiday 
date, you may want to decide to consider MyDate an entity, keep the 
dates in a separate table, and mark those dates as holiday as 
appropriate. That way, it will be much easier to project this 'reality' 
and search for the required periodes of time around holidays.


-- 
Erick

William Gill:
> Erick T. Barkhuis wrote:
> > I think your perception of what an entity is, is not fully correct.
> > An entity is not a collection of all possible values of some 'object', 
> > but it's the definition of the object itself.
> 
> I said "Even if I consider a Holiday table and Easter and Mother's Day 
> as entities..."
> 
> I meant "Even if I consider a Holiday table and Easter and Mother's Day 
> as instances of Holiday..."

We're on different tracks, Bill. 
I didn't consider Holiday an entity. Holiday will be an attribute of 
Date. Not the other way around.

[Although, in fact, your approach may be appropriate in certain 
'realities'. I'm not saying it's wrong, just different from what I had 
in mind.]

Erick T. Barkhuis wrote:
> We're on different tracks, Bill. 
> I didn't consider Holiday an entity. Holiday will be an attribute of 
> Date. Not the other way around.
> 
> [Although, in fact, your approach may be appropriate in certain 
> 'realities'. I'm not saying it's wrong, just different from what I had 
> in mind.]

Table: MyDates
- thedate     DATE (PK) NOT NULL
- holiday     ENUM(Easter,Thankg,Xmas)
- shortnote   VARCHAR(80)

    vise

Table: Holidays
- thedate     DATE (PK) NOT NULL
- name        VARCHAR(20)
- shortnote   VARCHAR(80)

    or

Table: ClosedDays
- thedate     DATE (PK) NOT NULL
- name        VARCHAR(20)
- shortnote   VARCHAR(80)


I see, but now am curious about your approach.  Isn't enumerating 
holidays a little awkward and limiting?  On first pass MyDates seems to 
be limited to holidays?

I guess Holidays.name could be a pointer to a lookup table

- FK_HolidayNames TINYINT(4) NOT NULL



-- 
Bill

William Gill wrote:
> Erick T. Barkhuis wrote:
>> From your description, it's not clear what the situation is, and 
>> whether or not you already normalized. What does your data model look 
>> like? How many entities do you have, and what relationships exist?
>>
> Yes it is normalized with one deliberate violation (trantype).  There is 
> no customer table, or any need for one, so custname is not a lookup or 
> foreign key.
> 
> Here's the CREATE
> 
> CREATE TABLE  donations (
>   ID int(10) unsigned zerofill NOT NULL auto_increment,
>   trantype enum('CASH','CHECK','CREDIT') default 'CASH',
>   custname VARCHAR(45),
>   amount float NOT NULL,
>   trandate date NOT NULL,
>   mailed date NOT NULL,
>   fundsCleared date NOT NULL,
>   complete date NOT NULL,
>   PRIMARY KEY  (ID)
> )
> 
> 'mailed' is used to track thank you letters.
> 
> 'fundsCleared' is to track when credit or checks are deposited.
> 
> 'complete' lets them know the thank you has been sent and the funds have 
> cleared.  I could eliminate it in favor of testing for both 'mailed' and 
> 'fundsCleared' having valid dates.
> 
> At present 'complete' with dates older than n days are simply deleted, 
> but could be moved into an archive.
> 

How would you handle it if the same customer makes more than one 
donation?  In this scenario, you could combine the custname and trandate 
into a single unique key.  However, what if he makes a pledge in the 
morning and when he gets home his wife wants him to up the pledge, so he 
makes another one?

I think if best to separate the customer info from the tranaction info. 
  That would allow for a one to many relationship.  You would have at 
least two tables then.

lawpoop wrote:
> On Oct 13, 5:00 pm, William Gill <nos...@domain.invalid> wrote:
> 
>> ... and if, as suggested elsewhere, the client's needs evolve adding
>> additional fields and tables isn't a major project.
> 
> Simply adding a field or a table isn't a major project, but splitting
> out the design you posted into 'donors' and 'donations' will be a
> nightmare. I guess you'll be trying to do it by name, which will never
> be spelled consistently. I note that there's only one field for name
> -- is that last name first, or last name last? What about titles?
> 
> Trying to identify the 'same' name in that single field, spelled any
> way the data entry person felt like at that moment, is not
> automateable ( no script or query will be able to match "O'Donnell,
> Patrick" to "patrik odonnel" or "Dr. Amir Rashid" to "Rasheed Amer" ).
> You'll have to compare every record to every other record *manually*.
> Imagine how long this will take if there's more than a few dozen
> donations.
> 
> And you know what isn't very difficult? Just setting up
> 'donors'  ( with `last_name`, `first_name`, `title`, etc ) and
> 'donations' from the get-go.
> 

Amen.

William Gill:
> Erick T. Barkhuis wrote:

> Table: MyDates
> - thedate     DATE (PK) NOT NULL
> - holiday     ENUM(Easter,Thankg,Xmas)
> - shortnote   VARCHAR(80)
> 

> I see, but now am curious about your approach.  Isn't enumerating 
> holidays a little awkward and limiting?  On first pass MyDates seems to 
> be limited to holidays?
> 
> I guess Holidays.name could be a pointer to a lookup table
> 
> - FK_HolidayNames TINYINT(4) NOT NULL

Bill, although I mentioned this 'table' as example, I was really 
talking about data analysis, not technical design. The discussion was 
about entities, remember?

Now that we have entered a what-if, we are down to trying to find 
entities for our assumed reality. Any guess would be a good one, as 
long as we don't use terms like 'enumerating', 'pointer' and 'lookup'.

So...assume your Holiday is an entity. We also have Donor and Donation.
How would you suggest their relationships?

-- 
Erick

>> ... and if, as suggested elsewhere, the client's needs evolve adding
>> additional fields and tables isn't a major project.
>
>Simply adding a field or a table isn't a major project, but splitting
>out the design you posted into 'donors' and 'donations' will be a
>nightmare. I guess you'll be trying to do it by name, which will never
>be spelled consistently. I note that there's only one field for name
>-- is that last name first, or last name last? What about titles?

Even *having* a table for 'donors' as well as 'donations' can be a
problem.  You are about to enter a donation.  Which donor do you
associate with it?  You have the donor's name:  John Smith.  Your
user interface takes that, says that there are 23 close matches to
that name, including John M. Smith, and John Smythe, and offers you
a choice of those or adding a new donor.  If the database doesn't
prohibit it, you also have nine separate 'John Smith' entries.
However, your database cannot prohibit the existence of nine separate
people named 'John Smith' (no middle initial), three of whom have
the same address and phone number, and do not use suffixes.  On
what basis do you make a choice?

The organization's privacy policy says it will not track addresses,
phone numbers, birth dates, nor hand out donor numbers.  Most
donations arrive by mail so you don't get to ask questions.  And
if you have direct contact with the donor, you're not supposed to
ask nosy questions.  Accept the donation, thank the person, and
unless the donor asks questions, don't engage in further conversation.
The last thing the organization wants is a long line of donors
waiting impatiently behind one who is being forced to repeatedly
spell "1387 Suppercalifragilisticexpalidocious Avenue" because he
speaks in a thick accent.

>Trying to identify the 'same' name in that single field, spelled any
>way the data entry person felt like at that moment, is not
>automateable ( no script or query will be able to match "O'Donnell,
>Patrick" to "patrik odonnel" or "Dr. Amir Rashid" to "Rasheed Amer" ).
>You'll have to compare every record to every other record *manually*.
>Imagine how long this will take if there's more than a few dozen
>donations.

You're simply pushing the problem back on the data entry person.

>And you know what isn't very difficult? Just setting up
>'donors'  ( with `last_name`, `first_name`, `title`, etc ) and
>'donations' from the get-go.

Yes, that *IS* very difficult for the data entry person, unless
he simply creates a new donor entry for every donation.

Gordon Burditt: 

> Even *having* a table for 'donors' as well as 'donations' can be a
> problem.  You are about to enter a donation.  Which donor do you
> associate with it? 

You are absolutely right. That is a problem.
But...it's a general problem, that occurs at every web shop (for 
instance). Double entries occur all the time, and that's why companies 
like SAP have modules that try to eliminate them, which isn't easy.


> You have the donor's name:  John Smith.  Your
> user interface takes that, says that there are 23 close matches to
> that name, including John M. Smith, and John Smythe, and offers you
> a choice of those or adding a new donor.  If the database doesn't
> prohibit it, you also have nine separate 'John Smith' entries.
> However, your database cannot prohibit the existence of nine separate
> people named 'John Smith'  [...]

All very true.
But are you now saying, that modeling a Donor (or Customer in similar 
applications) shouldn't be done?

If you agree that there _is_ an entity Donor, then other ways have to 
be found to eliminate duplications as much as possible. Your user 
interface description is one. Checking on e-mail addresses might be 
another. Or you could supply "account user IDs" and offer Donors to go 
through that login-procedure to donate (as web shops often do).
This won't prevent all duplicates, but improves the process.

-- 
Erick

"I plead contemporary insanity."

>> Even *having* a table for 'donors' as well as 'donations' can be a
>> problem.  You are about to enter a donation.  Which donor do you
>> associate with it? 
>
>You are absolutely right. That is a problem.
>But...it's a general problem, that occurs at every web shop (for 
>instance). Double entries occur all the time, and that's why companies 
>like SAP have modules that try to eliminate them, which isn't easy.
>
>
>> You have the donor's name:  John Smith.  Your
>> user interface takes that, says that there are 23 close matches to
>> that name, including John M. Smith, and John Smythe, and offers you
>> a choice of those or adding a new donor.  If the database doesn't
>> prohibit it, you also have nine separate 'John Smith' entries.
>> However, your database cannot prohibit the existence of nine separate
>> people named 'John Smith'  [...]
>
>All very true.
>But are you now saying, that modeling a Donor (or Customer in similar 
>applications) shouldn't be done?

If the organization says there isn't a need to track donors, then
maybe it shouldn't be done if it causes problems (particularly
issues with their privacy policy).  Their data entry person might
be instructed to choose "add new donor" for every donation, since
your program is asking him an unanswerable question.

>If you agree that there _is_ an entity Donor, then other ways have to 
>be found to eliminate duplications as much as possible. Your user 

Which seem to involve adding more disambiguating information to the
database (which takes time and effort to maintain), which the
organization has promised NOT to track, and in any case, they claim
they don't need the information, so there's no reason to bother
entering it correctly.

>interface description is one. Checking on e-mail addresses might be 
>another. Or you could supply "account user IDs" and offer Donors to go 
>through that login-procedure to donate (as web shops often do).

The privacy policy says that donor's *NAMES* are the only personal
information kept (beyond, say, the week for a check or debit card
transaction to clear), and they cannot make donors remember account
numbers.

>This won't prevent all duplicates, but improves the process.

"Improvement" is in the eye of the beholder.  If the organization is
seen to violate their own privacy policy, there may well be no donations
to track.

Gordon Burditt: 

> The privacy policy says that donor's *NAMES* are the only personal
> information kept (beyond, say, the week for a check or debit card
> transaction to clear),

Then how do they send thankyou notes?

-- 
Erick

>> The privacy policy says that donor's *NAMES* are the only personal
>> information kept (beyond, say, the week for a check or debit card
>> transaction to clear),
>
>Then how do they send thankyou notes?

Remember the qualifier in parentheses.  You don't have to keep the
address any longer than it takes to mail the note.  That shouldn't
take a week unless this organization is getting flooded with
donations, in which case they can hire someone to handle some of
the work.  The address would be useless for disambiguating which
John Smith made this donation, since the address for older donations
isn't kept, but it could be still be used to send a note.

It is possible to copy a return address from an envelope onto a
thankyou note (with, if necessary, a quill pen) without having it
also get registered in a database.  Some donations can't have a
note sent for lack of return address (cash in a collection plate is
one obvious example).

There are a number of other questions I have about the OP's schema,
but NOT about having a donor table or not.  How do you track whether
a donation by check has cleared?  You need to somehow associate a
bounced check with a particular donation.  Some kind of transaction
ID assigned by the bank?  Same applies to debit cards.  I think
this could be taken care of by other fields in the single table,
without adding another table.
  

Gordon Burditt: 
> >> The privacy policy says that donor's *NAMES* are the only personal
> >> information kept (beyond, say, the week for a check or debit card
> >> transaction to clear),
> >
> >Then how do they send thankyou notes?
> 
> Remember the qualifier in parentheses.  You don't have to keep the
> address any longer than it takes to mail the note.  That shouldn't
> take a week unless this organization is getting flooded with
> donations, in which case they can hire someone to handle some of
> the work. 

I understand what you're saying, Gordon. And it makes sense.
There's just this one _reason_ why they are keeping these data in their 
database: they want to track, afterwards, whether or not all thankyou 
notes have gone out in a timely manner.

I'm picturing this: at the end of a month, in which 200 donations have 
been made, someone gets into that database and produces a list. To his 
surprise, he notices, that 20 donors have not been sent a thankyou note.
Now what?
If those notes need to be sent immediately, they need to have the 
contact data. They also need to know how many times a thankyou note is 
missing for this person...or at least that would be nice.

Now, if that's all not necessary, why would the organization keep track 
of the donor names? They could as will leave them out, too.


[It's not the creation and sending of the notes what the database is 
for, but tracking the process and finding notes that have never been 
written]



> It is possible to copy a return address from an envelope onto a
> thankyou note (with, if necessary, a quill pen) without having it
> also get registered in a database. 

This part confuses me. Are you saying that the addresses are to be kept 
on the envelopes, in big boxes, instead of keeping them in a database? 
Apart from the physical medium, what's the difference? And what would 
be the advantage of keeping them on old, used paper?

> 
> There are a number of other questions I have about the OP's schema [...]

So do I, but I'm not going to second-guess without knowing more about 
their processes.

-- 
Erick

Gordon Burditt wrote:
>>> ... and if, as suggested elsewhere, the client's needs evolve adding
>>> additional fields and tables isn't a major project.
>> Simply adding a field or a table isn't a major project, but splitting
>> out the design you posted into 'donors' and 'donations' will be a
>> nightmare. I guess you'll be trying to do it by name, which will never
>> be spelled consistently. I note that there's only one field for name
>> -- is that last name first, or last name last? What about titles?
> 
> Even *having* a table for 'donors' as well as 'donations' can be a
> problem.  You are about to enter a donation.  Which donor do you
> associate with it?  You have the donor's name:  John Smith.  Your
> user interface takes that, says that there are 23 close matches to
> that name, including John M. Smith, and John Smythe, and offers you
> a choice of those or adding a new donor.  If the database doesn't
> prohibit it, you also have nine separate 'John Smith' entries.
> However, your database cannot prohibit the existence of nine separate
> people named 'John Smith' (no middle initial), three of whom have
> the same address and phone number, and do not use suffixes.  On
> what basis do you make a choice?
> 
> The organization's privacy policy says it will not track addresses,
> phone numbers, birth dates, nor hand out donor numbers.  Most
> donations arrive by mail so you don't get to ask questions.  And
> if you have direct contact with the donor, you're not supposed to
> ask nosy questions.  Accept the donation, thank the person, and
> unless the donor asks questions, don't engage in further conversation.
> The last thing the organization wants is a long line of donors
> waiting impatiently behind one who is being forced to repeatedly
> spell "1387 Suppercalifragilisticexpalidocious Avenue" because he
> speaks in a thick accent.
> 
>> Trying to identify the 'same' name in that single field, spelled any
>> way the data entry person felt like at that moment, is not
>> automateable ( no script or query will be able to match "O'Donnell,
>> Patrick" to "patrik odonnel" or "Dr. Amir Rashid" to "Rasheed Amer" ).
>> You'll have to compare every record to every other record *manually*.
>> Imagine how long this will take if there's more than a few dozen
>> donations.
> 
> You're simply pushing the problem back on the data entry person.
> 
>> And you know what isn't very difficult? Just setting up
>> 'donors'  ( with `last_name`, `first_name`, `title`, etc ) and
>> 'donations' from the get-go.
> 
> Yes, that *IS* very difficult for the data entry person, unless
> he simply creates a new donor entry for every donation.
> 

Most organizations will provide receipts.  Receipts are required for 
larger donations for tax purposes, and any donations will be 
investigated during an audit.

Keeping the donors straight is a problem in any system.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Erick T. Barkhuis wrote:
> Gordon Burditt: 
>>>> The privacy policy says that donor's *NAMES* are the only personal
>>>> information kept (beyond, say, the week for a check or debit card
>>>> transaction to clear),
>>> Then how do they send thankyou notes?
>> Remember the qualifier in parentheses.  You don't have to keep the
>> address any longer than it takes to mail the note.  That shouldn't
>> take a week unless this organization is getting flooded with
>> donations, in which case they can hire someone to handle some of
>> the work. 
> 
> I understand what you're saying, Gordon. And it makes sense.
> There's just this one _reason_ why they are keeping these data in their 
> database: they want to track, afterwards, whether or not all thankyou 
> notes have gone out in a timely manner.
> 
> I'm picturing this: at the end of a month, in which 200 donations have 
> been made, someone gets into that database and produces a list. To his 
> surprise, he notices, that 20 donors have not been sent a thankyou note.
> Now what?
> If those notes need to be sent immediately, they need to have the 
> contact data. They also need to know how many times a thankyou note is 
> missing for this person...or at least that would be nice.
> 
> Now, if that's all not necessary, why would the organization keep track 
> of the donor names? They could as will leave them out, too.
> 
> 
> [It's not the creation and sending of the notes what the database is 
> for, but tracking the process and finding notes that have never been 
> written]

Suppose Jim Jones makes a donation, says his address is 123 Main (his 
work address).  That information is entered in a field and later used to 
address a thank you.  A week later he donates again as James Jones at 
987 Elm (his home address).  That's where the second thank you goes. 
The organization can track both transactions (real world transaction 
not database transaction) for timely and complete processing.

Mr. Jones can tell where the information to address the thank you came 
from.  But if he receives two solicitations, One addressed to Jim and 
one to James he knows he had been entered into a dreaded database 
somewhere.

Not a perfect example, but if procedurally the organization never 
actively initiates contact, but only acknowledges transactions donors 
initiated (with each donation) doesn't that eliminate the concern about 
duplicates, and at least mitigate spelling and typing mistakes?

As for analyzing if and how often thankyou notes are missing for an 
individual, wouldn't a reasonably competent person get a clear enough 
picture by looking at the list of all unanswered donations over x days 
old?  That is, assuming the list isn't an overwhelming report.  In which 
case the problem is a management issue, not a database issue.


-- 
Bill

William Gill:
> Erick T. Barkhuis wrote:

> > [It's not the creation and sending of the notes what the database is 
> > for, but tracking the process and finding notes that have never been 
> > written]
> 
> Suppose Jim Jones makes a donation, says his address is 123 Main (his 
> work address).  That information is entered in a field 

I thought you only entered the name, not the address.

> ...and later used to address a thank you.  A week later he donates 
> again as James Jones at 987 Elm (his home address). 

Sounds like a different person to me.

> That's where the second thank you goes. 
> The organization can track both transactions (real world transaction 
> not database transaction) for timely and complete processing.

Certainly.

> 
> Mr. Jones can tell where the information to address the thank you came 
> from.  But if he receives two solicitations, One addressed to Jim and 
> one to James he knows he had been entered into a dreaded database 
> somewhere.

Why? Didn't he present himself as two different persons?
 
> Not a perfect example, but if procedurally the organization never 
> actively initiates contact, but only acknowledges transactions donors 
> initiated (with each donation) doesn't that eliminate the concern about 
> duplicates, and at least mitigate spelling and typing mistakes?

It may. But then why do you track at all, keeping the names? Once you 
know what thankyou notes were NOT sent, what is the organization going 
to do with that knowledge?

> 
> As for analyzing if and how often thankyou notes are missing for an 
> individual, wouldn't a reasonably competent person get a clear enough 
> picture by looking at the list of all unanswered donations over x days 
> old?  That is, assuming the list isn't an overwhelming report.  In which 
> case the problem is a management issue, not a database issue.

Probably true. But that doesn't have anything to do with whether or not 
the information is stored in a database, right?.
Remember, you were the one who wanted to use a database, anyway. In 
that case, why not create a database in such a way that this 
information is not to be compiled from a carton box full of paperwork 
anymore?

-- 
Erick
[who hates to see parents calling their new born twins "Jim and Joe", or 
"Mickey and Minney". That's not funny, it's stupid]

On Oct 15, 2:24=A0pm, Erick T. Barkhuis <erick.use-...@ardane.c-o-m>
wrote:

> I think your perception of what an entity is, is not fully correct.
> An entity is not a collection of all possible values of some 'object',
> but it's the definition of the object itself.
>
> Simply put: if there's anything you want to store information about
> (any object that plays a role in your model of the world), it's an
> entity. So, a CalenderDate _can_ become an entity, as soon as you want
> to keep track of several of them, and assign them attributes.


Is there a more formal definition of an entity in the RDB domain? I
looked on wikipedia and it talked about entity in terms of classes,
but not RDBs. Is this a concept from relational theory itself, or from
diagramming relations?

lawpoop:

> Is there a more formal definition of an entity in the RDB domain? I
> looked on wikipedia and it talked about entity in terms of classes,
> but not RDBs. Is this a concept from relational theory itself, or from
> diagramming relations?

It has nothing to do with relational databases. An ER Diagram can be 
implemented in a hierarchical database (IMS, for instance) as well.
That's why you create an ER Model first, and then decide how to 
implement it.

http://en.wikipedia.org/wiki/Data_modeling (Paragraph "Entity 
relationship diagrams")
http://en.wikipedia.org/wiki/Entity-relationship_model


On the other hand, UML models are based on objects, not entities. Here, 
more complex relationships are modeled, like aggregation, inheritance 
and composition.

http://en.wikipedia.org/wiki/Unified_Modeling_Language#Modeling



For requirements analysis, I always use ER diagrams, because they are, 
in my opinion, quite understandable for business employees in a 
project. Object models are more complex and often too abstract to 
discuss in a general project team.


-- 
Erick

Erick T. Barkhuis wrote:
> William Gill:
>> Erick T. Barkhuis wrote:
> 
>>> [It's not the creation and sending of the notes what the database is 
>>> for, but tracking the process and finding notes that have never been 
>>> written]
>> Suppose Jim Jones makes a donation, says his address is 123 Main (his 
>> work address).  That information is entered in a field 
> 
> I thought you only entered the name, not the address.
An oversight, later corrected, in my example.

> 
>> ...and later used to address a thank you.  A week later he donates 
>> again as James Jones at 987 Elm (his home address). 
> 
> Sounds like a different person to me.
 From the standpoint of the application it is.

> 
>> That's where the second thank you goes. 
>> The organization can track both transactions (real world transaction 
>> not database transaction) for timely and complete processing.
> 
> Certainly.
> 
>> Mr. Jones can tell where the information to address the thank you came 
>> from.  But if he receives two solicitations, One addressed to Jim and 
>> one to James he knows he had been entered into a dreaded database 
>> somewhere.
> 
> Why? Didn't he present himself as two different persons?
Yes, and if he's like me he can tell what generated each piece of mail. 
  Now if he starts getting junk mail for both of these people, he knows 
two things.  Someone sold his address, and who that someone is.

He may not make the connection, and suspect that he's in a database when 
he receives the two thankyou's, but once anyone initiates any contact 
that is not a response to a donation, he will be sure.

>> Not a perfect example, but if procedurally the organization never 
>> actively initiates contact, but only acknowledges transactions donors 
>> initiated (with each donation) doesn't that eliminate the concern about 
>> duplicates, and at least mitigate spelling and typing mistakes?
> 
> It may. But then why do you track at all, keeping the names? Once you 
> know what thankyou notes were NOT sent, what is the organization going 
> to do with that knowledge?
Thats the point we track each donation, not each donor.

If a thankyou is NOT sent, there is still a pending record containing 
(hopefully) enough information to send one. It is kept in a field on a 
pending transaction (real world not db), and has no life/meaning to us 
outside of that one transaction.

Erick, I am probably throwing you off by trying to address other posters 
who are still thinking donor is, or should be an entity (thus their 
concern about duplicates, misspelling, etc.).  Probably bad Usenet form 
on my part.  I read the thread sequentially and sometimes give a 
cumulative response where it seems most appropriate, like a discussion.

> 
>> As for analyzing if and how often thankyou notes are missing for an 
>> individual, wouldn't a reasonably competent person get a clear enough 
>> picture by looking at the list of all unanswered donations over x days 
>> old?  That is, assuming the list isn't an overwhelming report.  In which 
>> case the problem is a management issue, not a database issue.
> 
> Probably true. But that doesn't have anything to do with whether or not 
> the information is stored in a database, right?.
> Remember, you were the one who wanted to use a database, anyway. In 
> that case, why not create a database in such a way that this 
> information is not to be compiled from a carton box full of paperwork 
> anymore?
Which is what I'm doing.  In most cases it would be more sophisticated 
(and probably will end up that way here too), then the subject of this 
thread would not apply.  However, when I proposed (to them) an 
electronic "carton box full of paperwork" to replace their actual one I 
was surprised to see I needed only one entity.

Remember It could have been a text file, but I would have had to code 
all the date comparison, sorting, filtering algorithms, and such from 
scratch.

It would have been a database either way.  After all a text file of 
individual records is a database, just not a very good one.

-- 
Bill

Erick T. Barkhuis wrote:
> Now that we have entered a what-if, we are down to trying to find 
> entities for our assumed reality. Any guess would be a good one, as 
> long as we don't use terms like 'enumerating', 'pointer' and 'lookup'.
Before I get into it, let me explain.  I was a successful manager in 
part because I was able to bring people from a variety of disciplines 
together and have them communicate.  That meant I didn't have to be an 
authority in every discipline, just reasonably familiar with the 
concepts.  It meant having to referee and insure exchanges don't get 
bogged down by minor syntactical errors.  Everyone had to loosen up, and 
object only when something was semantically incorrect enough to be 
wrong.  Also as a teacher I would be more bound to insuring I used 
syntactically exact terminology, but as a student some latitude is 
needed during concept formation.

To me defining a field ENUM(value1,value2,value3) is enumerating the 
field.  And isn't a foreign key field just a "pointer" to instance of 
another entity?

I think I get your point, don't confuse the mechanics with the concept. 
  I don't think I do, but will watch out.

> 
> So...assume your Holiday is an entity. We also have Donor and Donation.
> How would you suggest their relationships?
A Donor makes a Donation, and Donation has a Donor.  As far as I can see 
Holiday can give additional meaning to some dates in a Donation.  I'm 
not sure what the proper way express that, or even if that's what you mean.


-- 
Bill

William Gill:

> I think I get your point, don't confuse the mechanics with the concept. 
>   I don't think I do, but will watch out.

It's OK. I think we understand each other.

> > So...assume your Holiday is an entity. We also have Donor and Donation.
> > How would you suggest their relationships?

> A Donor makes a Donation, and Donation has a Donor.  As far as I can see 
> Holiday can give additional meaning to some dates in a Donation.  I'm 
> not sure what the proper way express that, or even if that's what you mean.

Errm...you're replying to a relatively 'older' post in this thread. I 
think we have passed this station already.

You're going to put the whole bunch of donations into a single table, 
and that's fine. Several here have had a gut feeling, that sooner or 
later, omitting a Donor table may fire backwards. But...that's just a 
gut feeling and a loose prediction.

I sincerely hope that you won't have to have Donor overviews in the 
future. But if you do, you will probably not be able to construct the 
needed Donor table afterwards without having a hard time 'reshuffling' 
your pile of donations.


-- 
Erick
[Really curious to know how things will be a year from now]

>>>> ... and if, as suggested elsewhere, the client's needs evolve adding
>>>> additional fields and tables isn't a major project.
>>> Simply adding a field or a table isn't a major project, but splitting
>>> out the design you posted into 'donors' and 'donations' will be a
>>> nightmare. I guess you'll be trying to do it by name, which will never
>>> be spelled consistently. I note that there's only one field for name
>>> -- is that last name first, or last name last? What about titles?
>> 
>> Even *having* a table for 'donors' as well as 'donations' can be a
>> problem.  You are about to enter a donation.  Which donor do you
>> associate with it?  You have the donor's name:  John Smith.  Your
>> user interface takes that, says that there are 23 close matches to
>> that name, including John M. Smith, and John Smythe, and offers you
>> a choice of those or adding a new donor.  If the database doesn't
>> prohibit it, you also have nine separate 'John Smith' entries.
>> However, your database cannot prohibit the existence of nine separate
>> people named 'John Smith' (no middle initial), three of whom have
>> the same address and phone number, and do not use suffixes.  On
>> what basis do you make a choice?
>> 
>> The organization's privacy policy says it will not track addresses,
>> phone numbers, birth dates, nor hand out donor numbers.  Most
>> donations arrive by mail so you don't get to ask questions.  And
>> if you have direct contact with the donor, you're not supposed to
>> ask nosy questions.  Accept the donation, thank the person, and
>> unless the donor asks questions, don't engage in further conversation.
>> The last thing the organization wants is a long line of donors
>> waiting impatiently behind one who is being forced to repeatedly
>> spell "1387 Suppercalifragilisticexpalidocious Avenue" because he
>> speaks in a thick accent.
>> 
>>> Trying to identify the 'same' name in that single field, spelled any
>>> way the data entry person felt like at that moment, is not
>>> automateable ( no script or query will be able to match "O'Donnell,
>>> Patrick" to "patrik odonnel" or "Dr. Amir Rashid" to "Rasheed Amer" ).
>>> You'll have to compare every record to every other record *manually*.
>>> Imagine how long this will take if there's more than a few dozen
>>> donations.
>> 
>> You're simply pushing the problem back on the data entry person.
>> 
>>> And you know what isn't very difficult? Just setting up
>>> 'donors'  ( with `last_name`, `first_name`, `title`, etc ) and
>>> 'donations' from the get-go.
>> 
>> Yes, that *IS* very difficult for the data entry person, unless
>> he simply creates a new donor entry for every donation.
>> 
>
>Most organizations will provide receipts.  

An organization can't provide year-end receipts if their privacy
policy says they will only keep *NAMES* beyond the time needed for
a transaction to complete.

Since the OP says that donor tracking isn't necessary, I'm going to
take him at his word.  That probably means that donations aren't
tax-deductible.

>Receipts are required for 
>larger donations for tax purposes, and any donations will be 
>investigated during an audit.
>
>Keeping the donors straight is a problem in any system.

So how do you do that, especially if most donations are *BY MAIL*
and you can't (by policy as well as practicality) ask for additional
details?  Or maybe they're in envelopes dropped in a collection
plate, by people who may not have brought a writing instrument with
them to fill out the form.  You can put blanks on a donation form
but that doesn't mean they get filled in (or even that the form is
used).  And with a privacy policy of keeping *NAMES* only beyond
the time necessary for the transaction to complete, you can't use
addresses, phone numbers, or credit/debit card numbers to disambiguate
duplicate donor names.

Do you think donor disamgiguation, something the organization says
is not important, is more important than a stated privacy policy?

On Oct 16, 10:25=A0am, Erick T. Barkhuis <erick.use-...@ardane.c-o-m>
wrote:
> lawpoop:
>
> > Is there a more formal definition of an entity in the RDB domain? I
> > looked on wikipedia and it talked about entity in terms of classes,
> > but not RDBs. Is this a concept from relational theory itself, or from
> > diagramming relations?
>
> It has nothing to do with relational databases. An ER Diagram can be
> implemented in a hierarchical database (IMS, for instance) as well.
> That's why you create an ER Model first, and then decide how to
> implement it.
>
> http://en.wikipedia.org/wiki/Data_modeling(Paragraph "Entity
> relationship diagrams")http://en.wikipedia.org/wiki/Entity-relationship_m=
odel

I'm familiar with the concept, but to my dismay, the wikipedia article
is no more formal than my current understanding. ( "Entities can be
thought of as nouns. Examples: a computer, an employee, a song, a
mathematical theorem. Entities are represented as rectangles." So an
entity is a rectangle? The article does mention a 1976 paper by Peter
Chen -- maybe a formal definition is there. )

I guess I was thinking that there was a formal logical or mathematical
definition that would help one say "In this model, the date is an
entity, and belongs in its own table, because it meets criteria
x,y,z". By what criteria is a 'thing', such as a date,  an attribute
in one system, while being an entity in another? Without a formal
definition, it seems to me that it would come down to design
preference, an almost wholly subjective reckoning. The data architect
as an artist, I suppose.

I know that relational databases have a formal algebraic definition,
and over in comp.databases.theory, people get caught up all the time
mixing up terminology such as relation, tuple, etc. I was thinking
there was a kind of formality one could use when applying this nice
algebra to your real-world data modeling needs, but now it seems that
it's not so. Is designing relational databases nothing more than an
intuitive ( in the most common-sense, logical sense of the word )
associating of human concept to relational algebra system, much like
class-based programming intuitively associates human concepts to
complex constructions of boolean algebra?

I'm not saying that it's a wholely subjective, like abstract art or
anything like that, but is the only criteria for validity or
correctness a consideration of the outcome?

Gordon Burditt wrote:
>>>>> ... and if, as suggested elsewhere, the client's needs evolve adding
>>>>> additional fields and tables isn't a major project.
>>>> Simply adding a field or a table isn't a major project, but splitting
>>>> out the design you posted into 'donors' and 'donations' will be a
>>>> nightmare. I guess you'll be trying to do it by name, which will never
>>>> be spelled consistently. I note that there's only one field for name
>>>> -- is that last name first, or last name last? What about titles?
>>> Even *having* a table for 'donors' as well as 'donations' can be a
>>> problem.  You are about to enter a donation.  Which donor do you
>>> associate with it?  You have the donor's name:  John Smith.  Your
>>> user interface takes that, says that there are 23 close matches to
>>> that name, including John M. Smith, and John Smythe, and offers you
>>> a choice of those or adding a new donor.  If the database doesn't
>>> prohibit it, you also have nine separate 'John Smith' entries.
>>> However, your database cannot prohibit the existence of nine separate
>>> people named 'John Smith' (no middle initial), three of whom have
>>> the same address and phone number, and do not use suffixes.  On
>>> what basis do you make a choice?
>>>
>>> The organization's privacy policy says it will not track addresses,
>>> phone numbers, birth dates, nor hand out donor numbers.  Most
>>> donations arrive by mail so you don't get to ask questions.  And
>>> if you have direct contact with the donor, you're not supposed to
>>> ask nosy questions.  Accept the donation, thank the person, and
>>> unless the donor asks questions, don't engage in further conversation.
>>> The last thing the organization wants is a long line of donors
>>> waiting impatiently behind one who is being forced to repeatedly
>>> spell "1387 Suppercalifragilisticexpalidocious Avenue" because he
>>> speaks in a thick accent.
>>>
>>>> Trying to identify the 'same' name in that single field, spelled any
>>>> way the data entry person felt like at that moment, is not
>>>> automateable ( no script or query will be able to match "O'Donnell,
>>>> Patrick" to "patrik odonnel" or "Dr. Amir Rashid" to "Rasheed Amer" ).
>>>> You'll have to compare every record to every other record *manually*.
>>>> Imagine how long this will take if there's more than a few dozen
>>>> donations.
>>> You're simply pushing the problem back on the data entry person.
>>>
>>>> And you know what isn't very difficult? Just setting up
>>>> 'donors'  ( with `last_name`, `first_name`, `title`, etc ) and
>>>> 'donations' from the get-go.
>>> Yes, that *IS* very difficult for the data entry person, unless
>>> he simply creates a new donor entry for every donation.
>>>
>> Most organizations will provide receipts.  
> 
> An organization can't provide year-end receipts if their privacy
> policy says they will only keep *NAMES* beyond the time needed for
> a transaction to complete.
> 

Receipts do not have to be issued at year-end.  They can be issued when 
the donation is made.

> Since the OP says that donor tracking isn't necessary, I'm going to
> take him at his word.  That probably means that donations aren't
> tax-deductible.
>

That would be an invalid assumption.  Just because they don't currently 
track donors does not mean the donations are not tax deductible.

>> Receipts are required for 
>> larger donations for tax purposes, and any donations will be 
>> investigated during an audit.
>>
>> Keeping the donors straight is a problem in any system.
> 
> So how do you do that, especially if most donations are *BY MAIL*
> and you can't (by policy as well as practicality) ask for additional
> details?  Or maybe they're in envelopes dropped in a collection
> plate, by people who may not have brought a writing instrument with
> them to fill out the form.  You can put blanks on a donation form
> but that doesn't mean they get filled in (or even that the form is
> used).  And with a privacy policy of keeping *NAMES* only beyond
> the time necessary for the transaction to complete, you can't use
> addresses, phone numbers, or credit/debit card numbers to disambiguate
> duplicate donor names.
>

Many ways.  For instance, the addresses on the checks.  If paying by 
credit card, the account holder's address would be another.

Of course, if they don't provide the information, they don't get a 
receipt - but they are the ones who lose the tax deduction.

> Do you think donor disamgiguation, something the organization says
> is not important, is more important than a stated privacy policy?
> 

I think keeping track of donations is important for any organization, as 
in the case of a tax audit (either of the donor or the organization 
itself).  Additionally, many states have requirements as to what records 
must be kept.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

>> So how do you do that, especially if most donations are *BY MAIL*
>> and you can't (by policy as well as practicality) ask for additional
>> details?  Or maybe they're in envelopes dropped in a collection
>> plate, by people who may not have brought a writing instrument with
>> them to fill out the form.  You can put blanks on a donation form
>> but that doesn't mean they get filled in (or even that the form is
>> used).  And with a privacy policy of keeping *NAMES* only beyond
>> the time necessary for the transaction to complete, you can't use
>> addresses, phone numbers, or credit/debit card numbers to disambiguate
>> duplicate donor names.
>>
>
>Many ways.  For instance, the addresses on the checks.  If paying by 
>credit card, the account holder's address would be another.

The privacy policy says you can't hold on to addresses for longer than
it takes to process the transaction, so unless you get two donations
within a week, you can't use that information to figure out which of
several same-named donors it came from.  

Those addresses could be used for immediate (not year-end) thank-you
notes / receipts.

>Of course, if they don't provide the information, they don't get a 
>receipt - but they are the ones who lose the tax deduction.

Gordon Burditt:
> >> So how do you do that, 
> >
> >Many ways.  For instance, the addresses on the checks.  If paying by 
> >credit card, the account holder's address would be another.
> 
> The privacy policy says ...

Gordon, you keep riding on that privacy police. Are you sure that:
a) Bill's organization has such policy, and
b) if so, that's what that policy says?


-- 
Erick

lawpoop:
> On Oct 16, 10:25�am, Erick T. Barkhuis <erick.use-...@ardane.c-o-m>
> wrote:
> > lawpoop:
> >
> > > Is there a more formal definition of an entity in the RDB domain?

> > http://en.wikipedia.org/wiki/Data_modeling(Paragraph "Entity
> > relationship diagrams")http://en.wikipedia.org/wiki/Entity-relationship_model
> 
> I'm familiar with the concept, 

Oh, I'm sorry. I must have misunderstood the question. Upon rereading, 
you were quite clear.

> but to my dismay, the wikipedia article
> is no more formal than my current understanding. ( "Entities can be
> thought of as nouns. Examples: a computer, an employee, a song, a
> mathematical theorem. Entities are represented as rectangles." So an
> entity is a rectangle? The article does mention a 1976 paper by Peter
> Chen -- maybe a formal definition is there. )...
> 
> I'm not saying that it's a wholely subjective, like abstract art or
> anything like that, but is the only criteria for validity or
> correctness a consideration of the outcome?

It's all VooDoo, lawpoop! :-)
No, really, I haven't ever seen a formal definition of when something 
has to be named an entity. Neither have I seen a theoretical approach 
on how to formalize or even automate the process of defining a Data 
Model.

The Peter Chen article is here:
http://csc.lsu.edu/news/erd.pdf
In paragraph 2.2, he explains what entities and "entity sets" are. In 
fact, the wording in the Wikipedia is practically the same as Peter 
Chen's wording. Sounds like he, too, wants the "Human Mind" to dictate 
what is, and what is not, an entity in any given situation.

Could a data analist, while constructing a Data Model, perhaps best be 
compared with an architect, whose work can't be automated, either?


-- 
Erick

Gordon Burditt wrote:
>>> So how do you do that, especially if most donations are *BY MAIL*
>>> and you can't (by policy as well as practicality) ask for additional
>>> details?  Or maybe they're in envelopes dropped in a collection
>>> plate, by people who may not have brought a writing instrument with
>>> them to fill out the form.  You can put blanks on a donation form
>>> but that doesn't mean they get filled in (or even that the form is
>>> used).  And with a privacy policy of keeping *NAMES* only beyond
>>> the time necessary for the transaction to complete, you can't use
>>> addresses, phone numbers, or credit/debit card numbers to disambiguate
>>> duplicate donor names.
>>>
>> Many ways.  For instance, the addresses on the checks.  If paying by 
>> credit card, the account holder's address would be another.
> 
> The privacy policy says you can't hold on to addresses for longer than
> it takes to process the transaction, so unless you get two donations
> within a week, you can't use that information to figure out which of
> several same-named donors it came from.  
> 
> Those addresses could be used for immediate (not year-end) thank-you
> notes / receipts.
> 

Who's privacy policy?  The original op indicated they were using pieces 
of paper for information.  Doesn't sound like they had anything to even 
have a privacy policy about.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

>> >> So how do you do that, 
>> >
>> >Many ways.  For instance, the addresses on the checks.  If paying by 
>> >credit card, the account holder's address would be another.
>> 
>> The privacy policy says ...
>
>Gordon, you keep riding on that privacy police. Are you sure that:

*POLICE*?  I didn't say anything about *police*.  Policy, yes, police, no.

>a) Bill's organization has such policy, and
>b) if so, that's what that policy says?

I'm not talking specifically about the original poster's problem.
I don't know *why* Bill said that donor tracking is unnecessary,
but he did say that.  He did not say it was because of a specific
policy.  I'm asking about a hypothetical situation that might or
might not match Bill's.  The hypothetical situation is that the
reason why donor tracking is unwanted is that a promise was made
to donors that no personal information other than their name would
be kept longer than the time needed to complete the transaction.  
That means any thank you notes/receipts have to be sent quickly
and the address/email address forgotten after that.

I do know of certain organizations that might *not* want to do donor
tracking by policy.  The Ku Klux Klan, various paramilitary groups,
and religions thought of by the government as "cults" might not
want their supporters tracked by governments or news reporters.
The "legalize drugs" political movement does not want a donor's
list used as a DEA raid target list.  Battered women's shelters
don't want their former grateful clients (some of them might be
married to police officers or government officials) tracked down
by records.

No, I'm not saying that Bill's organization has anything to do with
any of the above.

On USENET, and hopefully not with his paying clients, Jerry seems
intent on substituting what he thinks the requirements ought to be
for what the stated requirements are (if he reads the stated
requirements at all).  Donor tracking requires ongoing effort and
may involve asking unanswerable questions of the clerk opening the
mail and entering donations, like *which* John Smith?  It also 
requires entering more information to allow answering questions
like that, such as addresses, email addresses, phone numbers, etc.,
and keeping that up to date.  This effort the organization might
not want to make, for, in their opinion, no useful result.

Gordon Burditt: 
> >> >> So how do you do that, 
> >> >
> >> >Many ways.  For instance, the addresses on the checks.  If paying by 
> >> >credit card, the account holder's address would be another.
> >> 
> >> The privacy policy says ...
> >
> >Gordon, you keep riding on that privacy police. Are you sure that:
> 
> *POLICE*?  I didn't say anything about *police*.  Policy, yes, police, no.

Sigh.
Yes, you're right, Gordon. You're right. I made an obvious typo. I 
spelled the word correctly after that.

You've got to agree: for someone, whose native tongue is not English, I 
still manage to put most characters in the proper place, most of the 
time.

> 
> >a) Bill's organization has such policy, and
> >b) if so, that's what that policy says?
> 
> I'm not talking specifically about the original poster's problem.

It appeared so, though.

> I don't know *why* Bill said that donor tracking is unnecessary,
> but he did say that. 

So, did you ask?

> The hypothetical situation is that the
> reason why donor tracking is unwanted is that a promise was made
> to donors that no personal information other than their name would
> be kept longer than the time needed to complete the transaction.  
> That means any thank you notes/receipts have to be sent quickly
> and the address/email address forgotten after that.

But that's not the case, since they want to track what thankyou notes 
had been forgotten.

> 
> I do know of certain organizations that might *not* want to do donor
> tracking by policy.  The Ku Klux Klan, various paramilitary groups,
> and religions thought of by the government as "cults" might not
> want their supporters tracked by governments or news reporters.

They are not likely to be a donor for organziations that send thankyou 
notes, anyway.

> The "legalize drugs" political movement does not want a donor's
> list used as a DEA raid target list.  Battered women's shelters
> don't want their former grateful clients (some of them might be
> married to police officers or government officials) tracked down
> by records.

They won't even give their identity, when sending a donation.


-- 
Erick

Gordon Burditt wrote:
>>>>> So how do you do that, 
>>>> Many ways.  For instance, the addresses on the checks.  If paying by 
>>>> credit card, the account holder's address would be another.
>>> The privacy policy says ...
>> Gordon, you keep riding on that privacy police. Are you sure that:
> 
> *POLICE*?  I didn't say anything about *police*.  Policy, yes, police, no.
> 
>> a) Bill's organization has such policy, and
>> b) if so, that's what that policy says?
> 
> I'm not talking specifically about the original poster's problem.
> I don't know *why* Bill said that donor tracking is unnecessary,
> but he did say that.  He did not say it was because of a specific
> policy.  I'm asking about a hypothetical situation that might or
> might not match Bill's.  The hypothetical situation is that the
> reason why donor tracking is unwanted is that a promise was made
> to donors that no personal information other than their name would
> be kept longer than the time needed to complete the transaction.  
> That means any thank you notes/receipts have to be sent quickly
> and the address/email address forgotten after that.
> 
> I do know of certain organizations that might *not* want to do donor
> tracking by policy.  The Ku Klux Klan, various paramilitary groups,
> and religions thought of by the government as "cults" might not
> want their supporters tracked by governments or news reporters.
> The "legalize drugs" political movement does not want a donor's
> list used as a DEA raid target list.  Battered women's shelters
> don't want their former grateful clients (some of them might be
> married to police officers or government officials) tracked down
> by records.
> 
> No, I'm not saying that Bill's organization has anything to do with
> any of the above.
> 
> On USENET, and hopefully not with his paying clients, Jerry seems
> intent on substituting what he thinks the requirements ought to be
> for what the stated requirements are (if he reads the stated
> requirements at all).  Donor tracking requires ongoing effort and
> may involve asking unanswerable questions of the clerk opening the
> mail and entering donations, like *which* John Smith?  It also 
> requires entering more information to allow answering questions
> like that, such as addresses, email addresses, phone numbers, etc.,
> and keeping that up to date.  This effort the organization might
> not want to make, for, in their opinion, no useful result.
> 
> 

No, I'm not substituting what I think the requirements ought to be.  But 
after over 40 years of programming, the first thing I know is that 
requirements change.  The next thing I can do is make some pretty 
educated guesses as to where those changes will lead.  And when doing 
that, I look at how I can accommodate those changes with no increase in 
cost to the client now.

Once they have a database, wanting to track by donor would be a common 
addition.  Splitting the database across two tables instead of one isn't 
going to cost anything extra now - but would cost significantly more 
later.

This is one of the reasons I get recurring business.  I think ahead.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Mon, 19 Oct 2009 06:55:55 -0400, Jerry Stuckle wrote:
> No, I'm not substituting what I think the requirements ought to be.  But 
> after over 40 years of programming, the first thing I know is that 
> requirements change.  The next thing I can do is make some pretty 
> educated guesses as to where those changes will lead.  And when doing 
> that, I look at how I can accommodate those changes with no increase in 
> cost to the client now.

Totally agree. Substituting "cost to the client" with "work on my part",
since I'm unfortunately not in a position where those go hand-in-hand...

> Once they have a database, wanting to track by donor would be a common 
> addition.  Splitting the database across two tables instead of one isn't 
> going to cost anything extra now - but would cost significantly more 
> later.

And, in the world of the doner, the difference between "we don't retain
the address" and "we don't contact you again unless you tell us it's
okay" is both moot and confusing. 

-- 
2. My ventilation ducts will be too small to crawl through.
                --Peter Anspach's list of things to do as an Evil Overlord

Erick T. Barkhuis wrote:
> Sigh.
> Yes, you're right, Gordon. You're right. I made an obvious typo. I 
> spelled the word correctly after that.
Erick,
Unfortunately many of us are getting tired of all kinds of "societal 
know it all's" dictating how things "should" be done.  The common 
colloquialism is to refer to the insinuators as "police", PC Police, or 
Etiquette Police, and so on.

I'm sure Gordon was reacting to the thought of being lumped in with the 
social police state.

As you can see, the resulting hypersensitivity is why people react so 
negatively when they think their name and address may end up in a list 
or database somewhere, and why conversely an organization might 
proactively shun such tracking mechanisms.  They feel that thee 
possibility of scaring away potential donors outweighs maintaining a 
donor list. Besides the logistics and current lack of sophistication of 
the collection mechanisms is incompatible with the requisite data 
collection.  In this case think of the name and address information 
being placed on a mailing label that is kept by the organization until 
it is placed on the acknowledgment envelope.  It is maintained by the 
organization only as long as needed then returned it to the owner. 
That's why minor spelling errors, differentiating between Jim and James, 
or one Smith from another is irrelevant.


-- 
Bill

Gordon Burditt wrote:
> On USENET, and hopefully not with his paying clients, Jerry seems
> intent on substituting what he thinks the requirements ought to be
> for what the stated requirements are (if he reads the stated
> requirements at all).  Donor tracking requires ongoing effort and
> may involve asking unanswerable questions of the clerk opening the
> mail and entering donations, like *which* John Smith?  It also 
> requires entering more information to allow answering questions
> like that, such as addresses, email addresses, phone numbers, etc.,
> and keeping that up to date.  This effort the organization might
> not want to make, for, in their opinion, no useful result.
Jerry and others me asked the same questions I had already asked myself. 
  I appreciated his question, and he accepted that it was a considered, 
deliberate decision.

It isn't possible, or desirable to publish here the entire user spec or 
all the situational details involved, so some assumptions need to be 
made.  When that causes someone to wonder if something has been 
overlooked, it's appropriate to ask.  It is even permissible to 
editorialize a little.  I don't know how Jerry is in client meetings, 
nor do I care.  I have been in enough meetings where some participants 
tried to dictate the needs of others, but I don't equate a newsgroup 
with those situations. There are lots of things I will say or infer 
here, that I would bite my tongue elsewhere.  That doesn't mean I 
wouldn't ask or point out possible oversights and omissions, or not 
expect the same from others, but when it gets to the point of "asked and 
answered" it's time to move on.


-- 
Bill

William Gill: 
> ....That doesn't mean I 
> wouldn't ask or point out possible oversights and omissions, or not 
> expect the same from others, but when it gets to the point of "asked and 
> answered" it's time to move on.

What? 
After all has been said and done, it's time for senseless bickering! 
Are you saying that such fun isn't allowed anymore?
:-)

-- 
SCNR
Erick

On Oct 17, 3:34=A0am, Erick T. Barkhuis <erick.use-...@ardane.c-o-m>
wrote:

> It's all VooDoo, lawpoop! :-)
> No, really, I haven't ever seen a formal definition of when something
> has to be named an entity. Neither have I seen a theoretical approach
> on how to formalize or even automate the process of defining a Data
> Model.

So then, the practical criteria for database design is, "If we do it
this way, then a, b, and c will happen. If we do it the other way, x,
y, and z will happen. I submit that a, b, and c are much preferable to
x, y, and z." In other words, one can't divine from the "reality of
the situation" or the situation by itself; one need define output
goals and available inputs, and design the database according to those
resources and needs. You can't just say, "Well, you have donors, you
probably need a donors table" -- the only way to make a good argument
for a donors table is "If you ever want to have feature X ( a year-end
statement ), you'll need a donors table".

Am I thinking about this correctly? So it's sort of an engineering
model ( "Here's the possbilities, and their tradeoffs" ) rather than a
mathematical model ( "Given this set of facts, this is right, and this
is wrong.")

>
> The Peter Chen article is here:http://csc.lsu.edu/news/erd.pdf
> In paragraph 2.2, he explains what entities and "entity sets" are. In
> fact, the wording in the Wikipedia is practically the same as Peter
> Chen's wording. Sounds like he, too, wants the "Human Mind" to dictate
> what is, and what is not, an entity in any given situation.

Well, that makes sense. Of course, a computer can't figure this out on
its own. I was thinking that there was at the start some intuitive
human-made decisions, but then at some point, one could say "If you
have this, this, and this, then you need to have this, because
otherwise {insert mathe-logical mumbo-jumbo here}". That there could
be derived implications of the model people were creating.

I was thinking about it over the weekend, and it occurs to me that an
entity has an independent existence within the model, not depending on
anything. For instance, in the donations model, "date" depends
entirely on there being a donation -- without a donation, there's no
date -- so therefore, date is not an entity. However, donations depend
solely on having been donated -- they have an independent existence,
or they depend solely on themselves.

>
> Could a data analist, while constructing a Data Model, perhaps best be
> compared with an architect, whose work can't be automated, either?

This came up on a discussion on slashdot a while ago, and I think
architect is the best metaphor. It's not math, and it's not art. You
are constrained by the math, but that nonetheless leaves open a huge
domain of possibility in which to make a creative solution.

lawpoop: 
> On Oct 17, 3:34�am, Erick T. Barkhuis <erick.use-...@ardane.c-o-m>
> wrote:
> 
> > It's all VooDoo, lawpoop! :-)
> > No, really, I haven't ever seen a formal definition of when something
> > has to be named an entity. Neither have I seen a theoretical approach
> > on how to formalize or even automate the process of defining a Data
> > Model.
> 
> So then, the practical criteria for database design is, "If we do it
> this way, then a, b, and c will happen. If we do it the other way, x,
> y, and z will happen. I submit that a, b, and c are much preferable to
> x, y, and z." In other words, one can't divine from the "reality of
> the situation" or the situation by itself; one need define output
> goals and available inputs, and design the database according to those
> resources and needs.^

Exactly right.
> 
> Am I thinking about this correctly? So it's sort of an engineering
> model ( "Here's the possbilities, and their tradeoffs" ) rather than a
> mathematical model ( "Given this set of facts, this is right, and this
> is wrong.")

Yes, that's it. 
I see this more like an architecture, where pros and cons are weighed 
on a constant basis.


> I was thinking about it over the weekend, and it occurs to me that an
> entity has an independent existence within the model, not depending on
> anything. For instance, in the donations model, "date" depends
> entirely on there being a donation -- without a donation, there's no
> date -- so therefore, date is not an entity. However, donations depend
> solely on having been donated -- they have an independent existence,
> or they depend solely on themselves.

Not quite, I believe. 
For instance: customers, orders and bills. Without customers, there are 
no orders. Without orders, no bills. Yet, every web shop will have 
entities Customer and Order (where Order is a relationship entity 
between Customer and Artikel). Bill may, or may not be an entity. If an 
Order can lead to multiple Bills, or a Bill is set up for multiple 
Orders, then yes, a Bill is certainly an entity. But if one Order leads 
to exactly one Bill all the time, Bill and Order may be exactly the 
same entity, with only a different status over time.

OK, it's VooDoo. :-)

-- 
Erick

William Gill wrote:
> Gordon Burditt wrote:
>> On USENET, and hopefully not with his paying clients, Jerry seems
>> intent on substituting what he thinks the requirements ought to be
>> for what the stated requirements are (if he reads the stated
>> requirements at all).  Donor tracking requires ongoing effort and
>> may involve asking unanswerable questions of the clerk opening the
>> mail and entering donations, like *which* John Smith?  It also 
>> requires entering more information to allow answering questions
>> like that, such as addresses, email addresses, phone numbers, etc.,
>> and keeping that up to date.  This effort the organization might
>> not want to make, for, in their opinion, no useful result.
> Jerry and others me asked the same questions I had already asked myself. 
>  I appreciated his question, and he accepted that it was a considered, 
> deliberate decision.
> 
> It isn't possible, or desirable to publish here the entire user spec or 
> all the situational details involved, so some assumptions need to be 
> made.  When that causes someone to wonder if something has been 
> overlooked, it's appropriate to ask.  It is even permissible to 
> editorialize a little.  I don't know how Jerry is in client meetings, 
> nor do I care.  I have been in enough meetings where some participants 
> tried to dictate the needs of others, but I don't equate a newsgroup 
> with those situations. There are lots of things I will say or infer 
> here, that I would bite my tongue elsewhere.  That doesn't mean I 
> wouldn't ask or point out possible oversights and omissions, or not 
> expect the same from others, but when it gets to the point of "asked and 
> answered" it's time to move on.
> 
> 

Yes, I agree you shouldn't try to publish the entire spec here.  As for 
how I am in client meetings - I don't dictate.  I ask questions.  Some 
of them are leading questions, I will admit.  However, they are aimed at 
gathering as much information as possible, and ensuring I understand the 
nature of the client's needs (which he/she often don't understand 
themselves).

As for your specific instance, I still think I would place donors in one 
table and donations in another (the client really doesn't care whether 
it is one or two tables).  However, I am having to say that without the 
benefit of the full spec, any discussions with the customer or even 
knowing the customer.  So I would have to say if you think one table is 
the right thing to do, then by all means, do it.  There isn't anything 
wrong with a database which contains only one table.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Erick T. Barkhuis wrote:

> What? 
> After all has been said and done, it's time for senseless bickering! 
> Are you saying that such fun isn't allowed anymore?
> :-)
Senseless bickering on Usenet?  How ludicrous!  :-)


-- 
Bill