Добавлено 1 месяца спустя:

#34458 Macik:

Я против плодить сущности. Тем более сейчас есть «рабочий вариант» с нулями.

вариант то как раз и не рабочий на 100%. Если мы имеем структуру до третьего уровня 01.01.01 то да, сортировка ведёт себя правильно. Если  01.01.01.01 то получается то, что я в скрине приложил. Не все сайты, конечно, имеют необходимость в такой структуре, но всё-таки, вариант не 100%-ный.

Т.е. должны успеть к определенному сроку? Разве Кот не независимый продукт?

Я о том, что надо взвешивать востребованность той или иной фичи, в противовес латанию дыр и стратегическому развитию. :)

К тому же, учитывайте, что у разработчиков ограничено время. А в трекере целый лист багов еще висит.

Т.е. должны успеть к определенному сроку? Разве Кот не независимый продукт?

Если считаете, что фича котонти в массовом изменении и легкости изменения структуры, тогда стоит подумать о массовом добавлении категорий. Вы попробуйте добавить 200 категорий через существующий интерфейс - это сводится в ад. 

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

Добавлено 46 секунд спустя:

ps. Но активность обсуждения данного вопроса меня радует. :)

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

А для сортировок реально проще будет использовать или экстраполе или правильно составленную структуру.

Да и переименовать ПУТЬ в ID

Смысл поменяется, не в лучшую сторону

Числа к числам и буквы к буквам. Да и переименовать ПУТЬ в ID а то что путь ассоциируется с ссылкой. Вроде все)))

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

Только если так. Только мне не понятно, как целочисленной сортировкой путей выбирать родительские категории?

А что если вообще скрыть от пользователя поле указания пути, а вместо него сделать селектбокс для выбора родительской категории?

Это ранее предлагалось неоднократно. Привет, другие CMS. Тогда теряем одну из важных фишек движка, позволяющих быстро менять структуру сайта редактированием путей (а не бесконечной чередой действий "открыть категорию, изменить родителя, сохранить, открыть категорию, изменить родителя..."). И ещё работа со структурой с точки зрения кода станет не работой с простым списком, а обходом дерева.

Добавлено 2 минуты спустя:

Целочисленную сортировку для путей сделать можно. Ещё не знаю, чего это будет стоить с точки зрения трудозатрат и производительность, но теоретически такая возможность есть. Но тогда надо добавлять конфиг, чтобы админ мог выбирать, между алфавитными путями/сортировкой и целочисленными.

А что если вообще скрыть от пользователя поле указания пути, а вместо него сделать селектбокс для выбора родительской категории?

Против!

Возможно это не продуктивно, но зато решает эту проблему не меняя основной принцип указания пути категории.

Хотя, да, если пути указанны в числах...

А что если вообще скрыть от пользователя поле указания пути, а вместо него сделать селектбокс для выбора родительской категории?

Все готовы?

Нет. McDuck правильно сказал. Лучше 1.1.1.1

В структуре если хотите целочисленную сортировку, то давайте сначала откажемся от поддержки всего кроме чисел в путях. Все готовы?

Если вы хотите сделать, например, поле "Расстояние до пляжа" со значениями "рядом, 50м, 100м, 150м, 200м, 500м, 1км, 2км, 3км", а затем сделать аккуратную сортировку по нему, то правильный выход - это хранить данные без единиц измерения. Скажем, "0, 50, 100, 150, 200, 500, 1000, 2000, 3000", а буковку "м" выводить в шаблоне. Пользователям будет удобнее, если вы сделаете небольшой плагин, который будет на лету переводить м в км и обратно (при вводе или выводе). Но не просите сделать это базу данных.

Причем тут юзеры и структура?

Во-первых, пути категорий - это отдельно взятый случай, живущий по своим правилам. Как заметил esclkm, в них допускаются не только числа, но и буквы. Как заметил McDuck, численная сортировка для них сильно затруднена.

Во-вторых, не существует "универсальное решение". Иначе создатели СУБД давно бы сделали один единственный тип данных вместо всех этих VARCHAR, INT, FLOAT и т.д. Вы просите написать некую волшебную функцию, которая будет на лету распознавать тип данных (а они ещё и разные, оказывается, например "0, 3.75, капуста, 4, 6км, морковь, 300, 999.999") и упорядочивать их заново. Но имейте в виду, что даже если вы просто немного "ошиблись" и храните целочисленные данные в текстовом поле, то MySQL из-за этого тратит на выборки и сортировку по этому полю ощутимо больше времени, потому что операция сравнения строк медленнее, чем сравнения чисел.

Если вы хотите сделать, например, поле "Расстояние до пляжа" со значениями "рядом, 50м, 100м, 150м, 200м, 500м, 1км, 2км, 3км", а затем сделать аккуратную сортировку по нему, то правильный выход - это хранить данные без единиц измерения. Скажем, "0, 50, 100, 150, 200, 500, 1000, 2000, 3000", а буковку "м" выводить в шаблоне. Пользователям будет удобнее, если вы сделаете небольшой плагин, который будет на лету переводить м в км и обратно (при вводе или выводе). Но не просите сделать это базу данных.

это не универсальное решение. Что делать с полями смешанного типа?

Меня больше озадачивает, что значения пути не проверяются на уникальность

я у себя на сайте юзаю в качестве путей только то что мне понятно anat.golov, hir.uro.mkb и тд

но вы хотите лишить меня этого? а смысл? ди а прямо со стратью хотите числа - вопрос зачем?

Тем, что вопрос касается не только структуры сайта. Любой плагин, любой функцонал, который использует сортировку выводит не правильно. А писать, допустим, в характеристиках товарав: 050м (вместо 50м), 100м, 200м чтобы сортировало правильно - это действительно шаманство.

Для численной сортировки создавайте числовые поля. Их MySQL будет сортировать как числа. Сортировать выборку из БД на стороне PHP - вот это было бы шаманство.

А писать, допустим, в характеристиках товарав: 050м (вместо 50м), 100м, 200м чтобы сортировало правильно - это действительно шаманство.

Вот на счет этого - соглашусь!

Чем вариант с 01,02,03,...,09,10.11,... не устраивает?

Тем, что вопрос касается не только структуры сайта. Любой плагин, любой функцонал, который использует сортировку выводит не правильно. А писать, допустим, в характеристиках товарав: 050м (вместо 50м), 100м, 200м чтобы сортировало правильно - это действительно шаманство.

на неохроме поднимался этот вопрос

Здесь этот вопрос тоже поднимался

Чем вариант с 01,02,03,...,09,10.11,... не устраивает?

Это шаманство. Если структура очень ветвистая и большая, то нужно додумывать 01 или 001 или 0001. 

1,11,12,13,2,21,22,3,31,32

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