Как бороться с большими объектами? - PullRequest
1 голос
/ 06 марта 2011

У меня есть 5 типов объектов: информация о месте (14 объектов), информация о компании-владельце (5 объектов), фотография, рейтинги (хранит результаты нескольких голосов), комментарии.

Все эти 5 объектов соберутся всоздать один объект (место), который будет иметь все свойства и информацию обо всей информации о месте, изображениях, комментариях и т. д.

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

I 'Некоторое время я тренировался, но я никогда не получал опыта реализации и производительности, но чувствовал, что это слишком много!

Что вы думаете?

Ответы [ 2 ]

3 голосов
/ 06 марта 2011

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

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

В большинстве случаев наилучшее решение может включать выбор только необходимых данных и динамическое обновление страницы с использованием запросов ajax по мере необходимости.

Что касается оптимизации доступа к данным, вам необходимо найти баланс между количеством запросов к базе данных и сложностью каждого отдельного запроса. Из-за задержек в сети часто важно извлечь как можно больше, используя как можно меньше запросов, даже если это означает, что вы иногда будете получать данные, которые вам не всегда нужны. Но если вы включите слишком много данных в один запрос, то вычисление всех объединений также может быть дорогостоящим. Очень редко можно увидеть решение, в котором лучше сначала выбрать все корневые объекты, а затем для каждого элемента выбрать некоторые дополнительные объекты, связанные с этим элементом. Поэтому разработайте свое решение для одновременной выборки всех данных, но включайте только то, что вам действительно нужно, и старайтесь свести к минимуму количество задействованных таблиц.

1 голос
/ 06 марта 2011

На самом деле вам нужно решить 3 проблемы, и они часто делятся на DAL, BLL и UI

Ваши объекты, очевидно, принадлежат BLL, и если вы рассматриваете производительность, то вам нужно подумать, как ваши объекты будут созданы и как они взаимодействуют с DAL. У меня много объектов с 50-200 свойствами, поэтому 14 свойств на самом деле не проблема.

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

Займитесь этим по одной за раз и посмотрите, где ваши проблемы.

...