Patrick Clery <[EMAIL PROTECTED]> writes:
> Here's the structure of the marital status table:
Also I find it very odd that you have a "marital status table". marital status
is just one attribute of member. Do you expect to have more than one marital
status bitfield per member? How would you distinguish which one to use?
It's going to make it very hard to combine criteria against other attributes
even if you do manage to get a GiST index to work against marital status and
you do the same with the other, then postgres will have to do some sort of
merge join between them. It also means you'll have to write the same code over
and over for each of these tables.
I think you're much more likely to want to merge all these attributes into a
single "member_attributes" table, or even into the member table itself. Then
your goal would be to match all the member_attribute bits against all the
member_preferred bits in the right way.
The more conventional approach is to break them out into a fact separate
table:
member_id, attribute_id
And then just have a list of pairs that apply. This kind of normalized data is
much more flexible for writing all kinds of queries against. But like you've
found, it's hard to optimize this to be fast enough for transactional use.
I think the normal approach with dating sites is to leave this for a batch job
that populates a match table for everyone and just have the web site display
the contents out of that table.
--
greg
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
