Это всё очень актуально, когда сидишь на слабом канале и нужно закачать обновление или переустановить макось, т.к. обновление привело к спонтанным ребутам (речь про Соному как раз). Я не жалуюсь - хочешь быстрый проц, надо терпеть )
Кстати про "стандартные практики"... слишком мало проектов использует их в достаточной мере, как мне кажется. Хотя все они очень хороши при правильном использовании
Про «несколькими руками лезете в БД» мысль не понял. В моем случае несколько десятков пользователей одновременно работают над одним набором данных. Поэтому несколько рук — да, конечно. Но все «руки» контролируются сервером приложения.
1.1. Да, пожалуй. Вероятно к этому и приду, когда справочники разрастутся сверх всякой меры. В моем случае порции данных будут ощутимо больше, но суть от этого не меняется.
1.2. Протокол сейчас сжимается GZip'ом. Все пакеты на нижнем уровне (на уровне чуть выше сокетов в моем случае) пакуются, если их размер превышает 500 байт. Для меньшего размера издержки на паковку по времени превышают выигрыш, хотя это достаточно умозрительно и скорее игрища — практический смысл от такого ограничения я не тестировал.
Паковка с учетом специфики данных в каждом справочнике — это интересно :)
2. Мысль понял. Спасибо за идею! Хотя пока в моем случае запросы на модификацию не настолько частые.
Согласен. Но организация такой подгрузки (чтобы было быстро и удобно) — отдельная, довольно немаленькая задача. В случае с поисковиками у них выбора нет — все значения не передать в принципе. А у нас передача одного справочника целиком занимает доли секунды. Почему бы не передать…
Было бы здорово почитать об алгоритме такой динамической подгрузки. Интуитивно вроде всё понятно, но чует сердце, что подводных камней там в избытке :)
«А у вас кто-то кроме сервера приложений может обращаться к базе?»
Никто. Весь обмен идет только через сервер приложения.
«Но вряд ли на клиенте пользователю показывается сразу сто тысяч записей.»
Сейчас посмотрел справочник юридических номеров документов. В нем 174858 значений. Фильтрация этого справочника происходит на лету в момент ввода пользователем фильтра.
Спасибо за ссылку на аналогичную статью! Действительно, очень похоже. :) Но разница в том, насколько я понимаю, что там решения оптимальные для двузвенки, а меня — для трехзвенки.
«Неужели необходимо часто делать выбор из всего списка? Может проще поиск на сервере делать и возвращать только результат?»
Согласен, зачастую это рациональней.
Но в моей системе у многих справочников особенность UI — они должны быть полностью показаны пользователю. Не сказать, что особо рациональная особенность, но сделано по образу и подобию окна старого поиска в КонсультантПлюс.
Это уже обсуждалось в ветке ниже. Тяжеловесно получается.
Такое решение хорошо, когда каждое значение часто обновляется и имеет ценность независимо от других значений (прошу не бить за формулировку ;) ). Но это уже обычно не справочник.
«Но вот с точки зрения реализации апп-сервера разница есть. Никаких логов, транзакций и прочего мусора.»
Если у меня записи в таблице вида +<строка>, то как в этой таблице хранить версию?
Также получается, что хранение неунифицировано для справочников разных видов (есть справочники вида +<число>; +<дата> и т.п.). Или я не понял идею?
Да, согласен. Ваш способ отлично подходит также для двухзвенки. Сам я не стал нагружать сервер БД «лишними» запросами и триггерами, переложив эту функцию на сервер приложения.
Про версию для каждой записи: мне кажется, это чересчур тяжеловесно для компактных, редко изменяющихся записей (справочник изменяется часто, но т.к. записей очень много вероятность изменения каждой отдельной записи очень мала).
«Имеется в виду — начать грузить справочники раньше, чем они стали нужны.»
Наиболее объемные справочники подгружаются при старте программы. Но соль в том, что с момента старта и до момента начала работы они могут измениться. А это критично (пользователь гораздо больше доверяет системе, да и надежность выше, когда данные всегда актуальны).
«Ну и да, я раньше не заметил/не подумал, но информацию о версии справочника нужно хранить в самом справочнике, тогда вы избавитесь от значительной части проблем.»
С точки зрения клиентской части (у меня трехзвенка) это без разницы. Для нее справочник и его версия выглядят как одно целое. Похоже, я не понял Вашу идею.
Иваново, МТС домашний, не работает
Wi-Di для начала
Это всё очень актуально, когда сидишь на слабом канале и нужно закачать обновление или переустановить макось, т.к. обновление привело к спонтанным ребутам (речь про Соному как раз). Я не жалуюсь - хочешь быстрый проц, надо терпеть )
Да, всё так. Вы правы
Дистрибутив аскетичной macOS Sonoma занимает меньше 17 ГБ, не говоря уж про размеры минорных обновлений. Так что есть куда расти
"на 40% предыдущей модели"
Хочется это в отношении самого Fold5. А тоньше сделали стилус, который приятнее, когда толще, а не тоньше...
Кстати про "стандартные практики"... слишком мало проектов использует их в достаточной мере, как мне кажется. Хотя все они очень хороши при правильном использовании
Сейчас (в проекте, не относящемуся к my.games) используем только АппМетрику - сам подход работает практически так же хорошо
1.2. Протокол сейчас сжимается GZip'ом. Все пакеты на нижнем уровне (на уровне чуть выше сокетов в моем случае) пакуются, если их размер превышает 500 байт. Для меньшего размера издержки на паковку по времени превышают выигрыш, хотя это достаточно умозрительно и скорее игрища — практический смысл от такого ограничения я не тестировал.
Паковка с учетом специфики данных в каждом справочнике — это интересно :)
2. Мысль понял. Спасибо за идею! Хотя пока в моем случае запросы на модификацию не настолько частые.
Было бы здорово почитать об алгоритме такой динамической подгрузки. Интуитивно вроде всё понятно, но чует сердце, что подводных камней там в избытке :)
Никто. Весь обмен идет только через сервер приложения.
«Но вряд ли на клиенте пользователю показывается сразу сто тысяч записей.»
Сейчас посмотрел справочник юридических номеров документов. В нем 174858 значений. Фильтрация этого справочника происходит на лету в момент ввода пользователем фильтра.
«Неужели необходимо часто делать выбор из всего списка? Может проще поиск на сервере делать и возвращать только результат?»
Согласен, зачастую это рациональней.
Но в моей системе у многих справочников особенность UI — они должны быть полностью показаны пользователю. Не сказать, что особо рациональная особенность, но сделано по образу и подобию окна старого поиска в КонсультантПлюс.
Такое решение хорошо, когда каждое значение часто обновляется и имеет ценность независимо от других значений (прошу не бить за формулировку ;) ). Но это уже обычно не справочник.
Если у меня записи в таблице вида +<строка>, то как в этой таблице хранить версию?
Также получается, что хранение неунифицировано для справочников разных видов (есть справочники вида +<число>; +<дата> и т.п.). Или я не понял идею?
Про версию для каждой записи: мне кажется, это чересчур тяжеловесно для компактных, редко изменяющихся записей (справочник изменяется часто, но т.к. записей очень много вероятность изменения каждой отдельной записи очень мала).
Наиболее объемные справочники подгружаются при старте программы. Но соль в том, что с момента старта и до момента начала работы они могут измениться. А это критично (пользователь гораздо больше доверяет системе, да и надежность выше, когда данные всегда актуальны).
«Ну и да, я раньше не заметил/не подумал, но информацию о версии справочника нужно хранить в самом справочнике, тогда вы избавитесь от значительной части проблем.»
С точки зрения клиентской части (у меня трехзвенка) это без разницы. Для нее справочник и его версия выглядят как одно целое. Похоже, я не понял Вашу идею.
Да, вероятно. Оттуда и возникло желание написать статью об этом :)