Доброе утро! Я ищу способ сохранить уникальный список ключей, в которых могут возникать отношения «один ко многим».
Проблема
Я работаю с ужасно ненормализованной базой данных на работе, и, к сожалению, о редизайне не может быть и речи. У меня есть главная таблица 1NF, которая содержит ряд транзитивных и частичных зависимостей, подобных этой:
Cmpd_Key Group Subgroup Group_Desc
A1 | A | 1 | Same
A2 | A | 2 | Same
B1 | B | 1 | Same1
B2 | B | 2 | Same1
C1 | C | 1 | Diff1
C2 | C | 2 | Diff2 <---This field contains multiple values
Мне часто нужно получить уникальный список Group идентификаторов, но требования обычно также требуют поля Group_Desc. К сожалению, из-за слабых ограничений на ввод данных вверх по течению, это поле описания может содержать несколько записей для Group, что приводит к дублированию, поскольку поле Group должно быть уникальным в большинстве извлечений данных. Для моих целей мне все равно, какую Group_Desc запись я извлекаю, пока я могу поддерживать отношение 1 Group к 1 Group_Desc.
Я придумал уродливое решение, которое я называю Inline View всякий раз, когда мне нужно сослаться на поле Group_Desc в более крупном запросе, но это убивает мою производительность:
SELECT Group, Group_Desc
FROM Table t
WHERE Subgroup = (SELECT MIN(Subgroup)
FROM Table
WHERE Group = t.Group) --Nasty Correlated Subquery
Вопрос
Есть ли у кого-нибудь эффективный трюк для многократного извлечения одной строки из нескольких значений в одном запросе? Я хотел бы иметь возможность отодвигать Group и только первое появляющееся Group_Desc.
Я представляю что-то вроде этого:
SELECT Group, Group_Desc
FROM Table t
GROUP BY Group, Group_Desc
HAVING ROWNUM = [The lowest returned Rownum within the same Group]
Другой разработчик упомянул функцию RANK как возможное решение. но я не видел, как я мог бы использовать это для устранения значений.
Любая помощь, которую вы можете предоставить, будет принята с благодарностью!
----------------EDIT----------------------
Итак, после некоторого дополнительного анализа я смог указать на упущение в моем исходном коррелированном подзапросе, которое привело к слишком длинному плану выполнения. Добавив несколько дополнительных предикатов, оптимизатор смог создать лучший план, который изменил мое время выполнения с 12 до 2 минут, что соответствует моим ожиданиям.
Я немного поэкспериментировал с решением для аналитики, которое Ponder Stibbons предложил ниже. Его решение довольно элегантно, и я выбрал его в качестве ответа на этот вопрос, однако я не смог использовать его в этом конкретном запросе, поскольку время выполнения было значительно медленнее, чем мое исходное решение, в первую очередь из-за индекса, который я смог использовать в своем коррелированный подзапрос.
Я не сомневаюсь, что при честном сравнении решение Analytics будет работать наравне или даже лучше, чем решение Correlated SubQuery. Я ценю помощь каждого по этой проблеме!
