В частности с самыми простыми. Например, что тренд завтра будет такой же как вчера. Или тренд завтра будет такого же знака как тренд вчера+позавчера с учетом величины отклонения? Или с «гусеницей»?
Я имел в виду, что с сервера приложений в базу идут параллельные запросы, каждый из которых в своей транзакции. То есть разруливание конкурентного доступа происходит на уровне базы, а не сервера приложений
Перечитал четвертый шаг. Получается вы несколькими «руками» параллельно лезете в бд.
Вижу 2 места для оптимизации (если она, конечно, там нужна).
1. Первичная загрузка справочника на клиент.
1.1. Можно сделать поэтапную загрузку. Справочник разбить по первым буквам. Требовать ввести первые три буквы, прежде чем грузить справочник. Сделать select TOP 20 после ввода первой буквы, select TOP 20 после второй итд — то есть каждый раз грузить только несколько первых подходящих записей итп.
1.2. Можно попробовать ужать передаваемые на клиент данные. Свой протокол придумать более сжатый. Ужать данные логически. Например, вместо datetime кидать разницу с предыдущим значением. Ужать данные физически — заархивировать и передать.
2. Последующие обновления данных на клиенте
Можно вообще нужные справочники закэшировать на сервере приложений. Изменения отслеживать там и скидывать в лог, по которому асинхронно обновлять бд.
А у вас кто-то кроме сервера приложений может обращаться к базе? Или есть несколько несвязанных способов изменить данные в бд через сервер приложений? Например интерфейс пользователя, и интерфейс оператора, редактирующего справочники. Оба лезут через сервер приложений, но кэш у них разный.
Не видел, к сожалению, консультант плюс. Но вряд ли на клиенте пользователю показывается сразу сто тысяч записей. Думаю, можно попилить выдачу. но это уже конкретное решение нужно смотреть.
Я, наверное, банальную вещь скажу.
Добавьте поле modified к каждому справочнику. Получайте с загрузкой данных текущее время и при обновлении грузите только записи с более поздней датой изменений. Без всяких дополнительных таблиц.
Грузите данные в фоне. Грузите данные по частям. 100000 записей в справочнике — это много. Неужели необходимо часто делать выбор из всего списка? Может проще поиск на сервере делать и возвращать только результат?
Прокомментируйте, пожалуйста, следующие ситуации (реально ли это, как таких ситуаций избежать, как разрулить итп):
1. Вася выполнял рабочие задачи. В ходе работы он изобрел алгоритм, который исключительно перспективен. Вася взял отгул, доработал алгоритм (описал полезную модель итп, вообщем оформил свои разработки в пригодном для патентования виде) и оформил на него патент. Вернулся на работу и предложил своей компании у него этот патент купить.
2. Вася со своим новым алгоритмом (разработанным в рамках служебных обязанностей) приехал на конференцию. В ходе конференции Петя прилюдно предложил несколько улучшений. Вася вставил их в алгоритм. Через полгода Петя потребовал себе выплат от компании Васи за использование его улучшений.
3. Вася разработал (в рамках служебных обязанностей) новый алгоритм. Он также использовал его (с некоторой модификацией) в собственном продукте, который выставил для общего безвозмездного использования. Компания конкурент использовала алгоритм из Васиного собственного продукта. Васина компани это обнаружила.
Я полагал, что иконка должна иллюстрировать идею, то есть от картинки до текста должно быть минимальное количество самых простых шагов. Поэтому на иконке «печать» обычно нарисован принтер, на иконке «отрезать» — ножницы и так далее. В данном случае я не смог самостоятельно сделать эти шаги. Разве что про патроны я предполагал нечто подобное, но сам бы выбрал другой вариант. Например в случае «разбитого сердца» нужно сделать аж четыре шага. Мне кажется это несколько противоречит подходу UX (ну или я просто туго соображаю).
Статья приятная, но выбор иконок для подписей удивляет.
Почему картинка, похожая на разбитое сердце, возле надписи «работаю UX дизайнером»?
Почему бензопила возле «принятия решений»?
Почему патроны возле «структуры информации»?
Почему горящая ёлка возле «описания взаимодействия»?
По крайней мере у меня две трети иконок никак или с трудом ассоциировались с подписью. Это как спросить который час и одновременно показать жест, как будто подносишь к губам сигарету. Что человек сделает: скажет сколько времени или угостит сигареткой? Так и задумано было?
В частности с самыми простыми. Например, что тренд завтра будет такой же как вчера. Или тренд завтра будет такого же знака как тренд вчера+позавчера с учетом величины отклонения? Или с «гусеницей»?
И что на рис.10 по оси Y отложено?
Вижу 2 места для оптимизации (если она, конечно, там нужна).
1. Первичная загрузка справочника на клиент.
1.1. Можно сделать поэтапную загрузку. Справочник разбить по первым буквам. Требовать ввести первые три буквы, прежде чем грузить справочник. Сделать select TOP 20 после ввода первой буквы, select TOP 20 после второй итд — то есть каждый раз грузить только несколько первых подходящих записей итп.
1.2. Можно попробовать ужать передаваемые на клиент данные. Свой протокол придумать более сжатый. Ужать данные логически. Например, вместо datetime кидать разницу с предыдущим значением. Ужать данные физически — заархивировать и передать.
2. Последующие обновления данных на клиенте
Можно вообще нужные справочники закэшировать на сервере приложений. Изменения отслеживать там и скидывать в лог, по которому асинхронно обновлять бд.
Не видел, к сожалению, консультант плюс. Но вряд ли на клиенте пользователю показывается сразу сто тысяч записей. Думаю, можно попилить выдачу. но это уже конкретное решение нужно смотреть.
Добавьте поле modified к каждому справочнику. Получайте с загрузкой данных текущее время и при обновлении грузите только записи с более поздней датой изменений. Без всяких дополнительных таблиц.
А вообще зависит от того, как вы хранение справочников организовали.
Про хранение на хабре вроде уже обсуждалось.
Грузите данные в фоне. Грузите данные по частям. 100000 записей в справочнике — это много. Неужели необходимо часто делать выбор из всего списка? Может проще поиск на сервере делать и возвращать только результат?
1. Вася выполнял рабочие задачи. В ходе работы он изобрел алгоритм, который исключительно перспективен. Вася взял отгул, доработал алгоритм (описал полезную модель итп, вообщем оформил свои разработки в пригодном для патентования виде) и оформил на него патент. Вернулся на работу и предложил своей компании у него этот патент купить.
2. Вася со своим новым алгоритмом (разработанным в рамках служебных обязанностей) приехал на конференцию. В ходе конференции Петя прилюдно предложил несколько улучшений. Вася вставил их в алгоритм. Через полгода Петя потребовал себе выплат от компании Васи за использование его улучшений.
3. Вася разработал (в рамках служебных обязанностей) новый алгоритм. Он также использовал его (с некоторой модификацией) в собственном продукте, который выставил для общего безвозмездного использования. Компания конкурент использовала алгоритм из Васиного собственного продукта. Васина компани это обнаружила.
Я полагал, что иконка должна иллюстрировать идею, то есть от картинки до текста должно быть минимальное количество самых простых шагов. Поэтому на иконке «печать» обычно нарисован принтер, на иконке «отрезать» — ножницы и так далее. В данном случае я не смог самостоятельно сделать эти шаги. Разве что про патроны я предполагал нечто подобное, но сам бы выбрал другой вариант. Например в случае «разбитого сердца» нужно сделать аж четыре шага. Мне кажется это несколько противоречит подходу UX (ну или я просто туго соображаю).
Почему картинка, похожая на разбитое сердце, возле надписи «работаю UX дизайнером»?
Почему бензопила возле «принятия решений»?
Почему патроны возле «структуры информации»?
Почему горящая ёлка возле «описания взаимодействия»?
По крайней мере у меня две трети иконок никак или с трудом ассоциировались с подписью. Это как спросить который час и одновременно показать жест, как будто подносишь к губам сигарету. Что человек сделает: скажет сколько времени или угостит сигареткой? Так и задумано было?