|
Данные 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?fid=28&gotonew=1&tid=1518335]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
49ms |
get topic data: |
11ms |
get first new msg: |
7ms |
get forum data: |
2ms |
get page messages: |
62ms |
get tp. blocked users: |
2ms |
others: | 229ms |
total: | 395ms |
0 / 0 |