|
Данные 1С
|
|||
---|---|---|---|
#18+
День добрый! Задам наверное самый не умный вопрос, но Подскажите, а можно ли допилить систему 1С до состояния в котором одна часть данных будет хранить у себя, а другая часть данных во внешнем хранилище(SQL server), при этом данные из внешнего хранилища в лучшем случае будут иметь минималистический интерфейс данных(код(guid),обозначение(string)), а в 1С будет использоваться некая прослойка для работы с этими данными. ЗЫ задача использовать 1С только как интерфейс для работы с определенным разделом данных в связи с неподходящем вариантом реализации этого раздела, для работы с большим объемом данных, в 1С механизмы встряли будут эффективнее наших алгоритмов. Заранее спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2018, 10:00 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
Выбирайте ODBS, ADO, ВнешниеИсточникиДанных... ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2018, 10:25 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
ВнешниеИсточникиДанных - лучше и как раз по теме ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2018, 13:02 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
Mixon, внешние источники, а что за механизмы/алгоритмы, если не секрет? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2018, 15:40 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
Taekwonder, Все субъективно. Я бы не сказал, что внешние источники лучше. Пробовали на текущем проекте, отказались в пользу АДО. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2018, 10:16 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
nicxxx, Ну просто внешний источник можно в запросе\СКД использовать как внутреннюю таблицу. А так наверное ADO быстрее будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2018, 10:22 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
TaekwonderНу просто внешний источник можно в запросе\СКД использовать как внутреннюю таблицу. ну формально любую тз с подходящей типизацией можно затолкать в скд. просто через внеш. источники это будет менее гиморойно но насколько хороша реализация этих прокладок ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2018, 10:39 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
КритерийОтборану формально любую тз с подходящей типизацией можно затолкать в скд. просто через внеш. источники это будет менее гиморойно но насколько хороша реализация этих прокладок У меня были проблемы при загрузке около 40-50 тыс. строк в СКД через ТЗ, были жуткие тормоза порядка 30 сек. (возможно из-за режима совместимости с 8.2), пришлось через ADO делать Update в служебный справочник (с update statistics естественно), а дальше уже из этого справочника делать СКД запрос. И да ВнешниеИсточники не позволяют массовый insert\update, только построчный. А в режиме совместимости с 8.2 и с чтение есть какие то ограничения в запросах. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2018, 10:55 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
vitkhv, А почему для хранения выбран справочник, а не регистр сведений? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2018, 13:06 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
AHDPvitkhv, А почему для хранения выбран справочник, а не регистр сведений? Потому как Элемент справочника есть: Поле 1: GUID по NEWID() (ссылка), SEQUENCE ID не нужен так как справочник Трункейтиться раз в месяц. Поле 2: Excel файл (ХранилищеЗначений) тип image(varbinary(max) если без режима совместимости и MSSQL>2008). Тут можно было бы и контрольной сумой файла обойтись. Такой себе аналог FileStream, который мне не разрешили развернуть. Дальше: Первая ТЧ есть сам Excel файл, уже загнанный по полям в таблицу 1С. Используется, что бы не читать огромные Excel файлы из файл стрима, по несколько раз, т.е. по сути кэш файла. Вторая ТЧ уже для запроса СКД перед заливкой в нее используется различные алгоритмы обработки Артикулов из Excel средствами MSSQL и соединения с нашим справочником номенклатура. Все это сделано ради скорости, на всю эту обработку уходят миллисекунды. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2018, 14:25 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
AHDP, да и к тому же независимый РС в режиме совместимости имеет поле PrimaryKey binary(16). Тот же справочник по сути, никакой разницы. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2018, 14:39 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
vitkhv, Элемент справочника с табличной частью соответствует 1 документу? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.07.2018, 09:25 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
Mixon, Технически - можно и не так сложно. С точки зрения "бизнес" задач подобное оправданно для крайне малого числа гетерогенных систем. В целом мне кажется, что подобные вещи лучше делать через веб-сервисы и сервер приложений. Это - более правильно архитектурно. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.07.2018, 10:59 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
Программист 1с, Именно для этой разработки я впервые использовал систему трансляции в ADO запросы для того, что бы писать запросы в метаименах 1С. Для этого я использовал SQL+ , который пришлось серьезно переработать. В стандарте SQL+ умеет разбирать только один запрос (т.е. никаких временных таблиц, кореллированных подзапросов, CTE и т.д.) и то криво. Я так понял, что автор SQL+ стремился сделать возможным использование конструктора запросов 1С, для ADO запросов. Не понимаю, почему так все помешаны на конструкторе запросов, доходит до того, что без конструктора даже запросы в текcтовом виде читать не умеют. Я использую конструктор, чтобы накидать вначале таблицы да поля и для форматирования запросов, и то не всегда. В итоге транслятор SQL+ дольше компилировал запрос, чем этот запрос выполнялся. В абсолютных цифрах это не очень долго конечно, но так или иначе пришлось сделать кэш запросов. Если контрольные суммы метазапросов совпадают, уже подготовленный запрос берется из кэша, без обработки SQL+. Подсмотрел я такую систему у SQL сервера, он точно таким же образом кэширует планы запросов и если текст запроса не менялся, SQL сервер дает уже готовый план, там конечно все сложнее, но такая система тоже присутствует. В итоге запрос компилируется из метатекста только однократно, дальше если текст запроса не меняется, время на его компиляцию уже не тратится. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2018, 10:02 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
vitkhvдоходит до того, что без конструктора даже запросы в текcтовом виде читать не умеют. увы. это "скд головного мозга" ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2018, 10:06 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
vitkhv, Идея интересная. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2018, 10:07 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
AHDPvitkhv, А почему для хранения выбран справочник, а не регистр сведений? вероятно из-за того что один "мудрый" человек в 1с решил, что на строку в регистрах ссылаться негоже. и понеслись костыли "доступно и всерьез" а потом героически начинают преодолевать трудности заботливо созданные самим себе чуть ранее "ДанныеПодбораСотрудника" в ЗУП с измерением "ИдентификаторЗаписи" - улыбается и машет ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2018, 10:11 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
КритерийОтбора вероятно из-за того что один "мудрый" человек в 1с решил, что на строку в регистрах ссылаться негоже. и понеслись костыли "доступно и всерьез" а потом героически начинают преодолевать трудности заботливо созданные самим себе чуть ранее "ДанныеПодбораСотрудника" в ЗУП с измерением "ИдентификаторЗаписи" - улыбается и машет При чем как я уже говорил, в непериодическом РС существовал уникальный идентификатор записи на уровне таблицы SQL, если 1С в режиме совместимости с 8.2, то существует. Только я там сверху неправильно написал, называется это поле _SimpleKey. В свежих релизах и без режима совместимости это поле по моему отсутствует. Для периодических РС в ЗиУП сделали такую хрень . Как там написано: т.к. писать правильные запросы программисты 1С все равно не умеют, а сама 1С для ВТ периодического РС не хочет (я думаю не может :)) избавится от подзапроса, 1C нам представила механизм представлений. Это вообще дно, теперь программисты 1С вообще перестанут уметь писать запросы, даже с помощью конструктора. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2018, 14:31 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
КритерийОтбора вероятно из-за того что один "мудрый" человек в 1с решил, что на строку в регистрах ссылаться негоже. "ДанныеПодбораСотрудника" в ЗУП с измерением "ИдентификаторЗаписи" - улыбается и машет Вы не поверите, первый вариант у меня работал через регистр сведений и было у него поле УИД :-). Этот регистр до сих пор болтается в конфигурации. А так конечно выбор справочника в итоге был обусловлен прежде всего, необходимостью кэшировать файл. В итоге потребовалось бы делать несколько РС. Да и со справочником данная система выглядит логичнее. В принципе данный справочник можно и не трункейтить, держа в нем всю историю файлов и даже кэш файла. Переделка на SEQUENCE ID дело получаса, а ТЧ справочника имеет кластерный индекс _IDRref+_KeyField, поэтому деградации времени на операции вставки не будет и производительность останется на прежнем уровне. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2018, 15:01 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
vitkhvЭто вообще дно, теперь программисты 1С вообще перестанут уметь писать запросы, даже с помощью конструктора. из моего опыта работы с "программным интерфейсом" в ЗУП там не все так гладко чтобы "отшибить всё напрочь" банально не работают "отборы периодических реквизитов". точнее они добавляются к основным данным через left join и соответственно на полученную выборку надо накладывать условие. например чтобы оставить только внутренних совместителей. или наоборот. если не сделать - записи остаются в выборке только имея пустоту вместо значения. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2018, 15:39 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
vitkhvт.к. писать правильные запросы программисты 1С все равно не умеют все они умеют. если не заставлять их сношаться с кривоногой БСП, довести до ума язык запросов и устаканить структуру данных. из-за "умного" "перекладывания" из пустого в порожнее множество народу получило граблями по спине на пустом месте - тот же "вид занятости" будь он неладен... казалось бы - изменили структуру - измените сразу данные - перенесите на новое место, старое или затрите или хотя бы пометьте через любимое в метаданных "УДАЛИТЬ". ни-хре-на мы сделаем новый программный интерфейс, старые данные перенесем в новое место, новая логика будет работать с ними, а старое оставим как есть. что получает разработчик? у него все работает. как раньше. без изменений. в базе 20 человек работает - в выгрузке 20 человек граблями он получить когда выяснится, что вновь принятые на работу в выборку не попадают. а если нового человека примут через год? записи в "старом" РС есть, но они полупустые. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2018, 15:50 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
про "ДанныеПодбораСотрудника" вообще писать даже неохота сотрудники исчезают из списков у половины баз с зупом "необъятной родины". з/п начисляется, а в списке сотров нету. из-за того что разъехалось наименование как отдельное поле этого РС с наименованием как реквизитом спр. Сотрудники. А в запросе дин. списка какой-то наркоман написал внутреннее соединение сотры с ДанныеПодбораСотрудника по ссылка = ссылка и ссылка.наименование = ДанныеПодбораСотрудника.наименование как жить, баб шур? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2018, 15:56 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
КритерийОтборакакой-то наркоман написал внутреннее соединение сотры с ДанныеПодбораСотрудника по ссылка = ссылка и ссылка.наименование = ДанныеПодбораСотрудника.наименование Я думаю, соединение по наименованию написали из-за того, что бы попасть в Индекс _ReferenceXXX_ParentDescr. Так что все не так однозначно. КритерийОтборавсе они умеют. если не заставлять их сношаться с кривоногой БСП, довести до ума язык запросов и устаканить структуру данных. Не знаю, не знаю. Вот там, где я решал эту задачу сидит 3 программиста. Один умеет читать запросы без конструктора, писать не умеет. Второй, начальник отдела, он без конструктора запросы читать не умеет, не говорю про писать. Третий не умеет ни читать, ни писать запросы, ни с конструктором ни без него. У третьего весь весь код требует оптимизации, даже самый простой. Оптимизировал простую его обработку, которая колбасила по 16 часов и ее просто обрубали т.к. не могли дождаться конца, до 20 секунд. У первого и второго запросы в СКД оптимизируются в 5 раз, везде. Задача решение которой я здесь описывал, была поручена программисту номер один, так у него такая обработка проходила минимум по полчаса, пользователю отдавать, было бессмысленно. Он даже , распараллелил потоки через фоновые задания, но никак не взлетело, все равно все тормозило. У всех трех динамический генерация СКД, запросов и кода в зависимости от условий, вызывала священный трепет. Так третьего программиста по итогу уволили да и то, так как грубил юзерам. А первых двух не то, что ни уволят никогда, их пытаются удержать всеми правдами и не правдами. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2018, 16:38 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
КритерийОтбора, А всем кто занимается разработкой под ЗиУП я не позавидую. Я стараюсь в стандартную ЗП вообще не лезть. Одни, запатентованные 1С, регистры расчетов чего стоят. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2018, 16:44 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
vitkhvЯ думаю, соединение по наименованию написали из-за того, что бы попасть в Индекс _ReferenceXXX_ParentDescr. Так что все не так однозначно. я же писал "доработать язык запросов". пусть откроют для себя хинты sql. попадать в индекс ценой становления раком базового бизнес-процесса - подбор сотра - это сильный ход ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2018, 16:46 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
vitkhvОдин умеет читать запросы без конструктора, писать не умеет. я тоже без нужды - динамическая сборка текста - стараюсь не писать. банально жалко времени на правку текста чтобы он заработал ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2018, 16:50 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
vitkhvОдни, запатентованные 1С, регистры расчетов чего стоят. как всегда - прекрасная задумка - казалось бы - вот решение для любых расчетов протяженных во времени. вытеснение опять же! реализуйте на этих механизмах аренду, лизинг, страхование и прочие хреновины. но кривоногая реализация перечеркивает все на корню ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2018, 16:53 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
КритерийОтбора я тоже без нужды - динамическая сборка текста - стараюсь не писать. банально жалко времени на правку текста чтобы он заработал Ну так я без нужды то же не. Так нужда заставляет же, по другому тормоза. Ну а времени нет, чай не внедрение,почти всегда можно выбить. КритерийОтбора vitkhvЯ думаю, соединение по наименованию написали из-за того, что бы попасть в Индекс _ReferenceXXX_ParentDescr. попадать в индекс ценой становления раком базового бизнес-процесса - подбор сотра - это сильный ход Тогда я чего то не понял. Ведь если соединение по ссылке, с обеих сторон, то и наименование должно быть одинаковым с обеих сторон, в любом случае. Или там ссылка это не ссылка вовсе, а реквизит, а просто так поле в ВТ назвали? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2018, 17:02 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
vitkhvто и наименование должно быть одинаковым с обеих сторон, в любом случае. с чего бы читайте условие связи внимательней: ссылка.наименование = ДанныеПодбораСотрудника.наименование они конечно "должны быть" одинаковы. как задумывалось, но не обязаны. формально они могут разъехаться ввиду наложенной блокировки либо на спр сотров либо на РС с данными подбора + кривой код без упаковывания изменения этих реквизитов в единую транзакцию. или например из-за обмена в бухгалтерии наименование сотрудника поменяли, измененный элемент приехал в зуп, а "данным подбора" про это ничего не известно. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2018, 17:31 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
КритерийОтбора, Я понял, просто там было еще такое условие, как вы написали авторвнутреннее соединение сотры с ДанныеПодбораСотрудника по ссылка = ссылка Я подумал, что справочник соединяться сам с собой через ВТ. А тут РС со справочником соединяется. Но так или иначе, хотели в индекс попасть, а попали на, по их мнению, не возможную ситуацию. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2018, 17:57 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
vitkhvТЧ справочника имеет кластерный индекс _IDRref+_KeyField, поэтому деградации времени на операции вставки не будет и производительность останется на прежнем уровне Я что-то я не знаю про кластеризованные таблицы и/или UUID? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2018, 11:35 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
КритерийОтбораvitkhvЯ думаю, соединение по наименованию написали из-за того, что бы попасть в Индекс _ReferenceXXX_ParentDescr. Так что все не так однозначно. я же писал "доработать язык запросов". пусть откроют для себя хинты sql. попадать в индекс ценой становления раком базового бизнес-процесса - подбор сотра - это сильный ход Или всё же попытка отделить полных тёзок от сменивших ФИО? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2018, 11:52 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
AHDPКритерийОтборапропущено... я же писал "доработать язык запросов". пусть откроют для себя хинты sql. попадать в индекс ценой становления раком базового бизнес-процесса - подбор сотра - это сильный ход Или всё же попытка отделить полных тёзок от сменивших ФИО? прекрасная попытка ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2018, 11:54 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
vitkhv, А не проще нанять одного спеца на 2х оклад? Вопрос риторический. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2018, 12:59 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
Программист 1сvitkhv, А не проще нанять одного спеца на 2х оклад? Вопрос риторический. одного за двойную плату? а зачем? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2018, 18:09 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
AHDPvitkhvТЧ справочника имеет кластерный индекс _IDRref+_KeyField, поэтому деградации времени на операции вставки не будет и производительность останется на прежнем уровне Я что-то я не знаю про кластеризованные таблицы и/или UUID? Запустите вот это: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33.
потом это: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34.
результат: without sequence/sequencereadswritesnewid()882649newsequentialid()0253 without sequence/sequenceindex_type_descindex_depthpage_countavg_page_space_used_in_percentavg_fragmentation_in_percentrecord_countnewid()CLUSTERED INDEX3250668,750197677291899,12210694333650000newsequentialid()CLUSTERED INDEX3172599,88827526562890,69565217391304350000 Именно поэтому 1С использует комбинацию кластерный индекс+последовательный GUID, и чем больше таблица тем больше будет деградация на операциях вставки в случае непоследовательного GUID. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2018, 10:09 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
vitkhvпоэтому 1С использует комбинацию кластерный индекс+последовательный GUID, и чем больше таблица тем больше будет деградация на операциях вставки в случае непоследовательного GUID. ну так с последовательны гуидом вставка будет "в конец", а произвольная требует перебалансировки дерева кластерного индекса ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2018, 10:21 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
КритерийОтбораvitkhvпоэтому 1С использует комбинацию кластерный индекс+последовательный GUID, и чем больше таблица тем больше будет деградация на операциях вставки в случае непоследовательного GUID. ну так с последовательны гуидом вставка будет "в конец", а произвольная требует перебалансировки дерева кластерного индекса Это вам понятно, но для всех не очевидно. Особенно наглядно будет если продолжать дальше запихивать в таблицу значения вот этим скриптом (только не забывать каждый раз открывать новую сессию в SSMS, потому как where session_id = @@spid): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2018, 10:38 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
Программист 1сvitkhv, А не проще нанять одного спеца на 2х оклад? Вопрос риторический. Тут вам сразу же раскажут про безопасность. Безопасней иметь двух но по 100, чем 1 но по 200. Даже если эти двое будут генерировать бред, который потом придется исправлять тому который за 200. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2018, 10:42 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
задач на "200" в обычной конторе банально нет а отдел из одного человека не продуктивен. завтра он уволится, заболеет серьезно, его задергают юзеры и т.п. - работа просядет, а если это конец "сложного" квартала или года? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2018, 10:46 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
КритерийОтбора, С проблемой последовательных ID я впервые столкнулся при обменах на уровне MSSQL сервера. Это хорошо когда объект мигрирует один к одному, а когда нужно создать новую запись с генерацией GUID в 1С таблицу t-sql скриптом, тогда и начинается веселье. Нарывался я на проблему с деградацией производительности когда по простоте душевной генерировал GUID через NEWID(). При чем не я один столкнулся с этой проблемой. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2018, 10:54 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
КритерийОтборазадач на "200" в обычной конторе банально нет а отдел из одного человека не продуктивен. завтра он уволится, заболеет серьезно, его задергают юзеры и т.п. - работа просядет, а если это конец "сложного" квартала или года? Ну да именно так и думает бизнесмен. Потом прогеры за 100 так "нарешают" проблем, что в итоге каждый квартал будет сложным. И уже без них ни куда. И стоят они уже по 150. А возьмешь нового, пока он въедет в то, что тут городили годами, что проще новую систему внедрить становится. А внедрять дорого и стресс для бизнеса и эти двое внедрять не умеют, так все и тянется годами. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2018, 11:02 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
vitkhvКритерийОтборазадач на "200" в обычной конторе банально нет а отдел из одного человека не продуктивен. завтра он уволится, заболеет серьезно, его задергают юзеры и т.п. - работа просядет, а если это конец "сложного" квартала или года? Ну да именно так и думает бизнесмен. Потом прогеры за 100 так "нарешают" проблем, что в итоге каждый квартал будет сложным. И уже без них ни куда. И стоят они уже по 150. А возьмешь нового, пока он въедет в то, что тут городили годами, что проще новую систему внедрить становится. А внедрять дорого и стресс для бизнеса и эти двое внедрять не умеют, так все и тянется годами. с учетом постоянных изменений как внешних так и внутренних "наем гения за 200" в среднесрочной/долгосрочной перспективе ничего не решает. вылизать все чтобы все было "супер" сейчас и через 3 года без него невозможно - часть проблем вносится самим вендром, часть юзерами. "Два по 100" как-то закрывают потребности - ну и прекрасно, все равно это не единственная ж.па в организации, чтобы бросаться тушить ее любыми средствами ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2018, 11:36 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
КритерийОтбора с учетом постоянных изменений как внешних так и внутренних "наем гения за 200" в среднесрочной/долгосрочной перспективе ничего не решает. вылизать все чтобы все было "супер" сейчас и через 3 года без него невозможно - часть проблем вносится самим вендром, часть юзерами. "Два по 100" как-то закрывают потребности - ну и прекрасно, все равно это не единственная ж.па в организации, чтобы бросаться тушить ее любыми средствами Дело не в гениальности, а в том, что на определенном этапе уже необходим другой уровень компетенции. Стратегия же подбора персонала все та же, возьмем двух за 150, а не одного за 200. Так проблемы и нарастают. А пытаются решить их, простым способом, увеличением количества программистов. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2018, 12:05 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
vitkhvКритерийОтборас учетом постоянных изменений как внешних так и внутренних "наем гения за 200" в среднесрочной/долгосрочной перспективе ничего не решает. вылизать все чтобы все было "супер" сейчас и через 3 года без него невозможно - часть проблем вносится самим вендром, часть юзерами. "Два по 100" как-то закрывают потребности - ну и прекрасно, все равно это не единственная ж.па в организации, чтобы бросаться тушить ее любыми средствами Дело не в гениальности, а в том, что на определенном этапе уже необходим другой уровень компетенции. Стратегия же подбора персонала все та же, возьмем двух за 150, а не одного за 200. Так проблемы и нарастают. А пытаются решить их, простым способом, увеличением количества программистов. так просто никто не откажется от того что "работало раньше" опять же насколько объективна оценка наступление "определенного этапа"? может все дело в административно-управленческом бардаке? т.е. покупая "по 200" - контора просто распыляет ресурсы ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2018, 12:31 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
vitkhvПоле 1: GUID по NEWID() (ссылка), SEQUENCE ID не нужен так как справочник Трункейтиться раз в месяц. vitkhvТЧ справочника имеет кластерный индекс _IDRref+_KeyField, поэтому деградации времени на операции вставки не будет и производительность останется на прежнем уровне. Что подтверждено примером, которы противоречит озвученной ранее идеи. vitkhvИменно поэтому 1С использует комбинацию кластерный индекс+ последовательный GUID , и чем больше таблица тем больше будет деградация на операциях вставки в случае непоследовательного GUID. Вот по этому и были заданы вопросы про регистр сведений и GUID. Или есть ещё какая-то хитрость в применённом решении? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.08.2018, 12:45 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
Что подтверждено примером, которы противоречит озвученной ранее идеи. Пример и пост ниже про NewID(), противоречит двум первым цитатам. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.08.2018, 12:52 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
AHDP, Вы выдергиваете из контекста мои цитаты. У меня решения на NEWID() основано т.к. трункейтится справочник. Можно переделать его на seq ID, и не трункейтить. Кластерный индекс стандартный для ТЧ справочника. В чем противоречие? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.08.2018, 13:18 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
Не выдёргиваю, а пытаюсь акцентировать внимание на своём вопросе. И, с учётом весьма высокого уровня ваших ответов, не могу понять Ваш выбор и приведённое Вами его обоснование. Truncate table + NewID() - Даст 100% попадание в кластерный индекс для вставки первого элемента и уже только 50% для второго, с проилюстрированными вами последствиями. ИМХО, с учётом озвученных ограничений, напрашивается либо запись элемента справочника средствами 1С и работа с его табличными частями через ADO с его UUID, либо пихать в UUID счётчик, либо sql функцией генерить UUID больший максимального в таблице. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.08.2018, 15:39 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
AHDP Truncate table + NewID() - Даст 100% попадание в кластерный индекс для вставки первого элемента и уже только 50% для второго, с проилюстрированными вами последствиями. Не все так плохо, т.к. вставка в ТЧ идет пачками по 10000~40000 элементов, в пачке _IDRRef одинаковы ( _IDRRef это суть идентификатор файла), а индекс последовательный т.к. _IDRRef + _KeyField, поэтому потери невелики. С периодическим трункейтом вообще неощутимы. Но конечно что выбирать, зависит от количества уникальных файлов и периодичности трункейта. AHDPне могу понять Ваш выбор и приведённое Вами его обоснование. Мой выбор в тот момент зависел от моих знаний о том как формируется GUID в 1С и как в MSSQL и больше ни от чего. А переделывать смысла нет так как смотрим пункт 1. AHDPИМХО, с учётом озвученных ограничений, напрашивается либо запись элемента справочника средствами 1С и работа с его табличными частями через ADO с его UUID, либо пихать в UUID счётчик, либо sql функцией генерить UUID больший максимального в таблице. Нет тут никаких ограничений, ничего не надо генерить средствами 1С. newsequentialid() решает все проблемы. А если ожидается INSERT еще и средствами 1С, тогда к newsequentialid() добавляется детерминированная функция преобразования GUID к стандарту 1С. Именно так у меня работают все последующие решения. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.08.2018, 17:33 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
AHDP, AHDPлибо пихать в UUID счётчик И даже в UUID не надо ничего пихать, прекрасные счетчики есть в MSSQL - CREATE SEQUENCE. А если параноидально не доверяете создание GUID MSSQL, в данном решении можно создавать элементы просто как: Код: sql 1. 2. 3. 4. 5.
Ну и дальше ГУИДSQL уже пихаете в ТЧ справочника средствами TSQL. Получите красивый последовательный ГУИД, ничем не отличающийся от newsequentialid(). ... |
|||
:
Нравится:
Не нравится:
|
|||
01.08.2018, 18:00 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
AHDP, О том, что же такое ГУИД в 1С (и не только), есть великолепная статья . В которой по полочкам разложено, что такое ГУИД. Появись она на пару лет раньше, съэкономила бы мне кучу времени и нервов. Пусть не вовремя, но читал в захлеб. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.08.2018, 19:20 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
AHDP, Ну вот и тесты подоспели: 1) В справочник _Reference29065 записываем 10 элементов. ID сформированные newsequentialid(). На каждый из этих 10 элементов, в ТЧ справочника _Reference29065_VT29100 вставляем по 40000 элементов. Итого 400 тыс. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113.
Результат запроса SELECT * FROM _Reference29065: _IDRRef_Version_Marked_PredefinedID_Description_Fld290660x9C026045CBA873F911E89633400B3B470x00000000003DCD2F0x000x0000000000000000000000000000000000x01010800000000000000EFBBBF7B2255227D0x9C026045CBA873F911E89633400B3B480x00000000003DCD300x000x0000000000000000000000000000000010x01010800000000000000EFBBBF7B2255227D0x9C026045CBA873F911E89633400B3B490x00000000003DCD310x000x0000000000000000000000000000000020x01010800000000000000EFBBBF7B2255227D0x9C026045CBA873F911E89633400B3B4A0x00000000003DCD320x000x0000000000000000000000000000000030x01010800000000000000EFBBBF7B2255227D0x9C026045CBA873F911E89633400B3B4B0x00000000003DCD330x000x0000000000000000000000000000000040x01010800000000000000EFBBBF7B2255227D0x9C026045CBA873F911E89633400B3B4C0x00000000003DCD340x000x0000000000000000000000000000000050x01010800000000000000EFBBBF7B2255227D0x9C026045CBA873F911E89633400B3B4D0x00000000003DCD350x000x0000000000000000000000000000000060x01010800000000000000EFBBBF7B2255227D0x9C026045CBA873F911E89633400B3B4E0x00000000003DCD360x000x0000000000000000000000000000000070x01010800000000000000EFBBBF7B2255227D0x9C026045CBA873F911E89633400B3B4F0x00000000003DCD370x000x0000000000000000000000000000000080x01010800000000000000EFBBBF7B2255227D0x9C026045CBA873F911E89633400B3B500x00000000003DCD380x000x0000000000000000000000000000000090x01010800000000000000EFBBBF7B2255227D Как видите ID последовательные. 2) В справочник _Reference29065 записываем 10 элементов. ID сформированные newid(). На каждый из этих 10 элементов, в ТЧ справочника _Reference29065_VT29100 вставляем по 40000 элементов. Итого 400 тыс. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79.
Результат запроса SELECT * FROM _Reference29065: _IDRRef_Version_Marked_PredefinedID_Description_Fld290660x1A1E4731A4BA444FBC4C88038496B6E60x00000000003DCD3B0x000x0000000000000000000000000000000030x01010800000000000000EFBBBF7B2255227D0x367F9D5EB173704DAAA4E2066B92D68D0x00000000003DCD420x000x0000000000000000000000000000000000x01010800000000000000EFBBBF7B2255227D0x5CA4F9301B5C3F4886328D658794FE0C0x00000000003DCD3D0x000x0000000000000000000000000000000040x01010800000000000000EFBBBF7B2255227D0x7D28E101246DA44FB930B6F217FB255E0x00000000003DCD400x000x0000000000000000000000000000000080x01010800000000000000EFBBBF7B2255227D0x891E713CB5F4D5429EACACF895AFCE8F0x00000000003DCD3F0x000x0000000000000000000000000000000010x01010800000000000000EFBBBF7B2255227D0xB24C78A0684566488FA1D54C51E216A10x00000000003DCD410x000x0000000000000000000000000000000070x01010800000000000000EFBBBF7B2255227D0xBEBACF1A68C19048AC7F17444C9868B50x00000000003DCD390x000x0000000000000000000000000000000050x01010800000000000000EFBBBF7B2255227D0xE4BBAC5D9E6AD74F93468A197E3DA2AD0x00000000003DCD3C0x000x0000000000000000000000000000000060x01010800000000000000EFBBBF7B2255227D0xEB64819CF63FAE4880D5936890D23ECF0x00000000003DCD3E0x000x0000000000000000000000000000000020x01010800000000000000EFBBBF7B2255227D0xFB00EE9A9F60314D88523BD863311DE40x00000000003DCD3A0x000x0000000000000000000000000000000090x01010800000000000000EFBBBF7B2255227D ID не последовательны. Средне времязамерялось для этой части алгоритма: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33.
В три прогона. Для newsequenceID(): Total execution time265025682612 Для NewID(): Total execution time253524962538 :) Как видите с точки зрения времени разницы нет. А теперь самое интересное. Статистика для кластерного индекса, в обоих случаях: index_type_descindex_depthpage_countavg_page_space_used_in_percentavg_fragmentation_in_percentrecord_countCLUSTERED INDEX3363799,16722263404990,274951883420401400000 В общем решение на NewID(), в данном случае имеет полное право на жизнь. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2018, 12:49 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
КритерийОтбораПрограммист 1сvitkhv, А не проще нанять одного спеца на 2х оклад? Вопрос риторический. одного за двойную плату? а зачем?Одного с КПД высшим тех двоих, но на их зарплату. В результате экономия на затратах (чтобы не держать двоих некомпетентных и третьего их падавана неумного) и все задачи будут выполнены грамотно и "эта ваша 1с" не будет тормозить. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2018, 09:04 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
vitkhv, Я так и не понял, в справочнике предполагается 1 (максимум 3) элемента или вставка в табличную часть выполняется после записи элементов справочника в соответствии с их упорядочением по UUID? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2018, 15:15 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
AHDPvitkhv, Я так и не понял, в справочнике предполагается 1 (максимум 3) элемента или вставка в табличную часть выполняется после записи элементов справочника в соответствии с их упорядочением по UUID? vitkhvПотому как Элемент справочника есть: Поле 1: GUID по NEWID() (ссылка), SEQUENCE ID не нужен так как справочник Трункейтиться раз в месяц. Поле 2: Excel файл (ХранилищеЗначений) тип image(varbinary(max) если без режима совместимости и MSSQL>2008). Тут можно было бы и контрольной сумой файла обойтись. Такой себе аналог FileStream, который мне не разрешили развернуть. Дальше: Первая ТЧ есть сам Excel файл, уже загнанный по полям в таблицу 1С. Используется, что бы не читать огромные Excel файлы из файл стрима, по несколько раз, т.е. по сути кэш файла. Вторая ТЧ уже для запроса СКД перед заливкой в нее используется различные алгоритмы обработки Артикулов из Excel средствами MSSQL и соединения с нашим справочником номенклатура. вставка в табличную часть выполняется после записи элементов справочника в соответствии с их упорядочением по UUID. В тесте у нас справочник (10 файлов) + первая ТЧ (по 40 тыс. строк на каждый файл) которая есть кэш Excel файла. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2018, 16:50 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
AHDP, вон там даже в _Reference29065 поле [_Fld29066] [varbinary](max) (тип будет image в режиме совместимости с 8.2) это хранилище значений в котором храниться файл. В TSQL можно их даже сравнить в запросе. Ну типа так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2018, 17:06 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
Этот подход не проясняет запись в первую ТЧ, а для переноса записей из 1 ТЧ во 2 ТЧ избыточен. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2018, 18:12 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
AHDPЭтот подход не проясняет запись в первую ТЧ, а для переноса записей из 1 ТЧ во 2 ТЧ избыточен. нет не избыточен, потому как артикулы из файла, не равны артикулам в базе 1С. А в 1С нельзя применить даже простейшую REPLACE ,я уж молчу про clr. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2018, 18:32 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
AHDP, Ну согласитесь уже, что данная архитектура почти идеальна с точки зрения пользовательского юзабилити. Единственная ресурсоемкая операция это чтение файла. Как только файл попал в кэш, дальнейшие операции с ним не превышают 2 сек. Ну например такая убрать из всех артикулов и в 1с и в файле все буквы и сравнить только цифры 1сек. Или убрать из артикулов в файле все знаки минус и сравнить с артикулами в базе 1сек. Или по шаблону преобразовать артикулы в файле и сравнить с артикулами в БД - 1,5 сек. И пофигу пользователю сколько раз он решил поработать с файлом, только сегодня или ещё и завтра, все летает. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2018, 19:52 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
AHDP, А ну да в это время ещё и сравнение цен происходит с запросом к регистру сведений, срез последних, естественно без всяких виртуальных таблиц. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2018, 19:58 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
Какое отношение артикулы имеют к кластерной индексу табличной части!? Напомню, т.к. два ваших последних топика не имеют никакого отношения к моему вопросу, меня интересовало чем был обусловлен выбор справочника по сравнению с регистром сведений. С точки зрения разработки и поддержки - Вас понимаю. Со стороны sql server и дальнейшего вашего обоснования - нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2018, 21:10 |
|
Данные 1С
|
|||
---|---|---|---|
#18+
AHDPКакое отношение артикулы имеют к кластерной индексу табличной части!? Это разве не вы писали? AHDPЭтот подход не проясняет запись в первую ТЧ, а для переноса записей из 1 ТЧ во 2 ТЧ избыточен. Я так понял, что вторая ТЧ избыточна. И соответственно обосновываю как вторую, так и первую ТЧ справочника. AHDPНапомню, т.к. два ваших последних топика не имеют никакого отношения к моему вопросу, меня интересовало чем был обусловлен выбор справочника по сравнению с регистром сведений. С точки зрения разработки и поддержки - Вас понимаю. Со стороны sql server и дальнейшего вашего обоснования - нет. Напомню вам, что в обоснование своих слов я предоставил вам алгоритмы, архитектуру, тесты и ссылки. Может я от вас увижу критику на таком же уровне, а не пространные рассуждения про сторону SQL сервера? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2018, 01:28 |
|
|
start [/forum/topic.php?all=1&fid=28&tid=1518335]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
165ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
77ms |
get tp. blocked users: |
1ms |
others: | 12ms |
total: | 295ms |
0 / 0 |