Местоположение (классификация), как правильно описать?

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

Например, есть поле “цена”. С ним просто. Это пустое поле. Т.к. цена индивидуальная и автор должен заполнять её в ручную. Уже при выходе можно делать диапазон цен, как это делают в интернет- магазинах, например.

И необходимо поле регион.

Например. Я создаю каталог фирм. Фирма - объект, к которому мне надо прикрутить поле “регион”. Где находится фирма? К какому региону, городу она относится?

Тут, я думаю, сделать это многоуровневым выпадающем списком.

Давайте посмотрим на такой список (у меня остался с 13 года) для региона.

Регион

Насколько актуально СНГ?

Первый уровень (берем только Россию) был выделен так:

  • Россия
  • Москва
  • Санкт-Петербург

Ок. Так думаю и оставить. Но идем глубже. Нажимаем на Россию.

Посмотрите на фото.

Центральный
Северо-Западный
Южный
Северо-Кавказский
Приволжский
Уральский
Сибирский
Дальневосточный
+ Общероссийские

С этим вроде понятно. Все правильно?

А вот с СНГ, не совсем ясно. Украина, например. СНГ раньше было удачно, как метка. И там было все. Теперь СНГ это:

Азербайджан	
Армения
Белоруссия
Казахстан
Киргизия
Молдавия
Таджикистан	
Узбекистан

Украину перенесем в Европу, ок.

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

P.S. интересно, как разные вещи влияют на программирование. Например, было большое обсуждение на одном форуме разработчиков с полем - пол. Ранее было просто. Муж., жен., скрыть. Потом (в Европе) появились новые. Трансы там и т.д. Что-то придумывают, а тут делать надо.

В сложных классификаторах, это же не просто пункт добавить. Поля связаны, к ним прикреплены еще другие свойства. В общем, надо аккуратно с этими полями… Кому свобода и самовыражение, а кому и работа. Голову ломать надо. )

4 симпатии

Такая форма подачи информации будет удобной?

Удобной, мы ничего лучшего не придумаем.

Единственные проблемы в таком списке - количество кликов. И мы не избежим большого ветвления на более глубинных уровнях. Города (далее) придется связывать в GEO локацией.

4 симпатии

Думаю, надо ещё посмотреть, что будет происходить с свойством объекта, если привязанное поле будет удалено. При изменение - переназначение, а физическое удаление. Надо проверить. Структура очень важна в самом начале.

4 симпатии

В обычных системах управления мы имеем жесткие структуры. Давайте назовем их Пространствами.

Например, Категории - это пространства, куда мы будем помещать товары, например. Мы создаем категории “в ручную”, это жесткая структура. Так везде, во многих CMS. А что, если нам надо будет создать группу категорий для России, США… и городов (по отдельности). И нужны будут категории по типу. Наши возможности достаточно ограничены будут. Ведь не будем же мы плодить категории.

А так и получится. Пример.

У нас есть сайт - Google. Он должен быть в каталоге США? Конечно. И он должен быть в каталоге для России. И это поисковая система, еще категории и т.д.

Выход в листинге, так делают. Через поиск. Мы просто фильтруем результаты по полям. Но это поиск.

Мы же хотим попробовать отказаться от жестких структур. Нет категорий с одной стороны, но они есть. Это сущности. Они могут быть любые: страны, типы товаров (сайтов), участники, группы, цена и т.д.

Они будут собираться в зависимости от условий и мы получим структуру, ту, которую нам надо. Добавим GEO локацию, и все.

Горизонтальные связи и вертикальные. Связи между группами и отдельных полей. Любые взаимодействия.

Мы будем формировать то, что хотим на лету.

В фото выше я специально вывел нулевые сущности, которые должны собраться в этом месте. Я из России и сборка “категорий” (которых нет) выглядит так.

“Категории” с нулевым содержанием выводиться не будут. Мы изначально будем получать “СВОЙ” каталог где будут использоваться определенные условия сборки.

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

4 симпатии

Пусть будет тут. Центральная страница:

И сборка одной рубрики (с теми метками, что прописаны).

Выглядит “жесткой”, статической структурой, с использованием категорий и с размещёнными там объектами. Но это не так. Нет категорий в принятом смысле. Страница создается из отдельных свойст. На данный момент общее количество свойств более 2000. Т.е. любой сайт, товар и т.д. может получить любое из 2000 описанных свойств.

5 симпатий