Problem re Set Like Structures
От | Bell John |
---|---|
Тема | Problem re Set Like Structures |
Дата | |
Msg-id | 20010306031937.82723.qmail@web12605.mail.yahoo.com обсуждение исходный текст |
Список | pgsql-general |
Hi, Sorry if this is a duplicate post - I posted yesterday, but I'm pretty sure from the wrong account, and the Email hasn't shown on the list. Also there was an error in the original Email! Whilst I'm new to Postgresql, I have long experience in database work in general. I am currently beginning work on a project for which Postgresql is the preferred database component. The environment is basically RedHat 7.x, Postgresql 7.0.2 and Python 2.x. The problem relates to performing Set like operations on data, specifically determining whether Set A is a subset of Set B. I've read through the Momjian book and am just beginning on the docs, but can't find a data structure to support Set like operations. For a while I became enthused by the possibilities of arrays, but alas I was to be dissapointed. This query type occurs VERY frequently in the application and I can see no efficient solution. The problem is as follows: We have three tables TABLE_A, TABLE_B and TABLE_C. TABLE_C represents an attribute that records in the other two tables may have references to. The relationship between tables A and B on the one hand, and table C on the other are many-to-many. Given no group like structure, the only way I can see to represent these relationships is by Join tables joining TABLE_A<=>TABLE_C and TABLE_B<=>TABLE_C. For any record 'a' in TABLE_A there will be a set A_JOIN_C(a)={c1,c2,...,cn} of records in TABLE_C which represent the keys of TABLE_C for which joins exist to record 'a'. Similarly, for each record {b1,b2,...,bn} in TABLE_B there will exist a corresponding set B_JOIN_C(bi). The problem is for a given record 'a' in TABLE_A to find the set of records in TABLE_B for which B_JOIN_C(bi) is a subset of A_JOIN_C(a). Now, I'm not saying that I can't formulate the query sequence - that's easy. The problem is in finding a tolerably efficient solution without a native GROUP data type. The issue is that this query type occurs so frequently in the problem domain that an efficient solution is mandatory. Does anyone have any suggestions? __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
В списке pgsql-general по дате отправления: