Оптимизация поиска по базе данных Oracle

Question

У нас есть набор таблиц клиентов, таких как клиент, адрес клиента, связь с клиентом, профессия клиента (оракул 11g).

Внешний интерфейс предоставит несколько деталей, таких как «email-id», «f-name», «city», «state», для поиска в БД и возврата соответствующих данных о клиенте.

во всех таблицах содержится более 10 кулонов, и когда найдены совпадающие emailid, f-name, city, state, мы должны вернуть данные этого клиента.

детали возврата распределены по всем 4 таблицам, и нам нужно объединить все 4 таблицы, чтобы получить детали для возврата. (например: нам нужно перенастроить cust-id, номер приложения, город, штат, номера телефонов, профессию deatisl)

comm-metchod - может иметь как электронную почту, телефон, факс и
comm-method-values ​​- будет содержать их значения

также клиент может иметь несколько адресов (с разными идентификаторами адресов) и профессий!

Проблема здесь в размере данных, и объединение занимает больше времени. мы рассматриваем наличие материализованных представлений, но, тем не менее, размер представлений будет невероятно увеличиваться, когда клиент сможет использовать несколько адресов, адресов электронной почты и профессий.

ищет предложение, чтобы решить сложность поиска.

таблицы похожи -

имя-Tab: КЛИЕНТ
CUST_ID
F-Name
L-Name
Pref-Name
Приставка
суффикс
пол
blah1
blah2
бла3

---

имя-Tab: CUST_ADDR
Каст-ID
Каст-адр-ID
улица
appt num
Город
Государство
Страна
blah4
blah5
бла6

---

имя-Tab: CUST_COMMUNICATION
Каст-ID
Каст-адр-идентификатор
Comm-метод * +1049 * Comm-метод-значение
blah7
бла8

---

имя-Tab: CUST_PROFESSION
Каст-ID
профессия-код
описание профессии
Комментарии-TXT
blah9
бла10

---

Answer 1

Вам необходимо спланировать, какие запросы будут разрешены;это минимальные обязательные поля и индексы для их поддержки.

Я не могу представить, что поиск только по городу или штату даст полезный результат.У вас будет слишком много совпадений.

Email-Id будет очень избирательным, поэтому вы используете один запрос, если они предоставляют идентификатор электронной почты.Запрос будет передан от небольшого числа сопоставленных записей customer_communication до родительского клиента и затем до других дочерних записей.

Имя и фамилия будут приемлемо избирательными, поэтому используйте второй запрос, если они их предоставляют, но НЕ указывайте email_id (который использовал бы первый запрос). Имя, город и штат могут быть приемлемымипоэтому третий запрос для этой фамилии плюс город плюс штат может быть приемлемым, поэтому четвертый запрос для этого

Большинство индексов, вероятно, будет кэшироваться в памяти.Вы, вероятно, получите несколько физических операций ввода-вывода для каждого запроса.Если вам нужно получить значение ниже этого, посмотрите на материализованные представления или кластеры таблиц (т.е. один кластер на CUST_ID со всеми таблицами, хранящимися как часть этого кластера).