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

Рейтинг: 6.5198  
Отложено
Предложил Пользователь 5535 27.05.2012 02:06:10

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

Сортировка по ИМЕНИ, если имя является числом, в общем-то в любом софте, работает в порядке:
0
...
9
10
...
19
20
...
29
и т.д.
В БУС сортировка по имени работает
1
10
11
12
...
2
20
21
и т.д.

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

Рейтинг: 1.7056  
Пользователь 5535 27.05.2012 02:22:58
Вот только не надо комментировать, мол: "Индекс сортировки можно использовать", или: "Заведи свойство для дополнительной сортировки". Индекс сортировки используется! А создавать ещё одно поле, только для того чтобы дублировать функцию (сортировку по ИМЕНИ), которая есть, но работает не правильно, это такой же нонсенс в программинге, как в автопроме - предложить владельцам авто на случай неправильного поведения двигателя ставить второй - дублирующий... :D
Рейтинг: 0.6119  
Пользователь 40370 28.05.2012 04:30:22
Так имя никогда не является числом, это всегда строка, поэтому сортировка правильная.
Рейтинг: 2.3759  
Пользователь 5535 28.05.2012 05:10:26
Так имя никогда не является числом, это всегда строка, поэтому сортировка правильная.
Сергей, такое ощущение, что у Вас нет ни одного гос.заказчика, или крупной компании с многолетней историей. Такие заказчики имеют на самых обычных сайтах исторические архивы, например новостей, или истории компаний и т.д. Как по вашему следует называть разделы? "Одна тысяча девятсот шестдесят девятый год"? Или в случае с информационным блоком "Заседания" на сайте регионального Законодательного собрания, которые имеют только номер, где каждое заседание это элемент инфоблока. Как их называть? "Тридцать седьмое заседание"? Ага, и сделать ещё одно поле, чтобы вписывать туда альтернативное название "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.- Обращаюсь персонально к каждому - прежде чем минусовать, подумай, достаточный ли у тебя опыт работы, на столько ли он достаточен, чтобы утверждать, что в имени элемента инфоблока не может быть число, были ли у тебя проекты, с задачами, которые я привёл в пример.
Рейтинг: 0  
Пользователь 5535 28.05.2012 05:21:39
Да кстати, при создании нового документа, например финансового в ERP, номера у нас присваиваются автоматически, и в отличие от штатного интернет-магазина, нумерация у нас с 00:00 1-го января каждый год начинается новая, при этом архив документов удалять не нужно. Всё работает по принципу 1С-ки... Так же и в страховой компании есть функция генерации полисов, где задаётся серия из букв, указываются стартовый номер и конечный номер, указывается привязка е филиалу страховой компании и все необходимые элементы (полисы, сотнями) создаются сразу с привязкой к филиалу, сотрудники которого тут же видит их в списке своих бланков...И из-за неправильной сортировки тоже закостылено всё по самые уши, ибо для генерации, как и вообще для всего остального функционала, использовали только API продукта!
Рейтинг: 6.2761  
Пользователь 39858 28.05.2012 08:19:54
У себя в похожих случаях всегда перебиваю формат нумерации на лидирующие ноли. Единственный вариант безобидный, если, конечно, условия позволяют.
Иначе нужно будет ломать запросы инфоблоков на CAST(name AS) либо name * 1.
Как это сделать цивилизованно - хз.

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

Рейтинг: 0  
Пользователь 32566 28.05.2012 09:48:55
Поле `NAME` хранится как СТРОКА вот она и сортируется как СТРОКА.
Ограничения в MySQL. Там не предусмотрено натуральной сортировки.Вот наковырял какое-то решение в виде встроенной функции
http://drupalcode.org/project/natsort.git/tree/1a48f37c5f1823edc08e411674846817d6a6f43b
Там как раз все числа заменяются на длинные последовательности с ведущими нулями.
С точки зрения производительности не берусь судить.
Мопед не мой))
Рейтинг: 0  
Пользователь 5535 28.05.2012 11:25:41
перебиваю формат нумерации на лидирующие ноли. Единственный вариант безобидный, если, конечно, условия позволяют.
В том то и дело, что условия не позволяют, есть проекты, где в первую очередь необходимо исключить ошибки, так как ошибка в серии и номере страхового полиса - полис недействительный, ошибки на правительственных сайтах сайтах региональног уровня - тёрки с прокурорами.

