Re: How to work with m:n relationships?

From: David Portas <REMOVE_BEFORE_REPLYING_dportas_at_acm.org>
Date: 21 Feb 2006 13:05:57 -0800
Message-ID: <1140555957.847650.65410_at_o13g2000cwo.googlegroups.com>


vldm10 wrote:
> I will use the post which was on comp.database on 25 January 2006,
> "Design Query", as one example for m:n relationships. Here we
> should to design a database to track product subscriptions. The
> solutions are simplified so that we can concentrate on m:n relationship
> and on some dis/adventages. Let following solution be as it is usually
> done in the relational databases.
>
> Subscriber ( ssn, name, address, phone, email, login, password,
> datefrom, dateto, other-details)
> Product ( product_code, name, price, other_details)
> SubscriberProduct ( ssn, product_code, type_of_subsription, date_from,
> date_to )
> Keys are ssn, product_code and (ssn, product_code) respectively. I will
> compare above solution with the following (which I defined in
> www.dbdesign.com):
>
> SubscriberSt (Key1, ssn, name, address, phone, email, login, password,
> datefrom, dateto, other_details)
> ProductSt (Key2, product_code, name, price, date_from, date_to,
> other_details)
> SubscriberProductSt ( Key3, Key1, Key2, type_of_subsription, date_from,
> date_to )
> Here every Key is one column generated key. This solution has suffix
> St and I will call it St-solution. So, Keys are only difference between
> these two solutions. We will assume that the entities and the
> relationships can change their own states.
>

You are saying that both are relational solutions (they differ only in the choice of key) so what is of interest in your example?

In this thread:
http://groups.google.co.uk/group/comp.databases.theory/browse_frm/thread/d6d693e595463cb8/f4a557e8da8c46a7

You stated:

"For some situation regarding m:n relationships, the relational database theory doesn't have appropriate solution"

I don't see anything to back up that claim, if that was what you intended. I think temporal data in RM is a solved problem.

--
David Portas
Received on Tue Feb 21 2006 - 22:05:57 CET

Original text of this message