Re: Separate PK in Jxn Tbl?

#1

Tony Toews [MVP] wrote:

Quote:

JOG <jog (AT) cs (DOT) nott.ac.uk> wrote:

I just think you're all damn brave for using Access in the first
place.

Why? It works and works well. If you have too many users or remote users bolt on a
SQL Server backend. Now you can have thousands of users.

All that cross-posting only encourages talk at cross-purposes. Every
full-time Access developer I ever met had difficulty not mentioning the
name and the word corruption in the same sentence. None of the customer
apps had a problem with that since they were small enough to resort to
paper when there was a problem. But when a file-based engine doesn't
log, the important question is hardly one of too many users. It was
okay for my family tree and personal tax accounts since by my definition
since I preferred to think of those as fuzzy apps. Funny, once I
started to say no to packaged goods like Windows, all my Access problems
went away. I suppose it will be amusing to watch Google repeat the
errors of history when they come up with "googleaccess" (I'm sure they
will).

#2

Tony Toews [MVP] wrote:

Quote:

JOG <jog (AT) cs (DOT) nott.ac.uk> wrote:

I just think you're all damn brave for using Access in the first
place.

Why? It works and works well. If you have too many users or remote users bolt on a
SQL Server backend. Now you can have thousands of users.

All that cross-posting only encourages talk at cross-purposes. Every
full-time Access developer I ever met had difficulty not mentioning the
name and the word corruption in the same sentence. None of the customer
apps had a problem with that since they were small enough to resort to
paper when there was a problem. But when a file-based engine doesn't
log, the important question is hardly one of too many users. It was
okay for my family tree and personal tax accounts since by my definition
since I preferred to think of those as fuzzy apps. Funny, once I
started to say no to packaged goods like Windows, all my Access problems
went away. I suppose it will be amusing to watch Google repeat the
errors of history when they come up with "googleaccess" (I'm sure they
will).

#3

Tony Toews [MVP] wrote:

Quote:

JOG <jog (AT) cs (DOT) nott.ac.uk> wrote:

I just think you're all damn brave for using Access in the first
place.

Why? It works and works well. If you have too many users or remote users bolt on a
SQL Server backend. Now you can have thousands of users.

All that cross-posting only encourages talk at cross-purposes. Every
full-time Access developer I ever met had difficulty not mentioning the
name and the word corruption in the same sentence. None of the customer
apps had a problem with that since they were small enough to resort to
paper when there was a problem. But when a file-based engine doesn't
log, the important question is hardly one of too many users. It was
okay for my family tree and personal tax accounts since by my definition
since I preferred to think of those as fuzzy apps. Funny, once I
started to say no to packaged goods like Windows, all my Access problems
went away. I suppose it will be amusing to watch Google repeat the
errors of history when they come up with "googleaccess" (I'm sure they
will).

#4

Tony Toews [MVP] wrote:

Quote:

JOG <jog (AT) cs (DOT) nott.ac.uk> wrote:

I just think you're all damn brave for using Access in the first
place.

Why? It works and works well. If you have too many users or remote users bolt on a
SQL Server backend. Now you can have thousands of users.

All that cross-posting only encourages talk at cross-purposes. Every
full-time Access developer I ever met had difficulty not mentioning the
name and the word corruption in the same sentence. None of the customer
apps had a problem with that since they were small enough to resort to
paper when there was a problem. But when a file-based engine doesn't
log, the important question is hardly one of too many users. It was
okay for my family tree and personal tax accounts since by my definition
since I preferred to think of those as fuzzy apps. Funny, once I
started to say no to packaged goods like Windows, all my Access problems
went away. I suppose it will be amusing to watch Google repeat the
errors of history when they come up with "googleaccess" (I'm sure they
will).

#5

Tony Toews [MVP] wrote:

Quote:

JOG <jog (AT) cs (DOT) nott.ac.uk> wrote:

I just think you're all damn brave for using Access in the first
place.

Why? It works and works well. If you have too many users or remote users bolt on a
SQL Server backend. Now you can have thousands of users.

All that cross-posting only encourages talk at cross-purposes. Every
full-time Access developer I ever met had difficulty not mentioning the
name and the word corruption in the same sentence. None of the customer
apps had a problem with that since they were small enough to resort to
paper when there was a problem. But when a file-based engine doesn't
log, the important question is hardly one of too many users. It was
okay for my family tree and personal tax accounts since by my definition
since I preferred to think of those as fuzzy apps. Funny, once I
started to say no to packaged goods like Windows, all my Access problems
went away. I suppose it will be amusing to watch Google repeat the
errors of history when they come up with "googleaccess" (I'm sure they
will).

#6

Tony Toews [MVP] wrote:

Quote:

JOG <jog (AT) cs (DOT) nott.ac.uk> wrote:

I just think you're all damn brave for using Access in the first
place.

Why? It works and works well. If you have too many users or remote users bolt on a
SQL Server backend. Now you can have thousands of users.

All that cross-posting only encourages talk at cross-purposes. Every
full-time Access developer I ever met had difficulty not mentioning the
name and the word corruption in the same sentence. None of the customer
apps had a problem with that since they were small enough to resort to
paper when there was a problem. But when a file-based engine doesn't
log, the important question is hardly one of too many users. It was
okay for my family tree and personal tax accounts since by my definition
since I preferred to think of those as fuzzy apps. Funny, once I
started to say no to packaged goods like Windows, all my Access problems
went away. I suppose it will be amusing to watch Google repeat the
errors of history when they come up with "googleaccess" (I'm sure they
will).

