механизм/инструкция?
Берете самый жирный инфоблок и выносите его в отдельную таблицу, а там уже используете uuid вместо id. Правда на практике я не встречал чтобы кто-то хотя бы близко подошел к этому числу на битриксе. Максимум что я видел это было 15кк.
а я встречал) но у нас со значениями свойств было такое)
Что имеете в виду под "вынести в отдельную таблицу инфоблок"? Со свойствами - понятно. А как элементы не в b_iblock_element хранить?
Если вы подошли к этому лимиту то вы уже знаете что нужно делать. "Элементы ИБ" не в "ИБ" хранить нельзя, поэтому если вы подошли к этой черте, то возможно стоит задуматься - а правильно ли вы все делаете и может есть другое, более рациональное решение?
Не подошёл :) Спросил из интереса. То есть коробочного решения вроде "переместить элементы инфоблока в отдельную таблицу" не существует :)
(мрачно) на свойствах подошли.
Не помню, есть ли в api экономия ID-ников. Возможно, что нет. Но переделывать - застрелиться дешевле. А менять размер ID - дешевле застрелиться 18 раз подряд.
Интересно как решать будете. Lock на 64bit + BigInt? Миграция на UUID с ломанием обратной совместимости?
Я же сказал - дешевле застрелиться 18 раз подряд 😥
Застрелиться всегда успеется, а проблему как решать будете?)
16 раз застрелимся - и то легче
По факту изменится половина таблиц, связанных с инфоблоками
Как хорошо, что все работают с Битриксом через api)
Обсуждают сегодня