Есть задачка по доработке базы по учету оказания услуг населению. В базу будут заведены порядка 100 тыс лицевых счетов. Пользователей будет где-то 50 чел. При этом у каждой группы пользователей будут свои уровни доступа к лицевым счетам,например, пользователь одного населенного пункта не должен видеть лицевые счета другого населенного пункта.
Как думаете взлетит ли подобная задача на 1с?

легко

> 100 тыс лицевых счетов

жку ?

эммм а где тут большая база ???? 100тыс эл справочника - это ни о чем....
50 пользователей - это то же ни о чем....

разумеется база должна быть клиент серверная, а не файловая.

(0) По доработке какой базы? Это ЖКХ? Ну учет расчета коммунальных услуг?
Думаю надо писать самописку, используя БСП и оглядываясь на типовые.

(2)Да. Просто попробовал сделать простой отбор по закрытым лицевым счетам в справочнике лицевых счетов.Сделал так:
Процедура ПриОткрытии()
    ЭтаФорма.ЭлементыФормы.СправочникСписок.Значение.Отбор.ЗакрытыйЛС.Значение=Ложь;
    ЭтаФорма.ЭлементыФормы.СправочникСписок.Значение.Отбор.ЗакрытыйЛС.Использование=Истина;
    ЭтаФорма.ЭлементыФормы.СправочникСписок.НастройкаОтбора.ЗакрытыйЛС.Доступность = Истина;
КонецПроцедуры
При первом открытии этого справочника при количестве лиц. счетов 20 тыс справочник открывался 40 сек. Это достаточно долго. А что же будет при 100 тыс. Правда еще не тестировал как это будет на SQL сервере.

(5) УФ + РУ

(5) ЗакрытыйЛС - индексирован?

(5) используй RLS и будет тебе счастье

(7) Да индексирован.
(8) вы предлагаете вместо стандартных отборов использовать RLS? Здесь я привел лишь простейший пример, при котором при открытии справочника не отображаются закрытые лицевые счета, но пользователь при желании всегда может вывести и закрытые счета. Интересно тогда, а почему в тех же типовых не используется RLS для вывода отбора по организации,там используется подобный код, который у меня приведен в (5).

(9) Ответ на поверхности.
RLS это, образно выражаясь, "жесткое" разграничение, которое как ты помнишь задается где? - в конфигураторе!. А отбором достаточно легко и просто рулить при работе непосредственно в базе.
О минусах RLS можешь почитать в "интернет"

(5) Сам подход использования закрытых лицевых в справочнике не верен. Не думайте по семероному (Как в клющках). Юзайте РС!

Не стоит доработку делать в типовых.  Ищите подходящую отраслевку. Если нет то уж надо писать на 1с8.3 самописку.

(9)РЛС конечно же
и в типовых почти во всех РЛС используется, только при не правильном использовании сего механизьма возможны жуткие тормаза

Сначала курс Эксперт по технологическим вопросам.
А то будет тормозить, и это кривая 1С типа.

"по доработке базы по учету оказания услуг населению"

Что за база? режим управления блокировками в базе?

Ладно, ответы не интересуют.
Дописать можно, но РЛС, неоптимальные запросы, взаимоблокировки при параллельной работе могут немного
местами мешать.

(0) Легко, но на хороших серверах )

(0) Что за база? ЖКХ?

(0)RLS будете использовать для разграничения или через РС механизм разграничения доступа?

автор наверное хотел сказать "большой файловой базы"...

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

Большое спасибо за советы, буду разбираться. Не первый год программирую в 1с 8, но вот такого уровня базу еще не делал, поэтому и хочется грамотно подойти к решению задачи. Текущая конфигурация уже работоспособна, но она работает только для одного участка без всяких отборов по доступу, а нужно будет сделать общую базу для нескольких абонентских участков, находящихся в разных городах одного региона.
Любопытен совет про 1с 8.3 , если честно со многие новшествами 1с еще не разбирался, времени совсем нет, работы и так хватает, с теми же типовыми, вот недавно активно изучал и участвовал во внедрении конфигурации УПП. Пока полет нормальный.
Интересно, а что в 1с 8.3 есть такого,что существенно облегчило бы мне решение задачи?

(22) про разделитель учета почитай

(23) Автор не делится предметкой, могли еще чем помочь.

(24) учет доставки газовых баллонов населению и юридичиским лицам.

(25) ВГО?

