С одной стороны, согласен. Стыд, позор и презрение. Но с другой стороны:
1. При нагрузочном тестировании эта фича никак не проявила себя. Она и после релиза не скзать, что прям сразу и стабильно проявлялась. Оптимизатор работал просто «странно» и иногда(!!!) выбирал абсолютно не адекватные индексы для построени планов.
2. В официальных требованиях от MS для Аксапты версии 2012, ничего не сказано об особенностях настройки БД в связке с SQL Server 2014+.
3. Принимая во внимание пункты 1 и 2, с чего бы нам было обратить внимание именно на эту фичу в списке изменений для новой версии?
Пост на самом деле адресован компаниям, проектам, кто внедряет Аксапту, и у кого нет в штате матерых DBA, которые наверное сходу вспомнили про эту фичу при апгрейде. Возможно кому-то в будущем это поможет не наступить на эти же грабли.
Да, вы правы. Но поэтому в этом примере я и написал «Специфика данной таблицы такова, что данные в ней не хранятся. Но очень интенсивно добавляются\удаляются. Это, по сути, таблица-семафор.». Естественно, эта рекомендация применима только для этой таблицы.
1. При нагрузочном тестировании эта фича никак не проявила себя. Она и после релиза не скзать, что прям сразу и стабильно проявлялась. Оптимизатор работал просто «странно» и иногда(!!!) выбирал абсолютно не адекватные индексы для построени планов.
2. В официальных требованиях от MS для Аксапты версии 2012, ничего не сказано об особенностях настройки БД в связке с SQL Server 2014+.
3. Принимая во внимание пункты 1 и 2, с чего бы нам было обратить внимание именно на эту фичу в списке изменений для новой версии?
Пост на самом деле адресован компаниям, проектам, кто внедряет Аксапту, и у кого нет в штате матерых DBA, которые наверное сходу вспомнили про эту фичу при апгрейде. Возможно кому-то в будущем это поможет не наступить на эти же грабли.