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

Charlotte Foust charlotte.foust at gmail.com
Sun Jan 4 09:57:27 CST 2015


You can use ADO to return values and update recordsets "on demand" without
having a table link.  Or you can open another database in code to perform
updates without having a link in the current database.

Charlotte

On Sun, Jan 4, 2015 at 5:09 AM, James Button <jamesbutton at blueyonder.co.uk>
wrote:

> 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
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>


More information about the AccessD mailing list