у меня на скуле 1с8 самописка с 2,6 млн номенклатуры, с 2-3 пользователями при обработке автозагрузки заявок уже было некомфортно работать. но была особенность - поиск по артикулам по подстроке. если по точному соответствию - то 5-10 минут на поиск 300 позиций уходит. это так, для справки...

(24) хотя с предметкой вряд ли поможите, т.к. готовая вещь особо не интересует, ну если только для общего развития,чтобы позаимствовать идеи. Как выше я уже писал,что программа есть, ее лишь нужно доработать, многие вещи придется перписать полностью, т.к. многие запросы очень не оптимальны и предполагаю, на большом количестве данных и пользователей, будут существенно тупить.
(26)ИГБУ

(25) а баллоны маркированные?

(29) номера баллонов есть,но не маркированные. Пока складского учета баллонов нет. В дальнейшем планируется доработка с использованием штрихкодов для идентификации баллонов, пока работают по старинке.

Хоть бы написал на чем написан. 1с8.1 ли 1с8.2 ли?
УФ или не УФ?

(31) 1с 8.2, обычные формы

(32) Переводи на УФ. на 1С8.3 много вкусностей. Но самое главное с УФ и работа с сервером там улучшено.
Для твое задачи это очень важно.
Тебе нужно мощные серваки и клиент-серверная база.
Про файловую даже не думай.

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

(34) Ну кроме 100 тыс лиц. счетов, будут ежедневные заявки от контрагентов, которые будут принимать абонентские отделы разных городов. А затем, на основании этих заявок будут формироваться ведомости доставки для водителей с разделением по маршрутам. Кроме доставки баллонов, ведется  еще техническое обслуживание газового оборудования. Так что данных не мало будет.
Доступ будут давать администратор базы, который заведет пользователя с привязкой к соответствующему абонентскому отделу. Этот пользователь должен будет иметь доступ к лицевым счетам и документам, только своего абонентского отдела.

(35) Как вариант. РИБ. Каждая периферия видит свое а ЦБ видит все.
в ПБ данных будет меньше.

У меня сходный вопрос. База на 50 тыс. клиентов. В месяц 30тысяч отгрузок. Проблема в том, что хотят видеть движения по контрагентам в БП. Взлетит ли такой объем в БП?

(37) и нафига он в БП?

Стандартный нагрузочный тест по отгрузкам есть в КИПе (точно по УПП, может и БП подойдет).

Раз париться не надо с тестом, на твой вопрос ТОЧНО ответит тестирование.

Вернее не точно, но в сферических пользователях )))

думается мне что БП 3.0, если там блокировки описаны без косяков лучше отработает.

(41) 3.0 очень хреново работает с диском где установка сервера сделана.

Очень сильные затыки идут на ЖР, программном кеше и темпах,

если 2.0 вполне нормально работала при установки на средний диск, то 3.0 просто тупит.

тут варианты
1. отказывается от ЖР
2. ставить под систему навороченный 10 рейд
3. ставить 8.3 последнюю, вроде там проблемы с ЖР порешали

(14) Ilpar порекомендовал курс: "Эксперт по технологическим вопросам". К сожалению, курсы сейчас пройти возможности нет, а вот литературу почитал бы по этому курсу. Может кто посоветует что лучше прочесть.

(43) Вот нашел типовой материал в виде базы знаний по блокировкам: http://kb.1c.ru

(44) этого, в общем-то, достаточно на первых порах

(0)
взлетит, можно не сомневаться.
сначала попробовать на РЛС, если будет критично тупить - сделать РИБ. Хотя вряд ли будет.

А вариант "Web-сервис" и сайт, где "работают" пользователи не рассматривается ?
Если пользователь принимает заявки по телефону, то он должен иметь интерфейс, где он сможет найти контрагента по номеру, который тот продиктует - смысла вообще показывать журнал нет.
Если мы формируем доставку, то выполняется запрос, который отбирает заказанное и оплаченное - если написать через Web, то водитель на экране навигатора сможет посмотреть.
Далее, для конечных пользователей можно сделать портал, где они могут заказать, выписать счёт на оплату и согласовать день доставки после оплаты.

Почему нет ?

(0) если объем справочников достаточно постоянный и добавление элементов происходит реже 1 часа, то вполне достаточно построить контрольные примеры с интерфейсами, использующими данный справочник и провести нагрузочное тестирование в различных вариантах, для отборов с прогнозируемыми значения можно хранить "предварительно" сохраненные результаты