Здравствуйте, gandjustas, Вы писали:
G>Тонкий клиент получает минимум данных, необходимых для отображения, причем можно организовать локальное кеширование на timestamp и rowversion (как в HTTP) для оптимизации. Самое главное что такой кеш не требует дополнительных приседания для поддержания его когерентности. G>В случае с локальной репликой, как ты сам говорил, требуют ссылочно-целостного подмножества данных, чтобы не пришлось разруливать конфликты целостности на сервере. Поддержание когерентности такой реплики при постоянно меняющихся данных требует больше ресурсов, как на клиенте, так и на сервере.
На самом деле всё не так. Если клиент видит не все данные, то изменение данных, которые он не видит поменяет timestamp/rowversion и приведёт к лишней загрузке данных. То есть либо эффективность использования кеша конкретным тонким клиентом зависит от активности остальных (не масштабируемая система), либо мы тратим ресурсы сервера (а именно они дорогие, на клиента плевать) на поддержание персональных timestamp/rowversion.
G>Единственный вариант, когда локальная реплика может оказаться предпочтительнее — когда для нормальной работы не требуются 100% актуальные данные, а сама реплика по размеру не велика. Пример такому — торговые терминалы.
Ну да. А антипример можно?
A>>Далее. Тонкие клиенты не позволяют работать в offline режиме, накапливая изменения. Мобильные сотрудники в связи с дешевизной мобильных компьютеров становятся всё более распространены. Работа в online режиме всегда хорошо, но не всегда возможно. Отсутствие связи не повод для отказа. Тут пошли разговоры про 99.999% аптайма каналов связи. Я не считаю что стоит полагаться на аптайм канала связи. G>С мобильными компьютерами разщвивются и мобильные средства связи. Поэтому получить соединение — не проблема.
Получить соединение вообще никогда не было проблемой. Проблема — постоянно иметь соединение.
G>Многе сознательно отказываются от толстых клиентов в пользу веб-приложений чтобы избежать проблем с деплоем.
Веб-приложение это очень простой и негибкий кеш (а wireless провайдеры тарифицируют трафик) и убогий интерфейс. К тому же это не приемлемо из административных соображений. Как показала практика — главная проблема для покета — это позволить запускать только фронт-офис. Несознательные личности, пользуясь корпоративными картами, оплачивают сервисы (оценки на грёбаных одноклассниках), качают порно и что только ещё не делают. Позволить запускать IE или любой другой браузер просто крайне дорого. При стоимости необходимых компании услуг в 3$, приходят счета на 50-100$. Это, конечно, разбирается, вычитается из зарплаты, бывают увольнения. Но практика показала, что покет должен быть в kiosk mode, иначе его эксплуатация обойдётся очень-очень дорого. Если сравнить необходимые человеческие ресурсы, какой-то там деплоймент это сущие пустяки. Кроме того есть системы прошивки покетов, которые значительно упрощают процесс.
G>как уже написал выше в случае частых обновлений и необходимости иметь последние данные для корректной работы локальная реплика гораздо менее выгодна.
Но предметной области так и не привёл, а я сам такую не припомню. Можно конкретики?
G>Требовать работоспособность канала — громко сказано. Требовать у клиента такое неполчучается. Обычно клиент приходит со своими параметрами и надо подбирать решенее, наиболее удовлетворяющее этим параметрам. G>Только можно выбирать исходя из пессимистичных соображений, типа "связи с сервером вероятнее всего не будет", или из оптимистичных — "связь таки будет".
Админы делятся на две категории: те, которые уже делают резервные копии, и те, которые ещё не делают.
Вот я уже не считаю что "связь таки будет". И делаю резервные копии
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Тонкий клиент получает минимум данных, необходимых для отображения, причем можно организовать локальное кеширование на timestamp и rowversion (как в HTTP) для оптимизации. Самое главное что такой кеш не требует дополнительных приседания для поддержания его когерентности. G>>В случае с локальной репликой, как ты сам говорил, требуют ссылочно-целостного подмножества данных, чтобы не пришлось разруливать конфликты целостности на сервере. Поддержание когерентности такой реплики при постоянно меняющихся данных требует больше ресурсов, как на клиенте, так и на сервере.
A>На самом деле всё не так. Если клиент видит не все данные, то изменение данных, которые он не видит поменяет timestamp/rowversion и приведёт к лишней загрузке данных.
Это неверно. Timestamp выбирается максимальный из выборки видимых записей. Синклер приводил запрос для получения дельты.
A>То есть либо эффективность использования кеша конкретным тонким клиентом зависит от активности остальных (не масштабируемая система)
В случае с репликой зависимость конкретного клиента от деятельности остальных еще больше. Не надо все сводить к случаю когда каждый клиент работает с изолированным куском данных, на практике такие случаи — редкость.
A>либо мы тратим ресурсы сервера (а именно они дорогие, на клиента плевать) на поддержание персональных timestamp/rowversion.
Персональные timestamp/rowversion держит клиент и передает при каждом запросе данных.
G>>Единственный вариант, когда локальная реплика может оказаться предпочтительнее — когда для нормальной работы не требуются 100% актуальные данные, а сама реплика по размеру не велика. Пример такому — торговые терминалы. A>Ну да. А антипример можно?
Wiki
A>Получить соединение вообще никогда не было проблемой. Проблема — постоянно иметь соединение.
А зачем? Достаточно иметь возможность подключиться в любой момент.
G>>Многе сознательно отказываются от толстых клиентов в пользу веб-приложений чтобы избежать проблем с деплоем.
A>Веб-приложение это очень простой и негибкий кеш (а wireless провайдеры тарифицируют трафик)
История показывает что самые простые решения оказываются самым эффективными. При правильном применении HTTP кеширование может быть очень эффективным.
A>и убогий интерфейс.
По сравнению с чем? Для бизнес-задач более чем хватает.
A>К тому же это не приемлемо из административных соображений. Как показала практика — главная проблема для покета — это позволить запускать только фронт-офис. Несознательные личности, пользуясь корпоративными картами, оплачивают сервисы (оценки на грёбаных одноклассниках), качают порно и что только ещё не делают. Позволить запускать IE или любой другой браузер просто крайне дорого. При стоимости необходимых компании услуг в 3$, приходят счета на 50-100$. Это, конечно, разбирается, вычитается из зарплаты, бывают увольнения. Но практика показала, что покет должен быть в kiosk mode, иначе его эксплуатация обойдётся очень-очень дорого. Если сравнить необходимые человеческие ресурсы, какой-то там деплоймент это сущие пустяки. Кроме того есть системы прошивки покетов, которые значительно упрощают процесс.
Мда... Решать проблемы быдлоперсонала тамими методами — это смешно.
Ктсати, кто мешает сделать kiosk-mode для браузера с одним адресом?
G>>как уже написал выше в случае частых обновлений и необходимости иметь последние данные для корректной работы локальная реплика гораздо менее выгодна. A>Но предметной области так и не привёл, а я сам такую не припомню. Можно конкретики?
В любой предметной области. вообще-то предметная область ортогональна архитектурным решениям.
Только не надо опять сводить к случаю, где каждый пользователь работает только со своей частью данных. Это практически тоже самое, что и однопользовательская система, а там вообще серверы не нужны.
Здравствуйте, gandjustas, Вы писали:
A>>На самом деле всё не так. Если клиент видит не все данные, то изменение данных, которые он не видит поменяет timestamp/rowversion и приведёт к лишней загрузке данных. G>Это неверно. Timestamp выбирается максимальный из выборки видимых записей. Синклер приводил запрос для получения дельты.
Во-первых, либо надо синхронизировать время между клиентом и сервером, либо с каждым запросом передавать timestamp. Сразу скажу, на практике работает только второй вариант То есть интерфейс мы уже усложнили. Далее, когда делать обновления? При каждой визуализации списка? Если нет, то когда кеш устаревает? В твоём случае однозначного ответа нет, в моём есть — при нарушении ссылочной целостности. Я хочу сказать что если ты не обновляешь список при каждой визуализации то сталкиваешься с очень серьёзными проблемами. А если обновляешь при каждой, то сталкиваешься с сильной нагрузкой на сервер. И мне совсем не ясно зачем это делать и какая тут выгода.
A>>То есть либо эффективность использования кеша конкретным тонким клиентом зависит от активности остальных (не масштабируемая система) G>В случае с репликой зависимость конкретного клиента от деятельности остальных еще больше. Не надо все сводить к случаю когда каждый клиент работает с изолированным куском данных, на практике такие случаи — редкость.
Надо уметь разделять БД в соответсвии с бизнес-процессами. Никогда не бывает чтобы за одно и тоже дело было одновременно ответственно много человек. Тогда будет бардак, что с программой, что без.
G>>>Единственный вариант, когда локальная реплика может оказаться предпочтительнее — когда для нормальной работы не требуются 100% актуальные данные, а сама реплика по размеру не велика. Пример такому — торговые терминалы. A>>Ну да. А антипример можно? G>Wiki
Wiki в частности и совместное редактирование вообще это совсем не антипример. Возьми любую систему контроля версий, тот же SVN. Да чего уж там, возьмём Mercurial, там полнейшая децентрализация. И ничего страшного, у каждого неактуальная реплика, все довольны. Давай более реалистичный антипример.
A>>Получить соединение вообще никогда не было проблемой. Проблема — постоянно иметь соединение. G>А зачем? Достаточно иметь возможность подключиться в любой момент.
Ну да, это я и имел ввиду. Иметь возможность подключиться в любой момент.
A>>и убогий интерфейс. G>По сравнению с чем? Для бизнес-задач более чем хватает.
Хватает и эффективно суть разные вещи. Хватает для всего даже командной строки.
A>>К тому же это не приемлемо из административных соображений. Как показала практика — главная проблема для покета — это позволить запускать только фронт-офис. Несознательные личности, пользуясь корпоративными картами, оплачивают сервисы (оценки на грёбаных одноклассниках), качают порно и что только ещё не делают. Позволить запускать IE или любой другой браузер просто крайне дорого. При стоимости необходимых компании услуг в 3$, приходят счета на 50-100$. Это, конечно, разбирается, вычитается из зарплаты, бывают увольнения. Но практика показала, что покет должен быть в kiosk mode, иначе его эксплуатация обойдётся очень-очень дорого. Если сравнить необходимые человеческие ресурсы, какой-то там деплоймент это сущие пустяки. Кроме того есть системы прошивки покетов, которые значительно упрощают процесс. G> G>Мда... Решать проблемы быдлоперсонала тамими методами — это смешно.
Это не смешно, это печально. Я патриотично верил что это местная проблема, но потом пообщался с российским коллегой. Там ситуация ещё хуже, покеты используют как флешки и таскают на них вирусы.
G>Кстати, кто мешает сделать kiosk-mode для браузера с одним адресом?
Вот уже просото не хочется. Поверишь, 6 месяцев шаг за шагом запрещаем разные способы отсылки СМСок, запретили tmail, Pocket Outlook, перехватываем открытие знакомых окон, если нельзя процесс запретить. И всё равно шлют, хотя уже догадываюсь как и прикрою лавочку. И это СМСки. А если будет браузер... О-о-о-о! Не хочу.
G>>>как уже написал выше в случае частых обновлений и необходимости иметь последние данные для корректной работы локальная реплика гораздо менее выгодна. A>>Но предметной области так и не привёл, а я сам такую не припомню. Можно конкретики? G>В любой предметной области. вообще-то предметная область ортогональна архитектурным решениям. G>Только не надо опять сводить к случаю, где каждый пользователь работает только со своей частью данных. Это практически тоже самое, что и однопользовательская система, а там вообще серверы не нужны.
Понимаешь, ты описываешь как всё классно у сферического коня в вакууме. Это не убедительно.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>На самом деле всё не так. Если клиент видит не все данные, то изменение данных, которые он не видит поменяет timestamp/rowversion и приведёт к лишней загрузке данных. G>>Это неверно. Timestamp выбирается максимальный из выборки видимых записей. Синклер приводил запрос для получения дельты.
A>Во-первых, либо надо синхронизировать время между клиентом и сервером, либо с каждым запросом передавать timestamp. Сразу скажу, на практике работает только второй вариант
И отлично работает.
A>То есть интерфейс мы уже усложнили.
Это того стоит.
A>Далее, когда делать обновления? При каждой визуализации списка? Если нет, то когда кеш устаревает? В твоём случае однозначного ответа нет, в моём есть — при нарушении ссылочной целостности. Я хочу сказать что если ты не обновляешь список при каждой визуализации то сталкиваешься с очень серьёзными проблемами. А если обновляешь при каждой, то сталкиваешься с сильной нагрузкой на сервер. И мне совсем не ясно зачем это делать и какая тут выгода.
Обновление какого списка имеется ввиду?
Ты видимо мало знаком с таким видом кеширования. В отличие от локальной реплики, одного паттерна для всех случаев обновления кеша при timestamp_ах нету. Надо в каждом случае подбирать наиболее эффективный вариант.
A>>>То есть либо эффективность использования кеша конкретным тонким клиентом зависит от активности остальных (не масштабируемая система) G>>В случае с репликой зависимость конкретного клиента от деятельности остальных еще больше. Не надо все сводить к случаю когда каждый клиент работает с изолированным куском данных, на практике такие случаи — редкость.
A>Надо уметь разделять БД в соответсвии с бизнес-процессами. Никогда не бывает чтобы за одно и тоже дело было одновременно ответственно много человек. Тогда будет бардак, что с программой, что без.
Не выдумывай. Во многих задачах с одними и теме же данными работает много человек. Большая часть сайтов такова, любые задачи документооборота и многое другое.
Если удается четко разделить данные мезду пользоватеоями, то достаточно иметь локальную БД и изредка синхронизироваться с центрльным сервером для обновления справочников и передачи статистики.
G>>>>Единственный вариант, когда локальная реплика может оказаться предпочтительнее — когда для нормальной работы не требуются 100% актуальные данные, а сама реплика по размеру не велика. Пример такому — торговые терминалы. A>>>Ну да. А антипример можно? G>>Wiki
A>Wiki в частности и совместное редактирование вообще это совсем не антипример. Возьми любую систему контроля версий, тот же SVN. Да чего уж там, возьмём Mercurial, там полнейшая децентрализация. И ничего страшного, у каждого неактуальная реплика, все довольны. Давай более реалистичный антипример.
Не путай теплое с мягким. в Wiki важно увидеть последние изменения как можно быстрее, а при коллективной разработке это не самое важное.
Кроме того в Wiki есть ссылочность, в отличе от исходных текстов.
A>>>и убогий интерфейс. G>>По сравнению с чем? Для бизнес-задач более чем хватает. A>Хватает и эффективно суть разные вещи. Хватает для всего даже командной строки.
Хватает чтобы эффективно решать задачи. Хочешь поспорить — посмотри гугловые приложения.
A>Это не смешно, это печально. Я патриотично верил что это местная проблема, но потом пообщался с российским коллегой. Там ситуация ещё хуже, покеты используют как флешки и таскают на них вирусы. A>Вот уже просото не хочется. Поверишь, 6 месяцев шаг за шагом запрещаем разные способы отсылки СМСок, запретили tmail, Pocket Outlook, перехватываем открытие знакомых окон, если нельзя процесс запретить. И всё равно шлют, хотя уже догадываюсь как и прикрою лавочку. И это СМСки. А если будет браузер... О-о-о-о! Не хочу.
Пока человек имеет прямой доступ к устройству, то совем запретить ему что-то делать не получится.
Проще через оператора запретить ходить на любые адреса, кроме определенных и запритеть пользоваться чем угодно, кроме GPRS\3G.
А вирусы на флешках — не беда если админ не совсем баран.
G>>>>как уже написал выше в случае частых обновлений и необходимости иметь последние данные для корректной работы локальная реплика гораздо менее выгодна. A>>>Но предметной области так и не привёл, а я сам такую не припомню. Можно конкретики? G>>В любой предметной области. вообще-то предметная область ортогональна архитектурным решениям. G>>Только не надо опять сводить к случаю, где каждый пользователь работает только со своей частью данных. Это практически тоже самое, что и однопользовательская система, а там вообще серверы не нужны. A>Понимаешь, ты описываешь как всё классно у сферического коня в вакууме. Это не убедительно.
Я тебе привожу примеры, а ты их снова пытаешься свести к своему паттерну.
Здравствуйте, gandjustas, Вы писали:
A>>Далее, когда делать обновления? При каждой визуализации списка? Если нет, то когда кеш устаревает? В твоём случае однозначного ответа нет, в моём есть — при нарушении ссылочной целостности. Я хочу сказать что если ты не обновляешь список при каждой визуализации то сталкиваешься с очень серьёзными проблемами. А если обновляешь при каждой, то сталкиваешься с сильной нагрузкой на сервер. И мне совсем не ясно зачем это делать и какая тут выгода. G>Обновление какого списка имеется ввиду? G>Ты видимо мало знаком с таким видом кеширования. В отличие от локальной реплики, одного паттерна для всех случаев обновления кеша при timestamp_ах нету. Надо в каждом случае подбирать наиболее эффективный вариант.
Именно это я и назвал "очень серьёзными проблемами".
A>>Надо уметь разделять БД в соответсвии с бизнес-процессами. Никогда не бывает чтобы за одно и тоже дело было одновременно ответственно много человек. Тогда будет бардак, что с программой, что без. G>Не выдумывай. Во многих задачах с одними и теме же данными работает много человек. Большая часть сайтов такова, любые задачи документооборота и многое другое.
Работает в смысле читает или в смысле создаёт и модифицирует? Для чтения ручное обновление совершенно нормальная ситуация. Вот ты как смотришь что сайт обновился, жмёшь Refresh? Надо различать кеширование объектной модели для создания и модификации объектов и отчёты, которые кешировать стоит крайне редко.
A>>Wiki в частности и совместное редактирование вообще это совсем не антипример. Возьми любую систему контроля версий, тот же SVN. Да чего уж там, возьмём Mercurial, там полнейшая децентрализация. И ничего страшного, у каждого неактуальная реплика, все довольны. Давай более реалистичный антипример. G>Не путай теплое с мягким. в Wiki важно увидеть последние изменения как можно быстрее, а при коллективной разработке это не самое важное.
В Вики ты жмёшь Refresh, а конечная страница (в отличие от markup source history) носит характер отчёта.
G>Кроме того в Wiki есть ссылочность, в отличе от исходных текстов.
Ну да, а #include, using что такое? Имена файлов в файле проекта?
A>>Хватает и эффективно суть разные вещи. Хватает для всего даже командной строки. G>Хватает чтобы эффективно решать задачи. Хочешь поспорить — посмотри гугловые приложения.
Да видел я гугловские приложения. Интерфейс богатый, но странный. Меня, например, раздражает. Кроме того, если бы всё было так замечательно с приложениями, никто бы не делал Google Chrome.
G>Пока человек имеет прямой доступ к устройству, то совем запретить ему что-то делать не получится. G>Проще через оператора запретить ходить на любые адреса, кроме определенных и запритеть пользоваться чем угодно, кроме GPRS\3G.
Это если оператор такое поддерживает. Нам отказали, хотя лично я пролил не менее полулитра раздражённых слюней. Да и вообще, привязывать GPRS карту к APN штука нетипичная. Кстати, тем которые отказали софт писал CBOSS афаик, так что даже на местную тупизну пожаловаться не могу.
G>А вирусы на флешках — не беда если админ не совсем баран.
Согласен, но если нет проблемы, то не надо платить за её решение.
A>>Понимаешь, ты описываешь как всё классно у сферического коня в вакууме. Это не убедительно. G>Я тебе привожу примеры, а ты их снова пытаешься свести к своему паттерну.
Ты в качестве примера привёл Вики. Вики это как бы не типично для ERP/CRM.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Далее, когда делать обновления? При каждой визуализации списка? Если нет, то когда кеш устаревает? В твоём случае однозначного ответа нет, в моём есть — при нарушении ссылочной целостности. Я хочу сказать что если ты не обновляешь список при каждой визуализации то сталкиваешься с очень серьёзными проблемами. А если обновляешь при каждой, то сталкиваешься с сильной нагрузкой на сервер. И мне совсем не ясно зачем это делать и какая тут выгода. G>>Обновление какого списка имеется ввиду? G>>Ты видимо мало знаком с таким видом кеширования. В отличие от локальной реплики, одного паттерна для всех случаев обновления кеша при timestamp_ах нету. Надо в каждом случае подбирать наиболее эффективный вариант.
A>Именно это я и назвал "очень серьёзными проблемами".
Это мелочи, по сравнению с синхронизацей реплики, особено без использования како-нибудь Sync Framework.
A>>>Надо уметь разделять БД в соответсвии с бизнес-процессами. Никогда не бывает чтобы за одно и тоже дело было одновременно ответственно много человек. Тогда будет бардак, что с программой, что без. G>>Не выдумывай. Во многих задачах с одними и теме же данными работает много человек. Большая часть сайтов такова, любые задачи документооборота и многое другое.
A>Работает в смысле читает или в смысле создаёт и модифицирует?
В смысле один читает, другой создает, а третий модифицирует.
A>Для чтения ручное обновление совершенно нормальная ситуация. Вот ты как смотришь что сайт обновился, жмёшь Refresh?
Жму, и мне приходи список форумов с заголовками и авторами последних сообщений.
В случае "ссылочно целостной реплики" надо полностью вытягивать и последнее сообщение, и автора полный объект форума (в котором можнет быть много полей).
Причем если объект форума хорошо кешируется, то последние сообщения и их авторы постоянно меняются.
Как в таком случае ограничить вытягивание лишних данных?
A>Надо различать кеширование объектной модели для создания и модификации объектов и отчёты, которые кешировать стоит крайне редко.
Имеет смысл учитывать чтобы накладные расходы на поддержание когерентности кеша не были выше среднего оверхеда на считывание данных на каждый запрос. Это не два полюса "объекты" и "отчеты", а целый континуум, и к каждой точке этого континуума можно применить некоторую политику кеширования.
Пример с форумами и последними сообщениями выше.
A>Ты в качестве примера привёл Вики. Вики это как бы не типично для ERP/CRM.
Да ну, а knowelege base на чем делать? Уж не на вордовских файлах.
Здравствуйте, gandjustas, Вы писали:
A>>Именно это я и назвал "очень серьёзными проблемами". G>Это мелочи, по сравнению с синхронизацей реплики, особено без использования како-нибудь Sync Framework.
Нет. То о чём говоришь ты это серия важных решений, а я говорю об абсолютно однозначной и очень простой логике. Ресурсоёмкость реализации я компенсировал генерацией кода.
A>>Для чтения ручное обновление совершенно нормальная ситуация. Вот ты как смотришь что сайт обновился, жмёшь Refresh? G>Жму, и мне приходи список форумов с заголовками и авторами последних сообщений. G>В случае "ссылочно целостной реплики" надо полностью вытягивать и последнее сообщение, и автора полный объект форума (в котором можнет быть много полей).
Есть данные только для чтения (на их основе не производится операций), то не надо сохранять ссылочную целостность. Ы?
A>>Ты в качестве примера привёл Вики. Вики это как бы не типично для ERP/CRM. G>Да ну, а knowelege base на чем делать? Уж не на вордовских файлах.
И где там такая страшная проблема актуальности данных? Ты вроде должен был привести пример, где была бы очень важна актуальность данных. А в примере с KB клиент увидит обновление через час из-за какого-нибудь squid'а.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Именно это я и назвал "очень серьёзными проблемами". G>>Это мелочи, по сравнению с синхронизацей реплики, особено без использования како-нибудь Sync Framework.
A>Нет. То о чём говоришь ты это серия важных решений, а я говорю об абсолютно однозначной и очень простой логике. Ресурсоёмкость реализации я компенсировал генерацией кода.
Технически это просто делается. А то что надо головой думать — это да.
A>>>Для чтения ручное обновление совершенно нормальная ситуация. Вот ты как смотришь что сайт обновился, жмёшь Refresh? G>>Жму, и мне приходи список форумов с заголовками и авторами последних сообщений. G>>В случае "ссылочно целостной реплики" надо полностью вытягивать и последнее сообщение, и автора полный объект форума (в котором можнет быть много полей).
A>Есть данные только для чтения (на их основе не производится операций), то не надо сохранять ссылочную целостность. Ы?
Во, уже лучше.
А теперь осталось отказаться от мысли что вообще нужны каке-то закешированные объекты для изменения данных и все будет ок.
A>>>Ты в качестве примера привёл Вики. Вики это как бы не типично для ERP/CRM. G>>Да ну, а knowelege base на чем делать? Уж не на вордовских файлах. A>И где там такая страшная проблема актуальности данных? Ты вроде должен был привести пример, где была бы очень важна актуальность данных. А в примере с KB клиент увидит обновление через час из-за какого-нибудь squid'а.
Ну если так рассуждать, тогда все можно.
На деле уже много раз встречал ситуацию, когда лаг в десять секунд между изменением данных и отображением результата другому пользователю не устраивал зказчика.
Здравствуйте, gandjustas, Вы писали:
A>>Нет. То о чём говоришь ты это серия важных решений, а я говорю об абсолютно однозначной и очень простой логике. Ресурсоёмкость реализации я компенсировал генерацией кода. G>Технически это просто делается. А то что надо головой думать — это да.
Ну и зачем думать о мелочах, когда можно не думать?
A>>Есть данные только для чтения (на их основе не производится операций), то не надо сохранять ссылочную целостность. Ы? G>А теперь осталось отказаться от мысли что вообще нужны каке-то закешированные объекты для изменения данных и все будет ок.
А нет, не откажусь
A>>И где там такая страшная проблема актуальности данных? Ты вроде должен был привести пример, где была бы очень важна актуальность данных. А в примере с KB клиент увидит обновление через час из-за какого-нибудь squid'а. G>Ну если так рассуждать, тогда все можно. На деле уже много раз встречал ситуацию, когда лаг в десять секунд между изменением данных и отображением результата другому пользователю не устраивал заказчика.
Любое кеширование, при возможности ручного обновления, не вызовет задержки. А обеспечить синхронное обновление без server push или параноидального client poll вообще нельзя.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Нет. То о чём говоришь ты это серия важных решений, а я говорю об абсолютно однозначной и очень простой логике. Ресурсоёмкость реализации я компенсировал генерацией кода. G>>Технически это просто делается. А то что надо головой думать — это да. A>Ну и зачем думать о мелочах, когда можно не думать?
Грамотное кеширование — не мелочи.
A>>>Есть данные только для чтения (на их основе не производится операций), то не надо сохранять ссылочную целостность. Ы? G>>А теперь осталось отказаться от мысли что вообще нужны каке-то закешированные объекты для изменения данных и все будет ок. A>А нет, не откажусь
Ну и зря.
A>>>И где там такая страшная проблема актуальности данных? Ты вроде должен был привести пример, где была бы очень важна актуальность данных. А в примере с KB клиент увидит обновление через час из-за какого-нибудь squid'а. G>>Ну если так рассуждать, тогда все можно. На деле уже много раз встречал ситуацию, когда лаг в десять секунд между изменением данных и отображением результата другому пользователю не устраивал заказчика.
A>Любое кеширование, при возможности ручного обновления, не вызовет задержки. А обеспечить синхронное обновление без server push или параноидального client poll вообще нельзя.
А оно и не нужно, нужно чтобы в начале бизнес-транзакции данные были в акуальном состоянии.
Причем желательно не заставлять пользователя жать кнопку "обновить" и курить пока локальная реплика синхронизируется.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Ну и зачем думать о мелочах, когда можно не думать? G>>Грамотное кеширование — не мелочи.
A>Оно не мелочи только с твоим подходом, потому что оно не прозрачно.
У меня все прозрачно. Для тебя может быть непрозрачно потому что этого не понимаешь.
A>Я его вообще не замечаю. Просто откуда-то взялись данные... при таком подходе быстродействием не пахнет.
Здравствуйте, gandjustas, Вы писали:
A>>Оно не мелочи только с твоим подходом, потому что оно не прозрачно. G>У меня все прозрачно. Для тебя может быть непрозрачно потому что этого не понимаешь.
Тебе надо думать о кешировании, как минимум о стратегии.
A>>Я его вообще не замечаю. Просто откуда-то взялись данные... G> при таком подходе быстродействием не пахнет.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Оно не мелочи только с твоим подходом, потому что оно не прозрачно. G>>У меня все прозрачно. Для тебя может быть непрозрачно потому что этого не понимаешь. A>Тебе надо думать о кешировании, как минимум о стратегии.
A>>>Я его вообще не замечаю. Просто откуда-то взялись данные... G>> при таком подходе быстродействием не пахнет. A>Напротив, всё шикарно
Ну да, у тебя же каждый пользователь работает только со своим куском.
Здравствуйте, EvilChild, Вы писали:
VD>>Динамическое приведение может и есть, но вот ошибки типов быть не может, так как тип изначально закрытый (известны все вхождения) и можно проверить правильность приведения еще во время компиляции. Более того, сама конструкция match (case и т.п.) предусматривает только перечисление конкретных типов и одного случая в случае если ни один из перечисленных случаев не работает. Так что ошибки быть не может. EC>Я именно об этом и толкую. EC>Динамическому приведению типа всё равно там делать нечего.
Это не так. Вариант (в терминах немерла) — это базовый тип имеющий ряд подтипов. Ссылка на какой из подтипов была помещена в переменную можно узнать только в рантайме.
Просто динамическое приведение типов не имеет никакого отношения к динамической типизации. Это один из видов полиморфизма. Список типов известен в момент компиляции, а конкретный определяется в рантайме. Но весь код статически типизирован. И это главное, так как динамический код от статического как раз и отличается тем, что первый может иметь ошибки типизации в рантайме, и тем, что все типы неизвестны о стадии выполнения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
EC>>Динамическому приведению типа всё равно там делать нечего.
VD>Это не так. Вариант (в терминах немерла) — это базовый тип имеющий ряд подтипов. Ссылка на какой из подтипов была помещена в переменную можно узнать только в рантайме.
В F# сделано аналогично, но это артефакт реализации, такие типы компилятор помечет атрибутом CompilationMapping(SourceConstructFlags.SumType), чтобы отличать их от обычных.
Сделано так, думаю, исключительно исходя из простоты реализации, а не потому, что нам для реализации ПМ нужны динамические приведения типа.
В OCaml или Haskell уверен сделано совсем иначе.
VD>Просто динамическое приведение типов не имеет никакого отношения к динамической типизации. Это один из видов полиморфизма. Список типов известен в момент компиляции, а конкретный определяется в рантайме. Но весь код статически типизирован. И это главное, так как динамический код от статического как раз и отличается тем, что первый может иметь ошибки типизации в рантайме, и тем, что все типы неизвестны о стадии выполнения.
С этим полностью согласен.
Здравствуйте, vdimas, Вы писали:
EC>>Это всё хорошо, но где при паттерн матчинге происходит динамическое приведение типа?
V>В месте определения/сопоставления дискриминатора алгебраического типа. Для того же Nemerle — это динамическая проверка типа.
Так происходит исключительно потому, что алгебраические типы замапили на классы, которые уже есть у нас нахаляву в CLR.
С точки зрения системы типов приведений нет — это деталь реализации.
Здравствуйте, EvilChild, Вы писали:
EC>В F# сделано аналогично, но это артефакт реализации, такие типы компилятор помечет атрибутом CompilationMapping(SourceConstructFlags.SumType), чтобы отличать их от обычных. EC>Сделано так, думаю, исключительно исходя из простоты реализации, а не потому, что нам для реализации ПМ нужны динамические приведения типа. EC>В OCaml или Haskell уверен сделано совсем иначе.
А я уверен в обратно. Тип определяет то, что можно сделать с его экземпляром. В рантайме мы можем получить разные экземпляры разных типов. Стало быть не зная того, что за тип имеется в наличии нельзя с ним работать.
Другое дело, что само определение может сводится к банальной проверке некоторой целочисленной переменной которая точно имеется у всех АлгТД.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
при таком подходе быстродействием не пахнет.
