Доработать сортировку в ИБ по имени

Сортировка по ИМЕНИ, если имя является числом, в общем-то в любом софте, работает в порядке:0. 910. 1920. 29и т.д.В БУС сортировка по имени работает1101112. 22021и т.д.

Проблематично, когда имя элемента или раздела это число, или начинается с числа.1. Неудобно когда необходимо сформировать и не дай Бог выгрузить список в файл.2. Препятствует при реализации на базе БУС многих задач, особенно задач связанных с автоматизацией, а так же при интеграции с иным софтом или оборудованием.

Сергей, такое ощущение, что у Вас нет ни одного гос.заказчика, или крупной компании с многолетней историей. Такие заказчики имеют на самых обычных сайтах исторические архивы, например новостей, или истории компаний и т.д. Как по вашему следует называть разделы? "Одна тысяча девятсот шестдесят девятый год"? Или в случае с информационным блоком "Заседания" на сайте регионального Законодательного собрания, которые имеют только номер, где каждое заседание это элемент инфоблока. Как их называть? "Тридцать седьмое заседание"? Ага, и сделать ещё одно поле, чтобы вписывать туда альтернативное название "37 заседание", по которому пользователи ищут интересующие заседания. Или может влупить в поле наименование всю повестку из 13 страниц текста? А ещё есть база нормативно-правовых актов, где названия документа бывают до 2000 символов, единственный выход в поле ИМЯ писать номер документа, а название в анонс.Ещё варианты надо? Пожалуйста - ERP, которую мы готовим для маркетплейса имеет инфоблок докуменоты, где элементы инфоблока это - Счета, Реализация, Транзакции, как в 1С, что писать в поле ИМЯ? Контрагента? Нахер он в поле ИМЯ не нужен, ибо контрагенты это отдельный инфоблок, и все документы привязаны к контрагенту как к элементу иного инфоблока! Ещё пример? ERP для страховой компании, работает уже 4 года, где 12 инфоблоков из 37-ми - это база не только из клиентов и финансовых документов, это ещё и все страховые полисы, оформленные за 10 лет и новые, еще на столько же! Номер полисов состоит из букв и цифр, взять имя ААА1, ААА2. ААА11, и выстроит он их ААА1, ААА11, ААА2, вот только кроме 1, 11, есть еще и 111111111, весело будет перебирать список в поиске ААА2? Искать не проблема можно по имени, а когда нужно выгрузить или распечатать реестр полисов от номера ААА1, до номера ААА100, как будем печатать? Ручками перекалачивать в word? Не тупо? Нет? Все эти проекты сейчас закостыленные в хламину только по одной лишь сортировке. А это дополнительные расходы серверных мощностей, это дополнительное время ожидания формирования списка, это дополнительное снижение производительности продукта, а значит большой МИНУС продукту!

Сергей Ковалев, зайди в любую директорию в оконной OSи, создай директрию, создай там несколько файлов. в т.ч. с числительными именами, и с текстовыми, а так же смешанными, включи сортировку по имени и посмотри. И так любой софт! Так большинство сайтов!

P.S.- Обращаюсь персонально к каждому - прежде чем минусовать, подумай, достаточный ли у тебя опыт работы, на столько ли он достаточен, чтобы утверждать, что в имени элемента инфоблока не может быть число, были ли у тебя проекты, с задачами, которые я привёл в пример.

У себя в похожих случаях всегда перебиваю формат нумерации на лидирующие ноли. Единственный вариант безобидный, если, конечно, условия позволяют.Иначе нужно будет ломать запросы инфоблоков на CAST(name AS) либо name * 1.Как это сделать цивилизованно - хз.

Но насчёт любого софта - это вы, имхо, перебарщиваете. Обычно сортировка числа как строки так и работает. И регулярно попадается именно такая сортировка - 1,11,2,24,3.Разве что нам совершенно разный софт попадался.

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

А мопеды - к чему ваще мопеды городить, когда дефолтная логика нелогичная, надо то что есть один раз "отшлифовать" и баласт виде "мопедов" не нужен будет!

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

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

Обычная частная задача, которая решается обработчиками событий.

Я так понял, у вас не будет номеров вида "ЕП 204095/2012", а только числа - тогда храните числа как ID элемента или отдельное свойство.

Например, заведите числовое свойство или инкремент. И сортируйте по этому свойству.

Перед созданием элемента укажите имя "новый элемент". После создания элемента, замените название на значение нового свойства.

Не правильно поняли Евгений, потому что не читали. Специально привёл пример со страховой компанией, где как раз есть смешанные имена. API продукта не позволяет менять ID элементов, хотя даааа, накостылить можно и это, и костылили, но проблем в тонны раз больше. ID элементов - сущность уникальная в БД, любая ERP и подобная система предполагает наличие нескольких блоков с собственной нумерацией.А делать ещё одно свойство - ну давайте тогда сделаем ещё один модуль инфоблоков, в котором будет работать сортировка полноценно. Ага, и вообще любую проблему будем решать увеличивая количество полей в таблицах БД, которых можно не создавать. Опять же лишний объём данных, соответственно больше времени на обработку запросов, больше накладных расходов на сервер, и как следствие падение производительности.

Читайте выше. плодить свойства - путь тупиковый, особенно для проектов и без того сложных. Закостылить мускул - у нас он итак закостыленный, у нас работает как надо, а вот выпустить хотя бы один блок ERP для маркетплейса не получится, ибо маркетплейс предполагает установку "с кнопки", без необходимости дополнительных костылей, тем паче на сервере, и производительность позволяющая полёт на виртуальном хостинге, что так же требует системного подхода к решению ряда узких мест.