про игры)

это кто?

О_О

Катя, она контент менеджером была. ты с ней точно общался

помню

вы уже тогда женаты были?

или это недавнее событие?

тогда еще нет. в прошлом году женились)

поздравляю! =)

спасибо)

что-то подумал тут, зайду на СЭ и поищу битрикс там. Как бы не так http://stackexchange.com/sites

есть все топовые cms, а битрикса нет. Но нас же уверяют, что на российском рынке он доминирует. Сколько там процентов? 40 с чем-то?

http://rus.stackexchange.com/tags Где здесь хоть одна из CMS ?

В русском сегменте 10000 вопросов в 1000 раз меньше чем в общем.

http://rus.stackexchange.com/ ресурс для изучающих русский язык. Никаких cms там в принципе быть не должно

ладно, у этого вопроса не будет ответа. Но все равно хочется иметь качественный ресурс. Формы должны были выпилиться в 2000х. Я удивлен, что они до сих пор живы

а как вы делаете выборку из нескольких инфоблоков? Например джойном.

Сцепить со свойствами архитектурно невозможно

Связанные элементы только если...

Но вот одно не могу понять -зачем? )

что зачем? Зачем многоуровневые структуры?

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

Вчастности так ранее с цветами к товару было

Но на мой взгляд все равно строить справочники гораздо практичнее

справочники в контекте битрикса это что?

Но вообще джоин в классическом понимании, с учетом свойств -попросту не возможны. Хотябы из за разных типов

справочники в контекте битрикса это что?

Не. Малые запросы, сбор массивов-справочников, и связь уже перед показом.

ладно, предположим у нас есть такое. Страна -> Область -> Город -> Улица. У каждого свои свойства. Как правильнее такое реализовывать в битриксе?

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

Боль конечно, но по факту именно так.

Ну или чистый sql, но я тебе этого не говорил?

я не понимаю. Разве нельзя просто создать Entity, описать связи, забиндить таблицы и все. Поверх схем сгенерировать формы, поправить их и все, готово. Ну валидаторы еще навешать

Ты не забыл что допустим на инфоблоки две схемы могут быть?

э?

Схемы хранения свойств. Инфоблоки и инфоблоки 2

Если тебе нужна плоская таблица - хайлоад инфоблоки используй, и будет тебе счастье, там это возможно.

я просто хочу хранить структуру, описанную выше

Но это минус универсальность, минус безопасность, минус поддержка. Зато просто и понятно -реальные таблицы, понятная структура

Зачем ты хочешь их хранить и как использовать? Может с этого тогда начнем?

Для города чем специализированный от сейл -местоположения не угодили?

я буду запрашивать довольно большой набор данных. Он многоуровневый. На каждой уровне свои свойства. Допустим, я нахожусь в корне. Мне нужно собрать агрегированные данные из уровней ниже и отразить их для каждого элемента из корня

Страна-область-город-улица Вопрос лишь потянет ли с глубиной до улицы. Думаю врят ли. Их я или в свои таблицы или в хайлоад пихнул

я буду запрашивать довольно большой набор данных. Он многоуровневый. На каждой уровне свои свойства. Допустим, я нахожусь в корне. Мне нужно собрать агрегированные данные из уровней ниже и отразить их для каждого элемента из корня

Не смог за общими словами понять пример

Хм

Ну это звучит как -я просто хочу обычный сайт, сколько стоит? )

Мы все загружаем данные и выводим их)

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

Не смог за общими словами понять пример

Легковые авто [свойства: описание, изображение, пр.] -- Мазда [свойства: название, тип] -- -- Модель [свойства: ...] -- -- -- ДВС [свойства: ...] -- ВАЗ Грузовые авто -- Камаз -- Сканиа Пассажирские авто -- Джамшутка

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

а? Насколько все плохо?

вопрос другой... зачем вам при таких структурах данных Битрикс?

По моим оценкам от 200-300к элементов на все инфоблоки (таблица общая) уже начинаются пляски с бубном.

