Комментарии 7
Отмечу серьёзные недостатки прямого получения данных:
вы забыли еще про блокировки, которые существуют в пространстве сервера приложений. Вы их обходите, а значит получаете грязное чтение.
Зачем вам в запросе упорядочивание? Думаю, оно не несет никакой нагрузки и его можно убрать.
Обработка с максимальной скоростью, потому что никто не любит, когда сайт тормозит.
Если вы заботитесь о скорости, то лучше архитектура доставляющая изменения, чем спрашивать много-много раз (исключения могут быть). Чем ближе будут лежать данные к клиенту, тем обычно быстрее их получается доставить, поэтому считаю лучше хранить актуальную копию данных на сайте, поддерживать ее актуальность доставкой изменений.
Упорядочивание нужно для того, чтобы получить последний документ с указанным в отборе номером. В БД может быть несколько документов с одинаковым номером, например, за разные годы.
С доставкой изменений полностью согласен - это гораздо лучшее решение. Рассмотренная ситуация - это только упрощённый пример. Суть исследования в том, чтобы понять, насколько прямой доступ даст ускорение.
Грязное чтение возможно, но оно далеко не всегда будет проблемой.
Упорядочивание нужно для того, чтобы получить последний документ с указанным в отборе номером. В БД может быть несколько документов с одинаковым номером, например, за разные годы.
Тогда бы было упорядочивание по дате, а у вас по idref (16 байтный UUID) - полагаться на него, что он будет выдавать возрастающие строки с течением времени нельзя (а еще направление сотировки - обратное - убывание desc). Я бы в принципе выкинул отсюда упорядочивание как довольно затратную процедуру, ограничившись диапазоном дат (вроде "полгода назад максимум").
Мне кажется задачу надо решать иначе. При изменении/вставки/удалении статуса - записывать данные в регистр сведений изменения или использовать план обмена. Либо 1С периодически (регл.задание), либо сайт периодически читает данные изменения - экспортирует их и соответственно очищает.
Да, правильнее передавать изменения из одной системы (например, 1С) в другую (например, сайт) в момент, когда они возникают. Не забыть, в ответе должно быть подтверждение, что сообщение принято и обработано. Так будет быстрее и правильнее. Но к сожалению доступ и возможность влиять на "ту сторону" есть далеко не всегда. Т. е. мы должны предоставить интерфейс, откуда будут забирать данные. Если интерфейс может быть неторопливым, тогда вопросов нет - делаем штатными средствами. Планы обмена, регламентные задания, http-сервисы - это всё работает в 2-3 раза медленнее, чем прямой доступ. Рассмотренный в исследовании пример - это всего лишь пример.
Получение данных для сайта из 1С: Предприятие (на примере статусов заказов Управление Торговлей 11.5)