Всем првиет. Есть свойство справочник. Срздаю его через ИБ также там же заполняю. Там вылазит поле Внешний код http://prntscr.com/j72pg5. Предположим оно нужно для каких интеграций - заполняется автоматом. Не понятно зачем его обязательно делать. Точнее понятно когда смотришь под копот. Тип хранение ссвойств в отдельной таблице. И получается что он сохраняет этот внешний код там http://prntscr.com/j72qys . Это бред какой то - по логиге должен быть ID. по чему так? самое интересное если я буду добовлять записи через сам HL то обязательно я должен указать внешний код. То есть если в HL 10000 записей я обязательно должен все проанализировать и поставить уникальный внешний код. если я это не сделаю и поставлю уже имеющий внешний код то он сохранит не предупредит что такой код есть и соответственно соотвествено будет косяк при сохранение. Кто нить с этим сталкивался? Приходит мысль написать самому новое свойство Справочника и сохранять как ID + допилить вывод не как список а как автозополнение а то получается у меня записей 10000000 я буду выводить весь список , а если таких свойств несколько - это бред. может кто то своими идеями поделится почему так?
kirov43 написал: может кто то своими идеями поделится почему так?
Для начала давайте усвоим небольшую разницу: есть привязка, есть справочник, есть список. При использовании привязки - храните идентификатор связанного элемента При использовании справочника - мнемонический код При использовании списка - идентификатор значения списка
Почему-то Вы говорите о справочнике, но подразумеваете список. Вот тут и кроется интересное поведение:
Код
$arFields = [
'UF_STATUS' => 467
];
Вопрос - какой статус будет установлен после обновления элемента? Конечно же 467, но вот что за магическая цифра? Можно переписать фрагмент так:
Стало понятнее, но добавилась лишняя конструкция. А если таких справочников 10? Да в каждом по 15-20 значений? Это что? 150-200 констант заводить? Почему бы не сделать так:
Код
$arFields = [
'UF_STATUS' => 'STATUS_SUCCESS'
];
Семантично - ведь всегда у Вас есть известная связка код->значение. Коротко - не нужно лишних констант и перечислений. Удобно для интеграции - при работе с привязками и списками нужно постоянно искать соответствие ID -> XML_ID и при нахождении обновлять, при несовпадении добавлять, лишние удалять... Чувствуете сколько операций? А теперь фикс: удаляем все значения справочника, заполняем с чистого листа. Проще? Намного.
Такой подход Битрикс использует в CRM (статусы) и он очень хорошо работает.
Как уникальность тогда проверять этих мнемических кодов?
я просвязь таблиц в классическим варианте 1:1 1:n итд. Там же свзяь идет ID таблицы к внешнему ключу к другой таблицы. Ок хорошо не всегда может быть числовой ключ он внешний но почему тогда внешний ключ он автоматически не заполняется если поле пустое при добовление записи в самом HL почему я должен это отслеживать?
А где у битрикса написано про данным механизм почему они так выбрали?
kirov43 написал: почему мнемический код? не понимаю - почему не ID записи HL?
Я же пояснил: 4567, 2356, 4, 12, 67 и т.п. - магические числа в коде, значение которых только автор знает. Через полгода-год их значение никто и не вспомнит и придется искать заново.
Цитата
kirov43 написал: я просвязь таблиц в классическим варианте 1:1 1:n итд. Там же свзяь идет ID таблицы к внешнему ключу к другой таблицы.
А кто сказал, что свойство типа справочник это связь таблиц? Таблицы как раз никак не связаны (нет внешних ключей, триггеров и т.п.). Т.е. с точки зрения СУБД это 2+ независимые таблицы.
Цитата
kirov43 написал: А где у битрикса написано про данным механизм почему они так выбрали?
Как любая большая компания они нигде не отчитываются о своих решениях. На конференциях можете поймать разработчиков и спросить
Андрей Николаев написал: А кто сказал, что свойство типа справочник это связь таблиц? Таблицы как раз никак не связаны (нет внешних ключей, триггеров и т.п.). Т.е. с точки зрения СУБД это 2+ независимые таблицы.
вот внешние коды хранятя в таблице свойств ИБ https://prnt.sc/j72qys - то есть таблица свойств и справочник HL связаны.
ладно все равно так странно делать. ладно со своим уставом в чужой монастрыь не лезут. Почему они не сделали свойство с автозаполнением как у элеменотов? например если в справочнике 10000000 записей и таких справочников несколько то все нахрен повиснет. там даже не кешируется вывод.