#7

Tony Toews [MVP] wrote:

Quote:

JOG <jog (AT) cs (DOT) nott.ac.uk> wrote:

I just think you're all damn brave for using Access in the first
place.

Why? It works and works well. If you have too many users or remote users bolt on a
SQL Server backend. Now you can have thousands of users.

All that cross-posting only encourages talk at cross-purposes. Every
full-time Access developer I ever met had difficulty not mentioning the
name and the word corruption in the same sentence. None of the customer
apps had a problem with that since they were small enough to resort to
paper when there was a problem. But when a file-based engine doesn't
log, the important question is hardly one of too many users. It was
okay for my family tree and personal tax accounts since by my definition
since I preferred to think of those as fuzzy apps. Funny, once I
started to say no to packaged goods like Windows, all my Access problems
went away. I suppose it will be amusing to watch Google repeat the
errors of history when they come up with "googleaccess" (I'm sure they
will).

#8

On Jan 27, 12:39 pm, "David W. Fenton" <XXXuse... (AT) dfenton (DOT) com.invalid>
wrote:

Quote:

JOG <j... (AT) cs (DOT) nott.ac.uk> wrote innews:5afa9a80-f1c5-4ede-8095-1f4c0164417a (AT) s12g2000prg (DOT) googlegroups.co
m:

No probs, although off the top of my head its gonna be a bit
contrived. With an artificial key:

Marriages {id, husband, wife, date}
Kids_from_Marriage {from_id, name, birth}

A query that asks "fetch me all the children whose mother is x"
obviously requires an equijoin, matching Marriages.id and
Kids.from_id. However with the original natural keys:

Marriages {id, husband, wife, date}
Kids_from_Marriage {mother, father, name, birth}

The same query is a simple select. That certainly seems a lot less
complicated to me

[...]
And it all leaves aside the question of how you know that
husband/wife/date is always going to be unique. I think that on any
given day in the US, there are plenty of marriages in which those
three values will be identical. You could add place. But then, in
large cities, that might not be enough. So use Postal Code in place
of place, and that might do the trick, although in large cities that
might not do it, either.

Huh? You think there are some pairs of people who are getting married
more than once on the same day? I mean, even in Hollywood the
crazy "marriages" usually last at least a few *days*. I'm not sure
it's
even technically possible to get married, divorced, and remarried to
the same person in one day. (Although I am no expert in the
*bureaucratic* details of marriage.)

Marshall

#9

On Jan 27, 12:39 pm, "David W. Fenton" <XXXuse... (AT) dfenton (DOT) com.invalid>
wrote:

Quote:

JOG <j... (AT) cs (DOT) nott.ac.uk> wrote innews:5afa9a80-f1c5-4ede-8095-1f4c0164417a (AT) s12g2000prg (DOT) googlegroups.co
m:

No probs, although off the top of my head its gonna be a bit
contrived. With an artificial key:

Marriages {id, husband, wife, date}
Kids_from_Marriage {from_id, name, birth}

A query that asks "fetch me all the children whose mother is x"
obviously requires an equijoin, matching Marriages.id and
Kids.from_id. However with the original natural keys:

Marriages {id, husband, wife, date}
Kids_from_Marriage {mother, father, name, birth}

The same query is a simple select. That certainly seems a lot less
complicated to me

[...]
And it all leaves aside the question of how you know that
husband/wife/date is always going to be unique. I think that on any
given day in the US, there are plenty of marriages in which those
three values will be identical. You could add place. But then, in
large cities, that might not be enough. So use Postal Code in place
of place, and that might do the trick, although in large cities that
might not do it, either.

Huh? You think there are some pairs of people who are getting married
more than once on the same day? I mean, even in Hollywood the
crazy "marriages" usually last at least a few *days*. I'm not sure
it's
even technically possible to get married, divorced, and remarried to
the same person in one day. (Although I am no expert in the
*bureaucratic* details of marriage.)

Marshall

#10

On Jan 27, 12:39 pm, "David W. Fenton" <XXXuse... (AT) dfenton (DOT) com.invalid>
wrote:

Quote:

JOG <j... (AT) cs (DOT) nott.ac.uk> wrote innews:5afa9a80-f1c5-4ede-8095-1f4c0164417a (AT) s12g2000prg (DOT) googlegroups.co
m:

No probs, although off the top of my head its gonna be a bit
contrived. With an artificial key:

Marriages {id, husband, wife, date}
Kids_from_Marriage {from_id, name, birth}

A query that asks "fetch me all the children whose mother is x"
obviously requires an equijoin, matching Marriages.id and
Kids.from_id. However with the original natural keys:

Marriages {id, husband, wife, date}
Kids_from_Marriage {mother, father, name, birth}

The same query is a simple select. That certainly seems a lot less
complicated to me

[...]
And it all leaves aside the question of how you know that
husband/wife/date is always going to be unique. I think that on any
given day in the US, there are plenty of marriages in which those
three values will be identical. You could add place. But then, in
large cities, that might not be enough. So use Postal Code in place
of place, and that might do the trick, although in large cities that
might not do it, either.

Huh? You think there are some pairs of people who are getting married
more than once on the same day? I mean, even in Hollywood the
crazy "marriages" usually last at least a few *days*. I'm not sure
it's
even technically possible to get married, divorced, and remarried to
the same person in one day. (Although I am no expert in the
*bureaucratic* details of marriage.)

Marshall