<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Даже представить не могу, чтобы мне для таких целей регистра сведений не хватило. Хех, я уж про константу — строку неограниченной длины даже молчу =))
(1) Ну, я сам долго с регистром жил. Решающим для перехода для меня стало жгучее желание как-то всё это безобразие группировать. А про строку неограниченной длины — разные случаи бывают. Гимн компании, например, хранить ))
Использую подобный механизм, но у меня еще есть возврат группы констант.
ПолучитьЗначениеКонстанты(«ГруппыНоменклатуры») вернет массив значений.
(3) О, вариант. Не могу, правда, придумать, зачем бы оно, но надо будет добавить.
В какой-то из отраслевых видел подобный механизм, реализованный на ПВХ )
(0) Я встречал реализацию такого механизма практически всегда на двух объектах — ПВХ и РС, и в своей конфе собственно именно такой же подход использую
(6)
(5) Думал тоже через ПВХ сделать. Но это два объекта, а не один плюс настройка несколько сложнее. А каких-то явных преимуществ реализации через виды характеристик я не нашел. Если не прав, подскажите.
(7)
Количество объектов при правильно сделанной обвязке особого влияния на процесс кодирования не окажет — все равно вы будете писать что-то типа «УстановиКонстанту(Наименование, Значение)».
Плюс, собственно, в том, что в регистре будет храниться индивидуально типизированное значение — то есть, ожидая в коде увидеть СправочникСсылка, вы не получите там строку али еще чего.
А если константа периодическая ?
(9) Периодическая константа — несколько оксюморон, не находите? ) Пока не встречались мне в практике. Был бы благодарен за пример.
(8) Если конфигурация своя, то да, а если клиенту встроить куда-нибудь, то чем меньше объектов тем лучше. Низкая связанность же ) Про жестко типизированное значение я думал (даже дополнительный параметр в сеттер ввел), но пока желание простоты и компактности во мне возобладало.
(10) Да пожалуйста , процент по кредиту или займу в середине месяца изменилась ставка рефинансирования из=-за этого изменился процент , сам процент хранится как константа, проценты начисляются в конце месяца , и часть месяца должна посчитаться по старой ставке а часть по новой
(11)
На самом деле клиенту пофиг, сколько там объектов вы добавите — 1 или 2. Важно, насколько дороже станут обновления )
(10) Имеется в виду уже более не константа, а некая условно постоянная информация, допустим используемая для подстановки в печатные формы документов — до 2018 года выводилось одно значение, начиная с 2018 года необходимо выводить другое.
Подобный же механизм (на основе ПВХ и РС) используется также и в старых редакциях типовых конфигураций для дополинтельных настроек пользователей (в основном для подстановки в объекты значений по умолчанию) и дополнительных прав пользователей
(13) Это безусловно так — клиент не заметит даже если искать по наименованию ) Но я предпочитаю чтобы склонный к насилию психопат, знающий, где я живу, который будет сопровождать его после меня, разбирался с одним моим справочником, а не ПВХ, регистром, справочником (для допзначений — как в механизме свойств) и парой общих модулей )
(12)
(14) Хмм. Сходу ответил бы, что таким вещам место в специально отведенных для этого регистрах, но вы заставили задуматься, спасибо.
(0) у меня подобное сделано как
справочник (предопределенные элементы) + планвидовхарактеристик
(17) С предопределенными элементами беда в том, что добавлять/изменять их через изменение конфигурации надо. А хочется чтобы можно было на лету с ними работать.
(18)
во вторых — динамически использовать константу это как ? через внешние обработки ?
во первых — для 8.3 вроде как не актуально
зы. не считайте придирками , все что повышает удобство работы имеет право на жизнь , к слову нечто подобное (варииант с хранилищем) тоже использую , только для других целей
(19) Во-вторых, почему бы и не так ) Надо мне, например, как-то печатной формой управлять. Добавляю константу, пилю внешнюю печатную форму, конфигурацию не трогаю. Или роботами разными управлять, которые тоже по сути — внешние обработки, которые по регламенту запускаются.
Во-первых, это да. Но не у всех, к сожалению, до сих пор 8.3 и это боль.
Никаких придирок, конструктивная критика — наше всё )
Нууу, не знаю даже. Эдакая свалка ленивых предопределенных элементов со всей конфы получается. При этом конфа без справочника становится неработоспособной. Слабый аргумент, но метаданные (по сути) вынесенные в данные — все равно не сахар.
Я обычно так делаю, если понадобилось найти по коду прям срочно:
1) делаю через поиск по коду, но сразу забрасываю в хранилище на будущее структурное изменение предопределенный элемент
2) потом как структурные зальются — перебрасываю «ИмяПредопределенного» на существующий элемент, а новый убиваю
3) рефакторю поиск по коду на обращение к предопределенному элементу.
(21)
это, я так понял , в мой огород камень 🙂 ,
в справочнике естественно есть защита от «дурака» , но так сделано было больше для
того чтобы иметь таблицы в запросах
для всякой быстрой фигни и регламентов использую (не сочтите рекламой)
(21) Это образец отличной дисциплины и вообще правильное решение ) Для ссылок. И для своей конфы. А создавать кучу предопределенных элементов в базах клиентов, если, например, распространяешь свое решение и тебе надо хранить его настройки, не очень удобно. Ну, и в таком варианте можно хранить вообще все что угодно, а не только то, что можно сделать предопределенным элементом. Но вообще да — тенденция превратить это хранилище в свалку наблюдается и с ней надо бороться. Но это уже на совести разработчика )
(23) Ну, разговор же был про поиск по коду. Понятно, что константы могут этим не ограничиваться.
Если распространяешь свою подсистему, то инкапсулировать служебные ссылки в отдельном объекте метаданных конечно удобно.
Но что мешает сделать в том же служебном справочнике для констант своей подсистемы предопределенные элементы? 🙂
(24) На самом деле не только поиск по коду — даты, числа, строки сплошь и рядом определяются в коде — отсрочки, минимальные/максимальные суммы, проценты, время завершения проведения документов или работы пользователей, куча всего.
А, в смысле, предопределенный элемент справочника констант, в котором будет содержаться изменяемое значение. Это да, хорошая идея для распространяемых подсистем )
(22) Это камень в огород всех подобных хранилищ. Убираешь хранилище — конфигурация ломается в тех местах, где было обращение к хранилищу. Поэтому коллега выступает за максимальное предопределение элементов.
(24) А, ну и еще аргумент против предопределенных элементов — если мне конкретно нужна определенная папка с определенной номенклатурой то да, предопределенный элемент — то, что надо. А если мне, например, нужна папка с номенклатурой, на которую не должны распространяться никакие скидки при продаже (дурацкий, конечно, пример, но тем не менее). Мне сказали, что это вот эта конкретная папка. Я предопределил элемент, прописал везде, где надо исключения и все заработало. А через месяц мне сказали, что теперь это не эта папка, а другая. Согласитесь, перебрасывать «ИмяПредопределенного» на новую папку в таких случаях — не лучшее решение. Или придется предопределять и новую папку и переписывать все места, где есть обращения к той. А в такого рода хранилищах можно просто перевыбрать значение специально выделенной константы.
(26) тогда неправильно понял , я то как раз из этих соображений не стал связываться с хранилищем данных и предпочел справочник
(27) Вы привели либо пример ошибки проектирования (когда надо было использовать атрибут), либо пример классической константы. Естественно, предопределенные элементы — не замена констант. Мы это уже затрагивали выше. Соответственно нужно либо добавлять классическую константу, либо если уже «скидывать» свои константы в отдельный справочник, то элементы этого справочника должны быть предопределенными (а в них уже ссылки на пользовательские объекты). Я думал, мы это уже обсудили и достигли консенсуса.
Для подобных случаев в типовых конфигурациях я использую процедуры «ХранилищеОбщихНастроекСохранить» и «ХранилищеОбщихНастроекЗагрузить» общего модуля «ОбщегоНазначения»:
Показать
Зачастую также бывает полезно устанавливать для управляемой формы свойство «АвтоматическоеСохранениеДанныхВНастройках», после чего
отметить галочками поле «Сохранение» у соответствующих реквизитов формы.
(29) Прошу прощения, я немного сам с собой подискутировал на самом деле. Я, просто, сначала решил, что основная причина, почему предопределенными элементами не обойтись — то, что часто сохраняемые данные — не ссылки, а что-то другое, а потом вспомнил, что и для ссылок тоже есть случаи, когда предопределенных элементов не хватит. Но да — консенсус достигнут )
(30) Я в принципе целиком поддерживаю мысль хранить настройки форм в хранилищах настроек — это как раз пример того, что не стоит тянуть в справочник констант, так как для этого есть специальное удобное место ) Но с другой стороны, совать в хранилище настроек что-то помимо настроек мне кажется не лучшей идеей, хотя технически это и реализуемо. Как минимум, не получится без проблем по быстрому изменить какие-то значения.
(30)(32) У хранилищ настроек есть большой минус — к ним нельзя обратится напрямую из запроса.
еще думал про вариант с быстрыми константами , который можно использовать в.т.ч в запросах :
есть справочник (константы) имеющий 3 реквизита (тип ПВХ) и табличную часть (характеристики )
в состав ПВХ включаем этот справочник , создаем в нем несколько предопределенных элементов к1,к2,к3,к4.. кn
тогда в тч справочника например из 3 колонок (кi,кj , КакаяТоКонстанта) получим количество размещений из кi,кj = n в квдрате , различных констант
на каринках — примерно то как это могло бы выглядеть ( колонки кi,кj — константа1 константа2)
зы. но это так , фантазии , сам не пользуюсь ))
(34) Что-то запутался, честно говоря ) А в запросах и мой вариант можно использовать: в запросе к табличной части справочника констант «ГДЕ Ссылка.Наименование = «ИмяГруппыКонстант» И ИмяКонстанты = «ИмяКонстанты»» и все. Хотя, чаще всего проще параметром передать )
(35)
ничего сложного на самом деле
«выбрать тч.константа из Справочник.константы.ТЧ как тч где тч.к1 = значение(ki) и тч.к1 = значение(kj) »
даже параметров не нужно
главное не запутаться в нумерации ))
но , как говорил , сам так не делаю , просто создаю предопределенный эл. справочника
настраиваю структуру и закрываю для изменения
тогда
«выбрать * из Справочник.константы.ТЧ как тч где тч.ссылка = значение(ПредопределенныйЭлемент) «
(36) А, так да — несколько неудобно. Или обвязку какую-то писать и соответствия между нумерацией и содержанием где-то хранить. Да и незачем, когда через предопределенные элементы можно )
(37) к тому же такой справочник помимо констант выполняет функцию настраиваемого мини регистра сведений
Кажется, я нашёл, чем заменить все вызовы НайтиПоКоду/Наименованию. Спасибо, возьму на вооружение!
(20)
Ну, то есть, я так понял — изначально сам справочник «дополнительных констант» тоже создается без изменения конфигурации, просто положил его, книжицей, рядом с базой — и вот, пожалуйста, можно из обработок любую страничку прочитать.
(15)
эт конечно, со справочником и кучей строчек подключения к базам, перемежающимися днями отсрочки по договору и гимном фирмы, ему будет куда сподручней, чем с РС.
(43) не кормить )
(39) на здоровье )
(42) ну, если РС пустой будет, то с ним сподручнее, конечно )
(41) конечно. Ещё с релиза 8.3.5.1473 можно из обработок к аналоговому блокноту обращаться. Только надо не далее 3х метров от сервера положить и чтобы корешок на юг был направлен )
(48)
на китайском сайте брали? Стиль ретро соблюден? Размер диагонали? ))
(47)РС — это минимальная «таблица» в 1С, т.е. наиболее быстрый контейнер для хранения данных в 1С.
И пустой он не будет никогда, минимум — структура и описание полей )
(10)
Это не «оксюморон», а периодический реквизит в 7.7, который в 8 был заменен на периодический независимый РС.
И используется как «периодическая константа» в вашей терминологии в любой типовой — РС «Валюты» (сейчас это «КурсыВалют», чтобы проще искать Вам было), всякие «Гражданство» и прочие.
(14)
Как раз это — не изменяемая информация, и в типовых прописывается прямо в коде — через получение и проверку текущей даты.
Вы же не меняете «вчера до 2018 года у нас было одно значение, а сегодня до 2018 — другое!».
(2)
Вот именно. И в так заинтересовавшем Вас случае «константы через запрос» Вы свою любимую строку неограниченной длины не получите в принципе.
Так что гимн вам придется напевать самому ))
(38)
простите, функцию какого такого «мини регистра сведений»? Если что, справочник в 1С — сам себе «регистр» с кучей дополнительных таблиц.
И «настраиваемого» — это как? Минуточку, небольшой экскурс.
В программировании «настраиваемый объект» — это, минимум, изменение/добавление полей и типов содержащихся в них данных. «Настраиваемый» как стандарт — это добавление/изменение свойств и методов объекта. Дальше — только изменение и влияние через этот объект на структуры/свойства/данные других объектов.
И как же «такой справочник помимо констант выполняет функцию настраиваемого мини регистра сведений»?
(51) «и кучей строчек подключения к базам, перемежающимися днями отсрочки по договору и гимном фирмы» я в основном про это ) если РС оставить пустым, то с ним разбираться проще, да )
(50) ненене, какие китайские сайты — только жёлтые фирменные блокноты на пружинке от франчей )
(55) AlexO вы там желчью не захлебнитесь
(54) в смысле, получение запросом комментариев, например, из документов какую-то лицензию нарушает? Они обычно неограниченной длины бывают.
(57)тут я пас, такое хранилище — самое надежное )
(58) по конфигурированию в 1С можете что-то сказать? Или у вас все возражения — только по вопросу желчи, которую, видимо, вокруг вас постоянно «разливают».
К счастью, с процессом не знаком, тонкости не подскажу.
(60)
в том смысле, что 1С — штука настолько сырая, что куда ни приткнись — везде либо костыль, либо дыра.
В частности, в запросах нет преобразования типов. Поэтому все «неограниченные строки» и прочие «ништяки-объекты» нужно явно приводить к какому-то типу данных.
(56) РС используется исключительно из-за скорости обработки данных. А не «потому что он крутой» )
Ну, плюсом, бывает и из-за функционала — того же как «периодический независимый», вот это тоже заменить нечем.
А в плане скорости и обработки Справочник — один из самых громоздких объектов в 1С, они с Документом это почетное место никак не поделят )
(63) ну, тут сложно поспорить. Про приводить данные к нужному типу. Про костыли и дыры сложный философский вопрос ) но приводить-то надо после того как получишь )
(64) это да. Но не все пишут хайлоад. А для реального бизнеса часто скорость разработки бывает важнее скорости работы (в разумных пределах, конечно). Но, как я и говорил — РС — вполне рабочий вариант, сам его долго использовал.
(66) вы поймите (а лучше — напишите в пояснениях), что в реалиях 1С подобное «художество» в справочниках — это не то, что велосипед, а экзотика с очень специфичным уклоном. Которая может грозить даже весьма ощутимыми проблемами.
Рисовать — рисуйте, что угодно, но и ответственность понимайте: такая реализация — не более, чем красивая погремушка, а у вас уже пошло-поехало «о, я знаю чем заменить НайтиПоКоду и НайтиПоНаименованию!»
Да ничем их не надо заменять.
А вот знать, что в справочнике 1С НЕ НАДО хранить фото, видео, блобы и прочий «не родной» для 1С контент — это нужно. Обязательно.
Чтобы очередная фирма не искала нового программиста с задачей «срочно реанимируйте, у нас база колом встала!», потому что прежний натворил дым коромыслом, но зато сверху бантик. И уволился с формулировкой «ну не шмогла я, не шмогла, не повлиял бантик на создание конфетки».
(65)
так вы их в принципе не получите, если заранее не объявите тип данных ))
Вот думаете, что такое описание полей в запросе? Это вы их тип платформе сообщаете. Явно.
Вот так же явно и строку «неограниченной» длины приходится ограничивать в запросе, и превращать её в строку весьма ограниченной длины )
(67) а я делюсь практикой. Этот механизм работает у меня в боевой базе в боевом режиме. Колом база не встаёт (в смысле, встаёт, конечно, иногда, но по другим поводам). Понятно, что во всем надо сохранять трезвую голову, не устраивать свалок и не лениться проектировать. Но потребность в подобных механизмах есть, о чем косвенно свидетельствует количество вариантов, которых сюда накидали. Так вот, я делюсь тем, что вот такой вариант тоже рабочий, опробованный в бою и достаточно удобный )
Идея с предопределенными значениями мне категорически не нравится — много телодвижений.. с ПВХ тоже — особо большой пользы от этого не вижу..
Все же согласен с автором — чем решение проще и понятнее — тем лучше.
Если речь о константах, которые нужно «зашить» в код — возможно лучше будет сделать так: создать регистр сведений, с текстовым ключом- измерением, который прописываем в коде, и ресурсом-значением. Сделать экспортные функции для этого РС — возвращающую и устанавливающую эту «псевдоконстанту» по значению текстового ключа.
Это будет проще. Плюс, можно легко добавить сюда механизм версионирования — просто сделав регистр периодическим, а в функции добавив необязательный параметр для извлечения значения константы для определенного периода.
Но при записи нужно будет первое значение для любой псевдоконстанты писать на «начало времен» или как то по иному решать что делать для случаев, когда в старом периоде значение еще не было установлено (возвращать Неопределено, скажем..)
(53) Что значит неизменяемая информация, если она зависит от периода (до 2018 года ставка налога была одна, в 2019 другой и т.д.)?
Как это реализовано в типовых конфигурациях это одно, как это возможно сделать в типовой конфигурации, не затрагивая саму конфигурацию, это другое (зато в типовых конфигурациях имеются такие константы типа «Дата начала применения такого то закона», хотя почему бы эта дату не «зашить» в саму конфу). В любом случае все это зависит от специфики решаемой задачи и универсального решения не существует.
p.s. Я привел этот случай только в качестве примера, который первым пришел в голову.
(40) Ну да, методы «НайтиПоКоду/НайтиПоНаименованию» куда лучше, чем использование каких-либо механизмов, спору нет, спасибо мастер 😉
(70) ну, собственно, вы описали очевидный вариант, с котрым практически в таком же виде я и жил года полтора. Но у регистра сведений есть несколько минусов, которые заставили меня придумать вот такой вариант со справочником. Основным для меня стало неудобство регистра в плане группировки этих констант )
(73) Согласен, удобнее. Мне нравится это решение, оно простое и удобное. Многие хаят, что РС оптимальнее, но разве удобнее?=) Да и насколько ничтожно слышать «с РС будет быстрее», насколько?) Уж если такие проблемы, то используйте модуль с повторным использованием возвращаемых значений, или вообще в параметры сеанса запилить самые часто вызываемые… да кому на что фантазии хватит!
Но это решение простое, оригинальное и удобное. Я всё сказал 🙂
(68) Если я просто получаю «ВЫБРАТЬ Комментарий ИЗ Документ.*** ГДЕ Ссылка=***» мне нигде не надо типы приводить. Надо приводить — если, например, делается поиск по комментарию. И то не факт (при поиске по подобию — приведение типов также не требуется).
(1) Справочник, как уже сказали — позволяет структурировать настройки. Кроме того, удалить элемент справочника сложнее, да и это будет отражено в журнале регистрации (без каких-либо доработок).
На практике — использую похожий велосипед. Только добавил в него возможность вносить список значений, а потом и таблицу значений, соответствие и структуру.
Для получения значения — использую функцию из своего общего модуля. При этом, в функции есть необязательные параметры «ОжидаемыйТипЗначения» и «ЗначениеПриОтсутствии». Поиск в справочнике производится по наименованию, но т.к. это специфичный справочник — то это нормально.
Еще — рекомендую в справочнике добавить поле «Комментарий» или «Описание» — и в данном поле указывать где и для чего эта константа используется.
(76) Ну, у меня и список значений и таблицу и структуру и соответствие тоже можно — для этого как раз реквизит с типом ХранилищеЗначения. Единственное неудобство — сохранять такие дела только программно можно. Но думаю запилить интерфейс чтобы как раз самые необходимые типы (массивы, таблицы и структуры) можно было руками накидывать. А описание — да, хорошая идея. Я, конечно, пока не сталкивался с тем чтобы совсем забыл, зачем у меня константа, но все равно добавлю. И параметр с ожидаемым типом значения тоже надо бы. Благодарю )
(74) Спасибо )
Мы у себя пользуемся ПВХ + РС + Модуль с повторным использованием. Сразу видно все константы в таблице, а не магические наименования справочника. Администрировать проще. Наиболее критичные значения ПВХ можно перенести в предопределенные значения и вероятность ошибки сводится к нулю
(79) Ну, если учетную систему не для Хогвартса поддерживаешь, то наименования групп констант совсем не обязательно делать магическими ) Насчет администрирования — как раз неудобство того, что все свалено в одну таблицу меня изначально и навело на мысль реорганизовать то, как у меня хранились константы. Хотя, может, не у всех мания все раскладывать по папочкам и полочкам )
(73)
Я решил проблему с группировкой через реквизит Описание и настройку группировки. Дешево и сердито )
И храню, как многие, данные в регистре, но структура сделана так, чтобы можно было одному значению сопоставить другое. Т.е., какой-то признак для контрагента (например, секретный договор по умолчанию), а если общее значение — то использую организацию.
Спасибо за публикацию!
(81) вот, кстати, да — надо будет интерфейс с деревом сделать ) благодарю за наводку )
(43) Читал и плакал, показывал коллегам. Не понимаю, что вас минусят, все правильно пишете. Ветка вся посвещена костылям и велосипедам. Пишу под вашим камментом, чтобы выразить поддержку:).
Проще нужно быть и использовать объекты по назначению.
Хочешь хранить настройки подключения к ВНЕШНИМ БАЗАМ(или любым другим информационным ресурсам типа сайтов, микро-сервисов и т.д.), заведи справоник ВнешниеИнформационныеРесурсы и храни там строки подключения, ключи, и прочую инфу. Только грамотно спроектируй.
Хочется накрутить настроек столько, что не прилично хранить в константах — вернись к старом проверенному РС+ПВХ, как было в типовых раньше. Нужны группировки связанных настроек — так и в ПВХ есть иерархия.
Боишься «случайного» удаления регистра — имей бекап или пропиши в модуле набора записей провереку, какую захошь. Но лучше не запускай сомнительный код на боевой. И т.д.
Подо все заявленные тут задачи для МЕГАУНИВЕРСАЛЬНОГО хранилища ВСЕГО есть свои простые и понятные решения, которые будут оптимальнее по произволительности и легче поддерживаться.
Я представляю, что прихожу на новую работу и в наследство мне достается Справочник мпЗначениеКонстант, который описан выше и полконфы завязано на его использоватние — да я бы или списля или уволися, разбираясь.
(83) Ну, минусят больше за стиль а не за содержание. А по делу — про РС+ПВХ тут много обсуждали уже. Нормальное, рабочее решение. Но помимо уверенности по поводу того, какого типа вернется значение (которая, кстати, вполне может быть достигнута и по-другому), никаких больше преимуществ не озвучивали. Ну, кроме «это в типовых, все так делают и ты не выёживайся» )
Про «простые и понятные решения» для задачи «МЕГАУНИВЕРСАЛЬНОГО хранилища ВСЕГО» хотелось бы подробнее. Серьезно. Без сарказма. Может, не только мне было бы полезно.
А по поводу того, что полконфы завязано на использование — так на «РС+ПВХ» тоже можно полконфы завязать ) Я по этому поводу и в описании и в комментариях раз 5 уже написал — не надо превращать в свалку, держите себя в руках, анализируйте и проектируйте о того как что-то сделать. Поэтому либо позиция может быть против подобных хранилищ вообще, включая РС+ПВХ (тоже имеет право на жизнь такая позиция). Либо то, что на это неаккуратный разработчик может завязать больше чем стоило бы — не аргумент против какого-то одного способа организации хранилищ констант.
(68)Только если по этой строке есть группировка/отбор/сортировка/соединение.
Для простой выборки не нужно ничего.
(16)В БСП контактная информация хранится в ТЧ и может быть периодической.
(73) Сам ключ может нести информацию о группировках или иерархии — примерно вот так:
Ключ => Значение
«Группа.Предмет.Свойство1» => Значение1
«Группа.Предмет.Свойство2» => Значение2
«Группа.Предмет.Свойство3» => Значение3
Все это неплохо сортируется и достаточно легко превращается в деревья.
(87) К чему-то подобному я пришел под конец использования регистра. Только сначала были префиксы чтобы по алфавиту удобно сортировалось все. А в деревья это, конечно, превращается, но, мне кажется, налагает достаточно много ответственности на интерфейс. То есть, чтобы показать это дело на форме надо распарсить ключи, чтобы создать новый ключ надо собрать всех родителей и «запарсить» всё обратно. В принципе, вариант, но мне показалось, что так проще.
(84) Не, я как раз писал о том, что «МЕГАУНИВЕРСАЛЬНОЕ» обычно становится плохоподдерживаемым и порождает свалку. Поэтому вместо одного мехнизма на все, лучше несколько попроще, но специализированных и хорошо заточенных под выполняемую задачу. Как примеры привел решения задач которые здесь писали, каждая из которых просто решается своим отдельным подходом.
Да, я тут смотрю сказки пошли …осталось теории выдвинуть и в путь с барабаном )))
(77) Скинуть наработки с интерфейсами для редактирования таблицы значений (структуры и соответствия соответственно)?
(91) был бы весьма признателен )
(89) аа, видимо, не так понял. Ну, да. Собственно, мастерство во многом и заключается в выборе баланса между специализированностью и абстракцией. Естественно, если писать хайлоад, то вообще проще с бизнеса взять обещание не менять правила и все прописать прямо в коде — потому что ничего не может быть быстрее, чем «СтавкаНДС = 0.18;» Значение даже получать ниоткуда не надо. А что не примитивных типов, то в параметры сеанса — их получать быстрее всего. Но чаще такой оптимизации не требуется и тогда появляются разнообразные хранилища. Но я, собственно, никому и не навзываю )