1С Предприятие 8.2 обычное приложение, обычная форма Конфигурация "Управление торговым предприятием для Украины", редакция 1.2.
День добрый!
Уважаемые, подскажите как будет правильно реализовать: Есть периодический регистр сведений куда будет писаться инфа о маркировке произведенной продукции. Структура регистра следующая: Период - стандартный реквизит; Код - 13 значный код для внутренней стикеровки выпускаемой продукции; Носенклатура - СправочникСсылка.Номенклатура Ответственный - СправочникСсылка.ФизическиеЛица ( человек который будет клеить стикеры); Сотрудники - СправочникСсылка.ФизическиеЛица (несколько человек который сделали продукцию, смена)
Так вот получается что "Сотрудников" всегда будет от 2-х до 5-ти, и писать нужно данные о всей бригаде. Дума что писать несколько строк в регистр на каждого сотрудника с одними и теми же данными не есть правильно. Что посоветуете??
Группа: Местный
Сообщений: 858
Из: Місто щасливих людей
Спасибо сказали: 327 раз
Рейтинг: 0
Если, как правило, в качестве сотрудника всегда идет несколько человек (смена) может есть смысл задуматься о создании справочника Смены с таб. частью Сотрудники, где можно перечислить всех сотрудников данной смены? И вместо ссылки на справочник сотрудники взять справочник смены
Дописываю конфигурации на платформе 8.х. - Управление торговым предприятием для Украины - Управление производственным предприятием для Украины - Управление небольшой фирмой для Украины - Бухгалтерия для Украины; - Общепит для Украины - Ресторан (Рарус) - Розница
Если, как правило, в качестве сотрудника всегда идет несколько человек (смена) может есть смысл задуматься о создании справочника Смены с таб. частью Сотрудники, где можно перечислить всех сотрудников данной смены? И вместо ссылки на справочник сотрудники взять справочник смены
Спасибо за ответ! Я в принципе так и думал, но есть несколько "НО" 1-е "НО" - смены не стабильны, текучка на производстве огромная, и даже смена которая ходит по графику, за частую постоянно меняется, т.е. есть 30 человек в одну смену и есть 7 станков состав которых чуть ли не каждый раз разный, так вот мне надо писать именно состав этого станка в регистр. И соответственно хранить эти данные хотя бы год-два.
Из этого имею 2-е "Но" может тогда более рационально писать 2-4 лишних строки в регистр чем писать каждый день 5-7 новых значений в справочник?
В общем если кому интересно. Провел я следующий эксперимент:
Взял обработку v8tablesizes и смоделировал ситуацию заполнения максимального количества записей на один день по трём предложенным моделям:
1) Регистр сведений с реквизитом типа СправочникСсылка.СоставСмен (Справочник.СоставСмен имеет Табл. часть с реквизитом типа СправочникСсылка.ФизЛица) т.е. выходит что за день максимум может быть записано 60 строк в регистр и 8 записей в справочник;
2) Регистр сведений с четырмя идентичными реквизитами типа СправочникСсылка.ФизЛица те же 60 записей в регистре но сам регистр будет "шире" на 3 столбца
3) для каждого Физ.Лица пишем отдельную строку в регистре итого максимум 240 записей за день
Что в итоге получилось:
Размеры с данными на 1 день: 1) 58 074 б. (регистр) + 73 292 б. (справочник) =131 366 б. 2)133 762 б. (регистр с 4 физ.лицами) 3) 1 000 332 б. (регистр с 1 физ. лиц. но с записями для каждого сотрудника со смены, 240 записей)
Размеры с данными на 2 день: 1) 123 858 б. (регистр) + 76 652 б. (справочник) =200 510 б. 2)166 530 б. (регистр с 4 физ.лицами) 3) 1 180 556 б. (регистр с 1 физ. лиц. но с записями для каждого сотрудника со смены, 240 записей)
Результат прироста: 1)69 144 б. 2)32 768 б. 3)180 556 б.
Ка видим, Вариант 3 со схемой "на каждое физ. лицо 1 строка в регистре" можно отбросить, т. как прирост в день будет существенно выше. да и записей в регистре 240 против 60 не в его пользу.
Далее рассматриваю варианты 1 и 2. Прирост базы при варианте 1 будет примерно 23,7 Мб в год. А прирост по варианту 2 примерно 11,25 Мб в год. Актуальность данных не более 2-х лет, поэтому разницу в 12 Мб можно считать не критичной и перенести выбор варианта реализации в плоскость "удобство реализации и последующей работы".
Оценив все "За" и "Против" было решено остановиться на варианте 1 (со справочником смен) т.как в дальнейшем этой смене нужно будет "прикручивать" зарплату от выработки, а так же заглядывая на перёд, в планах есть создание рабочего места "кадровика" который будет планировать эти смены и контролировать посещения, но это уже, как говориться, совсем другая история.....
Группа: Пользователи
Сообщений: 9
Спасибо сказали: 0 раз
Рейтинг: 0
Yevhenii @ 30.03.17, 10:21
, А каким документом планируется заполнение регистра, учитывая
Цитата
"Оценив все "За" и "Против" было решено остановиться на варианте 1 (со справочником смен) т.к. в дальнейшем этой смене нужно будет "прикручивать" зарплату от выработки, а так же заглядывая на перёд, в планах есть создание рабочего места "кадровика" который будет планировать эти смены и контролировать посещения, но это уже, как говориться, совсем другая история....."
Группа: Команда
Сообщений: 3568
Из: Киев
Спасибо сказали: 1434 раз
Рейтинг: 0
Делать вывод на основании размера таблиц не совсем корректно. Вы оценивайте на основании того как Вам нужно получать данные для Ваших алгоритмов. Чисто для примера рассуждаю варианты 1 и 2: Вариант №1. Для получения информации нужно будет соединять две таблицы и потом высчитывать какие-то показатели с учетом того что состав смен постоянно меняется. Вариант №2. Все данные по сотрудникам находятся в одной таблице, берете её и вычисляете показатели. В первом варианте затраты на получение данных будут выше чем во втором.
1С Предприятие 8.3, 1С Предприятие 8.2, 1С Предприятие 8.1, 1С Предприятие 8.0, 1С Предприятие 7.7, Литература 1С, Общие вопросы по администрированию 1С, Методическая поддержка 1С - всё в одном месте: на Украинском 1С форуме!