Всем привет!

Мне необходимо каким то образом хранить тарифы для интернет-провайдера (у них 3 основные характеристики - название, скорость и стоимость). Первая мысль была использовать справочник для их хранения.

Но у тарифа со временем могут изменяться характеристики. Поэтому я подумал, что логичнее будет использовать регистр сведений.

Товарищи рекомендовали использовать и справочник и регистр сведений, не аргументировав свой ответ.

Товарищи форумчане, подскажите как будет лучше организовать хранение тарифов?

РС

Название - в справочнике (то есть справочник "Тарифы")
А характеристики тарифа, особенно те, которые меняются во времени - в регистре.
На счёт скорости - это вопрос, так как скорость применяется только в данный момент (и в настройках оборудования) и её история не так важна.
А вот история стоимости важна, так как клиентам придётся давать детализацию, и к стоимости на определённую дату должен быть быстрый доступ.

Спасибо всем за ответы!

Torquader,

Хочу еще уточнить по поводу скорости. По идее скорость может быть использована

1. Для построения отчета "Прайс-лист"
2. Может использоваться программной прослойкой, ограничивающей канал пользователя.

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

Или я слишком мудрю?:)

(0)
нужна скорость записи и количество записей невелико - РС
не важна скорость записи и количество записей велико - С
в целом РС больше места для хранения занимает в базе

(2) если надо будет то срез сделает и в С только надо Период добавить
а тарифы да надо не наименованием хранить а ссылкой на справочник тарифов

(3) скорость лучше сделать отдельным от тарифа показателем
запросом завсегда можно будет собрать информацию по тарифу

(6) experimentator76, а почему лучше хранить отдельно? Я еще новичок в 1С и не сразу понимаю, почему тот или иной подход лучше другого.

(7) ты сам сказал что меняется скорость для тарифа
да и вообще неплохо иметь историю изменений характеристик для тарифа

вообще архитектура решения сильно зависит от того ЧТО В ИТОГЕ захотят иметь с этой информации
если не знаешь (а они и сами не знают) то надо по максимуму делать гибче\универсальнее
так как потом будет труднее переделывать

что именно использовать при реализации в (4)

(3) Во-первых, реально скоростью управлять будет не 1С (или вы хотите сделать "чудо").
Во-вторых, скорость важна только в данный момент, так как мало кому интересно, какая скорость была вчера.
Кроме того, если вы выбираете тариф (то есть элемент справочника), то скорость у вас уже будет (если она в справочнике).
А вот со стоимостью немного другое дело - текущую, конечно, тоже можно хранить в справочнике, но когда строится отчёт по какому-то клиенту, то будет интересовать скорость на конкретную дату (дату списания денежных средств) - и здесь важна быстрота, а что может быть быстрее регистра ?

Спасибо всем! Более или менее ясность пришла.

Только возник еще один сопутствующий вопрос. Для добавления и изменения тарифных планов я использую два документа. Рассмотри документ для добавления тарифного плана. У него есть 3 реквизита - наименование (название тарифа), скорость и цена.

При проведении документа наименование и цена попадает в регистр сведений. А вот возник вопрос - как правильнее будет добавить скорость в справочник?

(11) При проведении документа?

плин, при проведении документа какой на хрен справочник?

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

В таком случае я начинаю думать, что хранить там скорость не самая лучшая идея:)

периодический РС. Провайдер - измерение, скорость и стоимость - ресурсы

Вот как раз выше я пытался выяснить - будет ли лучше хранить скорость по тарифу в справочнике вместе с названием. Или запихнуть все характеристики в регистр.

(17) где-то выше было слово "периодический". явный РС, аргументации у меня нет

Спасибо. Буду пробовать вариант с РС. Скорее всего это и есть решение всех проблем:)

Хм, а тогда допустим такая ситуация.

В РС 2 ресурса - скорость и цена и 1 измерение - наименование (которое является ссылкой на справочник с названиями тарифов).

В справочнике еще нет наименования тарифа "Редкий" (как пример). Я через форму документа для добавления тарифа вбиваю информацию

Наименование = Редкий
Скорость = 5
Цена = 200

Информация о скорости и цене попадет в РС. А Наименование добавить не получится - так как нет соответствующей записи в справочнике. Что я делаю не верно?

(20) а тариф у тебя что? справочник?

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

Наименование тарифа храню в справочнике.

То есть справочник тут вообще не нужен?

(23) да, интересный вопрос, какого типа провайдер и тариф. я б сделал два справочника, тариф подчинённый провайдеру. по аналогии с контрагентами и договорами

Система создается для конкретного провайдера. Так что провайдера хранить не надо. Для конкретного провайдера нужно хранить его тарифы.

Тарифы характеризуются - названием, стоимостью и скоростью.

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

Вот исходя из этого пошла мысль создать

1. Справочник для хранения наименований тарифов
2. РС для хранения срезов стоимости и скорости тарифа поквартально

то есть тариф может не изменить название, но через квартал у него могут измениться характеристики

3.Два документа

 3.а для добавления нового тарифа
 3.б для изменения характеристик уже добавленного ранее тарифа

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

(26) читал по диагонали, потому что не вижу проблемы, всё очевидно. ладно, провайдер - "собственник" базы. справочник тарифы (это чтоб редактировать можно было просто), описанный уже РС, документы? я б сделал один - изменение состояния тарифа. который бы тупо писал в регистр то, что в документе. всё

(27) ну и в нужный момент оппа - срез последних по тарифу нам всё говорит

(26) кстати, да. чем добавление от изменения отличается? принципиально ничем. был NULL, меняем состояние на более определённое ;)

(27) то есть при такой схеме при добавлении нового тарифа придется сначала добавить наименование в справочник, а потом при помощи документа записать в регистр оставшиеся сведения?

(0) По-моему все очевидно Измерение - ТАРИФ (тип справочник тарифы, а не строка что б избежать проблем с пробелами и.т.д), ресурсы: СКОРОСТЬ и СТОИМОСТЬ.
Документ один для добавления и изменения.

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

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

(30) и не наименование ты добавляешь, а элемент справочника. пойми это, и всё станет ясно ;)

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

(35) вот ни разу не найду подтверждения своим мыслям, но,имхается мне, задача ТС - классический пример назначения РС

(35) А чем проще? Только один плюс - меньше новых объектов. А так РС запросом быстрее обрабатывать и СрезПоследних не надо изобретать.

> СрезПоследних не надо изобретать
вот он - аргумент за РС ;)