Добрый день.

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

Вводные данные: сайт на Битриксе, 1С 8 УТ для Украины, номенклатура ведется с использованием свойств. Придерживаемся принципа - чем меньше "допиливаем", тем лучше работает 1С. Стараемся вносить минимум изменений.

Пример. Книга с двумя авторами. Необходимо в свойство "Автор" записывать два значения "Иванов" и "Петров".

Варианты решения задачи:

1. Создать несколько свойств Автор.
2. Создавать несколько авторов в одном значении. Например "Иванов, Петров и Сидоров".
3. Доработать 1С.

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

PM.VIVAT @ Сегодня, 15:01 необходимо зарегистрироваться для просмотра ссылки ,
Я бы создал два реквезита: Автор1, Автор2

PM.VIVAT @ Сегодня, 15:01 необходимо зарегистрироваться для просмотра ссылки ,
1. Создать несколько свойств Автор. Это самый правильный вариант в плане меньше "допиливаем".

2. Создавать несколько авторов в одном значении. Например "Иванов, Петров и Сидоров".
Плодить по сути одинаковые свойства... имхо как-то не красиво.

PM.VIVAT @ Сегодня, 15:01 необходимо зарегистрироваться для просмотра ссылки ,
Если нужно будет делать отбор по Петрову отдельно от Иванова - однозначно 3. И не надо бояться доработки. Есть всего-лишь два состояния влияющие на автоматическое обновление - Включена/Отключена возможность редактирования. Обращайтесь к специалистам и смело дорабатывайте вашу программу таким образом, чтобы она максимально удовлетворяла потребностям вашего бизнеса.

Vlad 1C,

Обоснуйте. Я правильно вас понимаю, что в вариантах 1 и 2 отбор сделать не получится?

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

Хороший вариант. Но мы не знаем сколько таких свойств может понадобиться. Сегодня навскидку до 5 авторов. А завтра словарь, и там их 6-8 (со всеми соавторами).



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





Спасибо. Уточните плз., что значит Включена / Отключена возможность редактирования?

ПС: да, отбор желательно, что бы работал и я понял о чем вы говорите в случае, если будет несколько авторов как одно значение свойства.



Я понимаю, что можно смело доработать. Но так же смело потом можно получить массу конфликтов в будущем. Например с отчетностью в программе 1С и т.п. Я не против делать доработки, но столкнулся с проблемой на рынке услуг 1С, что каждый знает как сделать по своему здесь и сейчас. А к чему это приведет в дальнейшем и выбрать оптимальный вариант - мало кто может. По этому до того как доработать, нужно немного глубже понять как доработать, зачем и к чему это приведет в дальнейшем.

Вот может поможете разобрать в этом.





Нет, не просто на сайт выгрузить. Все действия от работы с заказами сайта до работы с отчетностью и т.п. будут вестись на стороне 1С.
В будущем можем использовать данные свойства при построении отчетов 1С, группировки, отборах.

Подчиненный справочник - Авторы.

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

Ну так для отбора - как раз. (Аналогично единицам измерения - классификатор+подчиненный справочник)

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

Если мы говорим про подчиненный справочник, то для каждой книги будет свой автор Иванов И. И. Как отобрать все книги, у которых в списке авторов есть Иванов И. И.?

Почему свой ? Писал же:
(Аналогично единицам измерения - классификатор+подчиненный справочник)

Именно так. И это очень частая ситуация.



В 1С это было текстовым полем? Не понял пока. Или вы доработали возможность выбора нескольких авторов из справочника, а при выборе более 1 - они имели разделитель точку с запятой ?!

И что являлось в данном случае первоисточником информации? Сайт или 1С все же?

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

Конечно, особенно если надо искать по автору.

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

Да никакого.
Регистр - недостаток только в юзабилити (для пользователя справочник привычнее)
Табличная часть - не индексирована (поэтому неоптимально).

Не пойму, какая разница. В обоих случаях нужно перейти в подчиненный объект (справочник или регистр), нажать там на + и добавить запись. Только в вашем варианте со справочником, нужно ещё в форме записи проваливаться в другой справочник и выбирать какое-то значение оттуда. Или я не прав? А если нужно сделать ещё удобнее, то можно напрограммировать, чтобы записи в подчиненный объект добавлялись прямо в форме основного справочника.


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

Зачем, если в справочнике индексирование идет по-умолчанию.




А вот СКЛ сервер считает по-другому и строит план выполнения исходя из присутствующих индексов.


В любом случае надо. Поэтому практически никакой разницы между регистром и справочником.

Ещё раз
Зная вас не первый день (заочно, по форуму) у меня сейчас впечатление, что кто-то стырил ваш пароль и пишет за вас. То, что от индексов зависит скорость выполнения запросов, это да. Но разве запрос без индексов не может выполняться за приемлемое время? Если следовать вашей логике, то индексы должны быть везде. Но почему-то это не так.

Может, особенно на "пробных базах". А теперь возьмем базу книг эдак на тыщ 200-500 и сунем в нее запрос с отбором по автору.
Поиск по индексу займет доли секунд, а сканирование таблицы - хз.
Там, где таблица заведомо небольшая - согласен - индексы могут быть вредны.

И? Пускай будет вместо 0.1 секуды 0.5 или пусть даже 1. Это сильно большая проблема? Кроме того, не забываем о том, что мы сейчас говорим про справочник, т.е. по своей природе это часто не тот объект, к которому постоянно и отовсюду будут выполняться запросы.


То то и оно, что хз. Это хз может быть незаметно для пользователя, если даже в реале эта разница будет раз в 10 (0.1 секукнды и 1)

Поэтому делать рагульную архитектуру с транзитным бесполезным (подчиненным) справочником всего лишь из-за того, что там есть индекс по умолчанию, это не очень хорошая плохая идея. Это исключительно мое мнение.

Исходя из такой логики:
- зачем строить "рагульные" развязки на дорогах и подземные переходы - машина все-равно доедет до цели;
- зачем поводить гигабитную оптику - ведь и по 50 к "меди" страница когда-то загрузится; и т.д.
О масштабируемости системы надо все-равно помнить.

При том не забывайте, что мы оптимизируем не время ожидания пользователя, а нагрузку на "движок".
И если СКД сервер с блокировкой записей многое "простит", то файловая база или "слоны" могут блокирнуть работу
(согласен - не в этом случае, но при таком подходе).

По конкретной реализации - я просто выразил свое мнение. Поэтому останемся при своих.

Спасибо за информацию всем.

Некоторые выводы сделал. Если у кого-то будут еще варианты, мысли - пишите.