Как по-умному сделать мульти-JOIN + CASE-statement?

Question

[Григорий Васильков]

Есть в битриксе понятие "секции". Это как бы коллекция из разделов админки (со свойствами ключ-значение)
https://www.screencast.com/t/f9ESw5mYV5mP

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

Собственно в чем беда - у нас есть 6 инфоблоков-"неймспейсов"-коллекций (напр. шины, диски, акб и еще пару штук)

Свойства каждой из категорий заданы по ID этого неймспейса. То есть структура базы битрикса примерно такая:

b_iblock - таблица с типами элементов (разделы админки)
b_iblock_section - таблица с секциями (категориями в админке)
b_utm_iblock_1_section - множественные свойства ключ-значение
b_utm_iblock_2_section - множественные свойства ключ-значение
b_utm_iblock_3_section [n...] - множественные свойства ключ-значение
b_uts_iblock_1_section - единичные свойства, где ключ это имя колонки, а значение - собственно значение
b_uts_iblock_2_section - единичные свойства, где ключ это имя колонки, а значение - собственно значение
b_uts_iblock_3_section [n...] - единичные свойства, где ключ это имя колонки, а значение - собственно значение

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

Так собственно вопрос:

Как грамотно подцепить все эти таблицы со свойствами в зависимости от выбранных секций? Типа если у секции такой-то инфоблок, подключить обе таблицы для него. Ясно что можно написать 22 left-join-а и вообще создавать запрос из PHP на-лету, но есть ли способ написать какой-то хитрый SELECT FROM SELECT чтобы он автоматически JOIN-ил одно к другому при условии наличия в выборке "еще одного" инфоблока?

Answer 1

[Григорий Васильков]

Короче, трепались трепались, указывали, поясняли, вот решение.
sandbox.onlinephpfunctions.com/code/adb1eb06ae01c6...

"Неграмотно", зато быстро и работает.

Comments

[Алексей Бурлака]

Красота!

Answer 2

[Draconian]

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

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

Comments

[Григорий Васильков]

Спасибо.
Ну да, есть у нас база, которая работает, так мы сделаем вторую базу и будем делать синхронизацию с первой. Мозги заболят!

Answer 3

[Алексей Уколов]

Как грамотно подцепить все эти таблицы со свойствами в зависимости от выбранных секций?

Почему бы не воспользоваться стандартным API? Битриксоиды наворотили структуру БД, но они же и API для работы с ней написали.
Ваш гигантский сложный запрос, скорее всего, не будет быстрее и точно не будет кешироваться.

Comments

[Григорий Васильков]

А сам пробовал? А я пробовал.

// bitrix
  require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/modules/main/include/prolog_before.php");
  CModule::IncludeModule("iblock");

  // process
  $rows = array();
  $obj = new CIBlockSection();
  $res = $obj->GetList(null, $arFilter = array(
    "IBLOCK_ID" => 8
  ), null, $arSelect = array(
    "ID", "NAME", "IBLOCK_ID", "UF_BRAND"
  ));
  while ($row = $res->Fetch()):
    $rows[] = $row;
  endwhile;

Работает строго для одного инфоблока. Если задать ArSelect массивом - UF_BRAND не выбирается. Эти "наворотилы" хоть бы что-то упростили вместо усложнения.

[Алексей Бурлака]

Вы так и не описали задачу. На уровне логики, а не вашего предоставления изнутри.

[Алексей Уколов]

> Работает строго для одного инфоблока.
> $arFilter = array("IBLOCK_ID" => 8)
Странно, почему бы вдруг только по одному инфоблоку выборка шла...

Действительно, для начала нужно задачу нормально сформулировать и решать её средствами API. Ну и помнить, что один запрос - это далеко не всегда хорошо и правильно.

[Григорий Васильков]

Алексей Бурлака: Деактивировать бренды в которых не осталось товаров, зная что бренды сделаны через элементы справочника, ID которого лежит в свойстве UF_BRAND.

[Григорий Васильков]

Алексей Уколов: ну погоня за "правильным" ни к чему хорошему не приводит. Я услышал, что есть сложности в понимании, не без битрикс-программистов она образовывается.

Задача решается кучей LEFT JOIN-ов либо созданием запроса из PHP динамически, поскольку родное Апи только усложняет SQL, а обычный SQL не позволяет выдирать с динамическим количеством LEFT JOIN.

Я хотел бы сделать это запросом каким-то SELECT FROM SELECT или услышать, что это невозможно, и потому единственный способ foreach ( $sql[] = `+инфоблок` )

[Алексей Бурлака]

Григорий Васильков:
1. Товары «не остаются» в следствии чего-то. Их удалили, продали в ноль, деактивировали, ... Я навешал бы события на нужные изменения и в этот момент проверял бы родительскую папку на предмет того, "пустая" она или нет. При чём плюс в том, что в обратную сторону точно также. Был бренд без товаров, они поступили на склад, отследилось событие и бренд активировался. Ещё плюс в том, что скрипт выполнится исключительно в нужный момент.
2. Как гарантию, можно подготовить скрипт, который раз в сутки (неделю? месяц?) проходит по инфоблокам, сканирует и правит ситуацию по-необходимости.

[Григорий Васильков]

1 - Загружаешь 10 тыщ товаров и 10 тыщ раз выполняется запрос проверки активности. Оптимизация, но по-русски.
2 - В точку! Именно это я и пытаюсь сделать и именно об этом вопрос!

[Алексей Уколов]

Ну так почему не сделать для каждого инфоблока отдельный запрос? Зачем пытаться влезть в БД? Я понимаю, что задача чисто теоретически интересная, но с практической точки зрения лучше всё делать через API.

[Григорий Васильков]

Прости за мою непорядочность, однако, пожалуйста, займись-ка бенчмаркингом и осознай что в коде битрикса запросы 90% делаются через foreach (), и 1000 записей импортируется минуту, тогда как 1000 записей в реале добавить 2 сек.

[Алексей Уколов]

Понятно, lost cause.