ну это ... вы же топором гвозди можете забивать но зачем когда можно взять молоток

Инфоблоки -универсальная структура, а не замена мозга и таблиц бд

Если данных больше - то или хайлоад инфоблоки, или свои таблицы

Легковые авто [свойства: описание, изображение, пр.] -- Мазда [свойства: название, тип] -- -- Модель [свойства: ...] -- -- -- ДВС [свойства: ...] -- ВАЗ Грузовые авто -- Камаз -- Сканиа Пассажирские авто -- Джамшутка

Магазин запчастей чтоли?

не магазин, просто справочник обновляемый

это просто синтетический пример

Если данных много, или клиентов на эти данные-много -нужна конкретика

я знаю, как бы я сделал на фреймворке. Просто накидал бы entity, описал бы связи, сгенерил формы и все. Работы на день, если не меньше

Просто прыжок улиц до авто... Выглядит немного странным

Просто прыжок улиц до авто... Выглядит немного странным

не зацикливайся на наименованиях. Это не имеет значения

Имеют объемы. Нет ни одного орм который нормально работал бы на объемах и адекватно джоинил. Всегда надо руками ключи докидывать. Что-то разбирать на мелкие запросы. Либо вообще руками запрос к бд писать на голом скл

Если интересует схема - отдельные таблицы и д7 орм. Но придется забыть о инфоблоках, т.к. это про другое

ок, я понял, что инфоблоки это плохая идея

Эти таблицы могут быть проведены как хайлоад и у тебя там вылезут даже с формами

ок, я понял, что инфоблоки это плохая идея

Если специализированные данные-то да, плохая

тогда нужно описаывать Entity\DataManager. Но как быть с формами?

Но вообще задачу смотреть надо, а потом обсуждать, каких то универсальных советов которые пойдут на все случаи жизни -не бывает.

тогда нужно описаывать Entity\DataManager. Но как быть с формами?

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

ох

спасибо за терпение

кстати

не отходя от темы

слышал как-то в докладах Битрикса про функционал Админок

именно так и называется

не просвятите?

А что ожидал -все есть инфоблок? Так у битрикс форум, города, цены, склады -не инфоблоки )

слышал как-то в докладах Битрикса про функционал Админок

Не понимаю вопроса. Возможно не слышал доклад

админку вообще муторно делать?

Рыжиков как-то в докладах 2016 года что-то говорил про кастомные админки на базе Битрикса...

админку вообще муторно делать?

Вообще ппц. Полный хардкор. От вендора лишь несколько классов (надо смотреть по примерам) чтобы нативно выглядело. Разграничение по табам. И вообщем все

Вообще ппц. Полный хардкор. От вендора лишь несколько классов (надо смотреть по примерам) чтобы нативно выглядело. Разграничение по табам. И вообщем все

ты меня разыгрываешь?

ты меня разыгрываешь?

Посмотри сам

http://dev.1c-bitrix.ru/api_help/main/general/admin.section/index.php

Посмотри сам

например это? http://dev.1c-bitrix.ru/api_help/main/general/admin.section/rubric_admin.php

ты меня разыгрываешь?

В меню вклиниться, или еще что -это просто. Но сама форма -придется вспомнить пхп основы) Как в старые добрые времена, практически

Списки кстати - там да, таблицу собрать просто. Я что-то сразу на редактирование прыгнул)

Рыжиков как-то в докладах 2016 года что-то говорил про кастомные админки на базе Битрикса...

Если есть возможность -кинь доклад, или где это упоминалось. Никаких подвижек я что-то не видел, может правда чего то пропустил

Списки кстати - там да, таблицу собрать просто. Я что-то сразу на редактирование прыгнул)

http://dev.1c-bitrix.ru/api_help/main/general/admin.section/rubric_edit.php

мда

http://dev.1c-bitrix.ru/api_help/main/general/admin.section/rubric_edit.php

Ага, лучше сразу реализацию посмотри. Более менее причесано admin/iblockelement_edit.php. ну или как то так)

Сейчас не за компьютером, чтобы точно сказать