Re: BOOLEAN RELATIONSHIPS: HARD QUESTION

From: Jacopo <jacopols_at_libero.it>
Date: Mon, 14 Jun 2004 20:19:19 GMT
Message-ID: <bLnzc.110599$Qc.4194951_at_twister1.libero.it>


Thank you very much for your help. Maybe the one you gave me is not the definitive solution since I haven't been able to explain you everything but the idea is great and made me think.
Let me ask you if I correctly understood what you said: I can create a table with all the possible combination of A, B, and C, an identifier of the combination and a flag to tell if it is allowed or not. In the second table a field with the ABC combination identifier and the possible D items associated with it.
I need to think about it but it looks good. My only worry at the moment: 25 items in A, 10 in B, 10 in C means
25*10*10=2500 record.
I simplified in my explanation but the machine we build are really complex and so I guess in the end the entries in the frist table could be millions. How much time would it take the program to examine them even if the table is indexed?
Anyway the suggestion is great and I will for sure think about it. Thank you very much.

        Jacopo

"Brian Inglis" <Brian.Inglis_at_SystematicSw.Invalid> ha scritto nel messaggio news:esdrc0dmmfafgg5eidk36ghtf7i88h8kp0_at_4ax.com...
> On Sun, 13 Jun 2004 16:50:26 GMT in comp.databases.theory, "Jacopo"
> <jacopols_at_libero.it> wrote:
>
> >I need to create a database for my company. We build machines and so we
have
> >a part list of the components.
> >I have created a model of the machine in which there is a list of
components
> >to be filled in order to complete the design scheme.
> >Every machine will be composed by:
> >1 mandatory element of type "A" among the entire list of A type items
> >1 mandatory element of type "B" among the entire list of B type items
> >4 mandatory element of type "C" among the entire list of C type items
> >N optional element of type "D" among the entire list of D type items
> >
> >The problem is this. When you choose a specific element to fill the type
"A"
> >box you can't then choose among all the items of list B to fill the type
B
> >box but among those B elements that matches the selected A items.
> >As well the type C is influenced by the previous choices but in this case
> >the list must be differently selected for any combination of the chosen A
> >and B items.
> >The optional elements on the other side can be present or not, according
to
> >the selected A, B, C items or to a combination of them all.
> >
> >The problem is creating a solid model of relationships in order to let
the
> >user select among the only items that matches the previous ones.
> >Definitely I don't want to create rules into the source code.
> >The idea is giving them a mask in which, when they create a new item,
they
> >can link it with OR, AND, NOT, XOR, ecc. relationship.
> >The problem for me is saving these rules. If just one "AND" relationship
> >between two items was allowed a new table with matching couples would be
> >enough, but in this case I should be able to implement a rule like:
> >
> >If you choose the item A38 in A AND B15 in B AND NOT C44 in C, then
you
> >can select the optional element among this list.
>
> You have a set of allowed combinations of elements A, B, C: first table.
> Given this list, you then have combinations that allow or disallow option
D.
> Whether you keep the all the allowed or just the disallowed combinations
for
> each D is up to you: second table.
>
> You can retrieve all the A options with a select distinct, B options
similarly
> with the given A selected, likewise C given A and B.
> Once you have each C selection, you can store each selected combination.
> Given the four selected A, B, C combinations, you can retrieve the D
options
> that either meet all the allowed combination criteria, or are not rejected
by
> disallowed combination criteria.
>
> Spreadsheets are ideal for creating, communicating, and validating this
kind of
> base combinatorial data, and if you can export in tab delimited or CSV
format
> and import that format into the database, quick turnaround on data loading
and
> query testing.
>
> --
> Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
>
> Brian.Inglis_at_CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
> fake address use address above to reply
Received on Mon Jun 14 2004 - 22:19:19 CEST

Original text of this message