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

Add to that BLOB's stored in a separate database (Access file)
And structures where the main (indexed and linking) keys were stored in one
table while the non-indexed data were stored in a separate table.

That enables the keydata to be held in cache for searches etc. while the bulk
data would be accessed directly by index, and only referenced when the
appropriate main key had been identified via the searches etc.  and the main
block of data was to be reviewed or updated.
Maybe a memo field for commentary re history of activities - free form text in
the form of an essay etc.
Or maybe the converse of your suggestion - the non-secure information such as
background details to clinical details of procedures etc. than can be pretty
much publically accessed by researchers, while the details that would allow
identification of the subject are kept securely inaccessible. 

Yes - it may be more secure to not have any link from the open data to the
secure data, but there needs to be some link for maintenance and maybe
contacting the subject if there is an appropriate requirement identified from
searching the open data.

Social services and health records create some 'interesting' requirements that
may need 'non-confirmative' approaches
 
JimB    


-----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 9: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.
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bill Benson
> Sent: Friday, November 28, 2014 07:52 PM
> To: 'Access Developers discussion and problem solving'
> Subject: [AccessD] Confused by One to Many versus One to One
>
> I almost never make relationships one to one, and yet my databases always
> seem to "work." By work, I mean that I never seem to run into situations
> where I cannot accomplish what I want to, in terms of record insertion,
> queries, etc. So I now have a situation where maybe that is not a good idea.
>
>   
>
> I have Order and Product tables, one order can contain many products. So I
> required an OrderProducts table to distribute the same OrderID across
> numerous ProductIDs.
>
>   
>
> My question is, should the relationship between the Order and OrderProduct,
> on the OrderID and FKOrderID, be 1-to-1, or 1-to-many?
>
>   
>
> Likewise, the same question for the OrderProduct and the Product, on the
> ProductID and the FKProductID?
>
>   
>
>   
>

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com