Я разрабатываю веб-приложение, которое, по нашим оценкам, может иметь около 1500 уникальных пользователей в час. (У нас нет статистики для одновременных пользователей.). Я использую ASP.NET MVC3 с серверной частью Oracle 11g, и весь поиск будет осуществляться с помощью упакованных хранимых процедур, а не встроенного SQL. Приложение только для чтения.
Таблица A содержит около 4 миллионов записей.
Таблица B насчитывает около 4,5 миллионов записей.
Таблица C содержит менее 200 000 записей.
Есть две другие крошечные таблицы поиска, которые также связаны с таблицей A.
Таблицы B и C обе имеют отношение 1 к 1 к Таблице A - Таблицы A и B обязательны, а C - нет. Таблицы B и C содержат много строковых столбцов (некоторые до 256 символов).
Поиск всегда будет возвращать 0, 1 или 2 записи из таблицы A с сопряжением в таблице b и любыми связанными данными в C и поисковыми таблицами.
Мой процесс доступа к данным будет создавать соединение и команду, выполнять запрос, возвращать считыватель, загружать соответствующий объект из этого считывателя, закрывать соединение и удалять.
Мой вопрос такой ...
Лучше ли (с точки зрения производительности) возвращать один широкий набор записей одновременно (используя только одно соединение) или лучше запрашивать одну таблицу сразу за другой (используя одно соединение для каждого запроса), возвращая более узкие записи и присоединить их в коде?
EDIT:
Уточнение - мне всегда будут нужны все данные, которые я бы привел в любом из вариантов. Обе опции в конечном итоге приведут к тому же количеству данных, отображаемых на экране, что и из БД. Но одно будет иметь одно соединение, получающее все сразу (но шире, а может, и медленнее?), А другое будет иметь несколько соединений, одно сразу за другим, получая меньшие суммы за раз. Я не знаю, повлияет ли влияние количества соединений на решение здесь.
Также - у меня есть свобода денормализовать дизайн стола, если я решу, что это уместно.