Версия для печати темы (https://pro1c.org.ua/index.php?s=51bca61ef4837a99e5bf0ed903b8a648&showtopic=34322)

Автор: PM.VIVAT 03.01.17, 15:01

Добрый день.

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

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

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

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

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

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

Автор: cos12 03.01.17, 15:31

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

Автор: podcast 03.01.17, 16:16

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

Автор: Flexy 03.01.17, 16:32

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

Автор: Vlad 1C 03.01.17, 22:38

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

Автор: Vofka 04.01.17, 9:48

Vlad 1C,

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

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

Автор: PM.VIVAT 04.01.17, 10:33

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



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





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

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



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

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





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

Автор: sava1 04.01.17, 12:36

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

Автор: Vofka 04.01.17, 13:37

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

Автор: sava1 04.01.17, 15:22

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

Автор: logist 04.01.17, 19:02

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

Автор: Vofka 05.01.17, 10:15

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

Автор: sava1 05.01.17, 10:19

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

Автор: PM.VIVAT 05.01.17, 11:02

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



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

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

Автор: Vofka 05.01.17, 14:29

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

Автор: sava1 05.01.17, 16:07

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

Автор: Vofka 05.01.17, 16:11

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

Автор: sava1 05.01.17, 16:27

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

Автор: Vofka 05.01.17, 17:12

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


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

Автор: sava1 05.01.17, 17:30

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




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


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

Автор: Vofka 05.01.17, 17:48

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

Автор: sava1 05.01.17, 18:00

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

Автор: Vofka 06.01.17, 9:48

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


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

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

Автор: sava1 06.01.17, 11:47

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

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

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

Автор: PM.VIVAT 11.01.17, 12:19

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

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