А мопеды - к чему ваще мопеды городить, когда дефолтная логика нелогичная, надо то что есть один раз "отшлифовать" и баласт виде "мопедов" не нужен будет!
Рейтинг: 0  
Пользователь 39858 28.05.2012 11:33:27
Так дефолтная логика просто наследует сортировку базы, в частности, мускула.
Видимо потребности такой не было особо. На мускуле она и организуется через костыли, которые описывал, просто что поддержку такого костыля может нативно сделают, хотя может и нет, всё-таки, он всё равно костыль.
В оракле вроде есть такая сортировка нативно, там проблем меньше.

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

Рейтинг: 6.2603  
Пользователь 25773 28.05.2012 12:14:45
Обычная частная задача, которая решается обработчиками событий.

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

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

Перед созданием элемента укажите имя "новый элемент". После создания элемента, замените название на значение нового свойства.
Рейтинг: 0  
Пользователь 1848 28.05.2012 12:17:09
Вот только не надо комментировать, мол: "Индекс сортировки можно использовать", или: "Заведи свойство для дополнительной сортировки". Индекс сортировки используется! А создавать ещё одно поле, только для того чтобы дублировать функцию (сортировку по ИМЕНИ), которая есть, но работает не правильно
Почему же, поле имя это строка и сортировка проходит по типу строка. Если у вас другая задача, то это ваша частная задача. Решение ее вы привели сами. Не вижу проблем ее реализации.
Рейтинг: 0  
Пользователь 5535 28.05.2012 15:09:37
Я так понял, у вас не будет номеров вида "ЕП 204095/2012", а только числа - тогда храните числа как ID элемента или отдельное свойство.
Не правильно поняли Евгений, потому что не читали. Специально привёл пример со страховой компанией, где как раз есть смешанные имена. API продукта не позволяет менять ID элементов, хотя даааа, накостылить можно и это, и костылили, но проблем в тонны раз больше. ID элементов - сущность уникальная в БД, любая ERP и подобная система предполагает наличие нескольких блоков с собственной нумерацией.
А делать ещё одно свойство - ну давайте тогда сделаем ещё один модуль инфоблоков, в котором будет работать сортировка полноценно. Ага, и вообще любую проблему будем решать увеличивая количество полей в таблицах БД, которых можно не создавать. Опять же лишний объём данных, соответственно больше времени на обработку запросов, больше накладных расходов на сервер, и как следствие падение производительности.

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

P.S. - зайдите в партнёрский форум, найдите мою последнюю тему, почитайте и поймёте о чём речь.
Рейтинг: 0  
Пользователь 69300 06.07.2012 16:51:36
Битрикс никак не должен подменять результат запроса к базе.

Вы вправе испольвазоть функцию http://us2.php.net/manual/en/function.natsort.php в качестве фильтра для вашей конкретной задачи.  
Рейтинг: 0  
Пользователь 81613 21.09.2012 15:16:19
Думаю, хорошим решением со стороны разработчиков битрикса было бы добавить какой-нибудь функционал в виде API, а может быть и в интерфейсе админки, позволяющий устанавливать поля Sort у разделов/элементов инфоблоков в соответствии с какой-нибудь (в том числе натуральной) сортировкой по какому-нибудь полю или свойству (полям и свойствам).
Рейтинг: 0  
Пользователь 61475 15.11.2012 00:52:29
Поддерживаю. Подобия natsort для mysql очень не хватает. Было бы супер применять натуральную сортировку (опционально) для любых строковых полей
Рейтинг: 0  
Пользователь 12674 12.06.2013 17:46:50
изначально продукт должен быть готов отсортировать все по числам, далее по алфавиту. может и по чекбоксу какую логику применить. Но текущий вариант какашка. И дело тут не в документах даже, а в умных фильтрах.

Есть поле типа строка, значения - например диафрагма объектива.
1,5,10,15
в фильтре увидим
1,10,15,5

крутить базу строя доп поля - маразм