Re: That killer 3rd join...

Поиск
Список
Период
Сортировка
От Oliver Smith
Тема Re: That killer 3rd join...
Дата
Msg-id 20000907011110.A31180@kfs.org
обсуждение исходный текст
Ответ на Re: That killer 3rd join...  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
Ответы Re: That killer 3rd join...  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
Список pgsql-general
> OTOH, I'm not 100% sure what you're trying to get out
> from this query, I'd have expected that it would be, using
> these metals on this stone gives you this result, but since
> the types of jewelery I get are different on the same row
> of output, I'm a little confused.

Each stone gives a specific set of attributes, but combining it with
silver & plat gives one type of jewellery, while gold & electrum
produce a different type.

The reason for including this is so that a chart can be produced
which shows what attributes each stone modifies, how much those
attributes are modified for each stone+metal combo, and what type
of jewellery is produced in the combo.

See http://www.kfs.org/~oliver/eq/jewellery.jsp to see the chart
itself.

As my own side note, on Postgres 7.0.2, I at one point tried creating
a view which said

CREATE VIEW silver_view AS
 SELECT * from jcombo_query WHERE metal_uid = 1 ;

and so on for elec, gold, plat. And then used these to simplify the
main query. This caused Postgres to go away permanently, and I had
to manually delete the database.

And the original query was so slow, that I decided to, for the time
being, do a

 SELECT * INTO jewellery FROM metals_query ORDER BY stone_uid ;


Ol
--
If at first you don't succeed, skydiving is not for you...

В списке pgsql-general по дате отправления:

Предыдущее
От: Chris
Дата:
Сообщение: Re: Inheritance and Constraint
Следующее
От: Stephan Szabo
Дата:
Сообщение: Re: That killer 3rd join...