Приглашаем опытного программиста для поддержки и развития крупного информационного портала на Битрикс.
27.11.2008 22:12:12
Приглашаем опытного программиста для поддержки и развития крупного информационного портала на Битрикс.
|
|
|
|
27.11.2008 22:49:23
Мой метод.
Допустим имеется у нас инфоблок с предложениями продавцов. В каждом предложении у нас есть поле с привязкой к продавцу. Продавец - это запись в другом инфоблоке. Делать обращение к продавцам при обработке каждого предложения - затратно и нелогично. Делаем следующим образом. Сначала перебираем все предложения и записываем все возможные значения продавцов (ID записи в инфоблоке продавцов) в отдельный массив при этом ключами (!). Т.е. обрабатывая запись мы получили ID продавца = 100, делаем ключ в массив $arSellers[100] = 1. В итоге получаем массив продавцов, где ключи - ID продавцов, а значения везде = 1. Массив имеет вид:
Теперь делаем выборку вида
В ходе этой обработки, допустим, мы можем $arSellers[100] заменить на значения элемента с ID = 100. Получим некий справочник продавцов. Ну и далее вы этот справочник можете использовать как душе угодно - вставить в выборку предложений, вывести в шаблоне название и ссылку на продавца. Тут по сути всего 2 запроса (хотя на практике может быть чуть больше, допустим 4 или 5). Ну и разумеется, лучше всё это хозяйство кэшировать.
———
|
|||||
|
|
03.12.2008 20:50:05
Была такая же ситуация, но с бОльшим количеством связей с другими инфоблоками. Пробовали по-разному. В итоге - использовали чистый SQL. Ну, скажем так, пратически чистый, немноо зависящий все-таки от переданных компоненту параметров.
крыша этого дома - пуленепробиваемая солома.
|
|
|
|
03.12.2008 22:54:14
Виталий Оборин верно обрисовал подход.
Проблему с подобными симптомами решали аналогичным его совету способом. Имхо, подобные вещи получаются из-за невозможности с помощью API битрикса сделать JOIN нескольких ИБ и вернуть результаты в рекордсете.
Поэтому и приходится делать запрос к первому ИБ, собирать ключи внешние и делать второй запрос к связанным ИБ что бы вытащить нужные данные. Ну или обходить в цикле и на каждой итерации дёргать. К примеру, стандартная функция по приводу внешней связи к читабельному виду (Название + URL) делает запрос с помощью всё того же GetList и если вы в цикле для своей выборки делает подобные вещи, то получите по одному запросу на каждый шаг цикла. Хотя можно обойтись одним или несколькими запросами. Очень интересно узнать менение разработчиков, что именно мешает и мешает ли ввести в классы работы с ИБ возможности джойна на уровне API |
|||
|
|
04.12.2008 01:30:26
Как вариант - фильтр на ajax попробовать, типа гуглового выпадающего списка фраз.
Не надо сверлить зубы через задний проход дрелью от Сваровски
|
|||||
|
|
04.12.2008 11:27:39
Гадаю, проблема в разработчиках, которые написали неправильный код, или в битриксе, который тормозит и будет тормозить... А как вы решаете вопрос с обновлениями версий битрикса при использовании чистого SQL? Он у вас не связан с другими частями? |
|||
|
|
04.12.2008 11:28:53
Как это проверить, нигде не нашел? |
|||
|
|
04.12.2008 11:34:24
В примерах работ я видел сайты Эльдорадо, Банки.ру, Гдеэтотдом, там ведь тоже по большие базы и много выборок из них. Любопытно, как там реализованы эти механизмы? Кстати, заметил, что стандартные компоненты типа фотогалереи, форум и др, работают сравнительно быстро. Возможно, разработчики не учили особенности битрикса при создании компонентов. Где можно об этом почитать? Еще вопрос, насколько принципиально выделять рабочий функционал в компонент или использовать прямо в файле: sitename.ru/service/index.php ? |
|||
|
|
04.12.2008 12:09:50
не сравнивайте сайт эльдорадо со своим, он работает на 4 серверах по моему, используется БД MSSQL или Оракл (у QSOFT можно подробнее почитать что там сделано).
А выход какой для вас - перевестись на инфоблоки 2.0, поставить индексы по полям фильтра, отловить длинные запросы и определить откуда они вызываются, попытаться оптимизировать запросы при помощи стандартных утилит MySQL. Если не поможет - поставить второй сервер только для MySQL, настроить работу двух серверов в связке и смотреть что будет дальше. Была подобная задача, только там не элементов было 50к, а свойств примерно 900к. Мы вышли из ситуации следующим образом - перевели инфоблоки в инфоблоки 2.0, поставили индексы для работы выборки по фильтру, потом отказались от API Битрикса и перешли на прямые запросы. Как вариант, вы можете сделать так - производить запрос один раз, потом сериализовать полученный массив и выводить в дальнейшем его, а не делать запросы к БД.
тел. +7-3852-555-807
WA +79339335399 |
|
|
|
04.12.2008 12:17:22
если делать так - будет жутко неудобно отслеживать изменения и вносит коррективы. Компонентная модель подразумевает разделение логики работы и шаблона вывода информации на две части. Если от этого уходить - следующий ваш программист будет месяц въезжать в логику работы сайта, и только потом будет вносить какие то изменения. Если для вас - это непринципиально - делайте так, как вам удобно.
тел. +7-3852-555-807
WA +79339335399 |
|||
|
|
04.12.2008 12:37:53
Поэтому и ищу решения, как это исправить. Интересно, отказ от mySQL в пользу Oracle сильно увеличит производительность? Насчет отдельного сервера базы данных - хорошая идея, будем думать, но все-таки невозможно все время наращивать мощности оборудования, сайт должен работать быстро за счет своей структуры. Или получается, что все упирается в технические ресурсы? Как проверить версию инфоблоков? |
|||
|
|
04.12.2008 14:57:10
Любые другие варианты - чистой воды мазохизм, с этим к психиатру.
Не надо сверлить зубы через задний проход дрелью от Сваровски
|
|||||||||||||||
|
|
||||||||||||||