[AccessD] Confused by One to Many versus One to One

Oh, I just found another one-to-one relationship deal - the US Census 
summary file data.  Here's the trick.  Each state has a master table, 
then there are 47 segments of data, divided up into separate tables.  
The LogRecordId is the same in the master table and in each of the 
segment tables,  All this divvying up is because the data load is huge 
and won't all fit in a 2Gb database, so they use a sort of "import the 
parts you want from all the comma delimited text files" technique .  I 
found that tedious, so I'm using linked tables to get around the 2Gb 
limits.
[I'm working on the township's parks & recreation 5-year master plan - 
that's why I'm deep in the Census data.]
TNF

Tina Norris Fields
tinanfields-at-torchlake-dot-com
231-322-2787

On 1/3/2015 10:27 PM, John R Bartow wrote:
> I'd guess that was the reason the aforementioned government agency DB schema
> was set up the way it was.
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Tina Norris
> Fields
> Sent: Saturday, January 03, 2015 3:17 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Confused by One to Many versus One to One
>
> In fact, the only way I've ever seen a 1-to-1 relationship used was to make
> a table of confidential employee data that shouldn't appear in the general
> employee info table.  I read an example once, suggested for a library
> database, but I honestly didn't understand it at all.
> TNF
>
> Tina Norris Fields
> tinanfields-at-torchlake-dot-com
> 231-322-2787
>
> On 11/30/2014 2:57 PM, Jim Dettman wrote:
>> Bill,
>>
>>    It's pretty rare to have a 1 to 1.  Pretty much everything will be a
>> 1 to M or a M to M.
>>
>> Jim.
>>
>>