By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
428,997 Members | 1,657 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 428,997 IT Pros & Developers. It's quick & easy.

Best Practices for Storing Set Combinations

P: n/a
I hope this is the correct newsgroup for this query (if not please
give me a pointer to where is best):

I understand the theory of normalisation etc and am trying to follow
best practices in the design of the database for a new project, but I
am unsure as to the best practice when one wants to store data
relating to combinations of arbitrary numbers of sets of data. For
example, take the following two groups of sets, each containing
elements of data which can be combined together in different ways,
each combination requiring a field of information to be related to it:
Group 1
-------
Set 1: a, b and c
Set 2: i and j
Set 3: w, x, y and z

Possible combinations:

a/i/w, a/i/x, a/i/y, a/i/z, a/j/w .... (24 combinations in total)
Group 2
-------
Set 1: A, B
Set 2: I, J and K

A/I, A/J, A/K, B/I .... (6 combinations in total)
So I may need to store 7 for the combination a/i/w and 2 for the
combination a/i/x etc. But at the same time I have to store perhaps 4
for A/I and 9 for A/J etc.

What is the best way of storing this in a database when the number of
sets *and* the number of elements in those sets may vary?

I cannot structure my table as:

element1 | element2 | element3 | element4 | comb_data
a | i | w | | 7
a | i | x | | 2
. | . | . | . | .
. | . | . | . | .
. | . | . | . | .
A | I | | | 4
A | J | | | 9
. | . | . | . | .
. | . | . | . | .
. | . | . | . | .

because I immediately limit the number of sets I can handle and
introduce potentially redundant columns.

Is there a best practices way to handle this scenario?

Many thanks in advance,

Louis
Nov 23 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.