|
Данные 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 |
|
|
start [/forum/topic.php?fid=28&msg=39679786&tid=1518335]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
59ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
others: | 244ms |
total: | 407ms |
0 / 0 |