Измерение производительности для одного или нескольких запросов при наличии большого количества таблиц мостов - PullRequest
Новая
       4

Измерение производительности для одного или нескольких запросов при наличии большого количества таблиц мостов

2 голосов
/ 19 декабря 2009

я задал этот вопрос вокруг одного соединения или нескольких (выберите n + 1) запросов

Я хотел бы узнать, было ли это так же, если у вас было много-много отношений и много таблиц бриджа

например, вот мои таблицы:

Таблица: Люди (идентификатор, первый, последний, возраст, телефон и т. Д.)
Таблица: Роли (идентификатор, имя)
Таблица: PeopleRoles (id, personID, roleID)
Таблица: Навыки (идентификатор, имя)
Таблица: PeopleSkills (идентификатор, personID, skillID)

поэтому, если бы я сделал соединение, я бы получил несколько строк для каждого человека (при условии, что у человека много ролей или несколько навыков).

при условии, что существует много подобных таблиц с множеством взаимосвязей, что быстрее:

Вариант 1:

  1. Выберите * из приложений
  2. затем переберите каждое приложение и запустите Select * from Roles, где applicationID = id inner join

Вариант 2:

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

1 Ответ

4 голосов
/ 19 декабря 2009

Вариант 2 - почти всегда будет быстрее, если у вас не так много повторяющихся значений. Это действительно зависит от размера избыточных данных - но необходимость делать несколько операторов выбора действительно является смертельным приговором, когда у вас большое количество строк, потому что он должен выполнять циклы и не может делать более сложный тип объединения на стороне сервера, но, возможно, что еще более важно - если ваша логика совершает много обращений к базе данных, они происходят через границы процесса / сети, что само по себе на порядок медленнее.

Существуют и другие способы оптимизации результатов, если они действительно, действительно имеют значение - вы могли бы создать базу данных для создания некоторого XML, который можно было бы более эффективно сериализовать между уровнем данных и уровнем логики, но это МНОГО работы вряд ли кто-то назвал бы кроссплатформенный или универсальный.

Конечно, IMO - это вопрос напрашивается ... Почему бы просто не использовать ORM, такой как Linq to Entities или Linq to SQL или (N) Hibernate? Зачем изобретать это колесо?

...