Здравствуйте, EvilChild, Вы писали:
EC>Это всё хорошо, но где при паттерн матчинге происходит динамическое приведение типа?
Динамическое приведение может и есть, но вот ошибки типов быть не может, так как тип изначально закрытый (известны все вхождения) и можно проверить правильность приведения еще во время компиляции. Более того, сама конструкция match (case и т.п.) предусматривает только перечисление конкретных типов и одного случая в случае если ни один из перечисленных случаев не работает. Так что ошибки быть не может.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
EC>>Это всё хорошо, но где при паттерн матчинге происходит динамическое приведение типа?
VD>Динамическое приведение может и есть, но вот ошибки типов быть не может, так как тип изначально закрытый (известны все вхождения) и можно проверить правильность приведения еще во время компиляции. Более того, сама конструкция match (case и т.п.) предусматривает только перечисление конкретных типов и одного случая в случае если ни один из перечисленных случаев не работает. Так что ошибки быть не может.
Я именно об этом и толкую.
Динамическому приведению типа всё равно там делать нечего.
Здравствуйте, gandjustas, Вы писали:
G>>>И каким образом должно учитываться содержание? G>При желании сам разработчик может разбит документ на несколько.
Нет механизма client side includes, так что сам разработчик разбить документы на несколько не может.
G>Вне офиса много чего находится. Я вот сильно сомневаюсь что "большой бизнес", с использованием компьютеров (именно такой нас интересует), делается в сортире. G>Так что давай конкретнее.
Послушай, если ты не знаешь что такое "вне офиса", то это конечно очень странно. По-твоему строители, например, в кабинете сидят? Есть виды деятельности где большая часть сотрудников занимается не перекладыванием бумажек, а чем-то другим.
A>>Есть фирмы для которых пара часов в месяц не мелочь. Вот представь себе что так. G>Так они банально платят деньги чтобы получить 99,999% работосособности.
Ты такой аптайм ни за какие деньги не купишь, потому что работоспособность линии связи не в полной мере зависит от деятельности владельца линии.
G>Нужен, только не постоянно. G>Можно по расписаних синхронизироватся через супер-пупер надежный GSM\GPRS.
Это не решение. Например, в зависимости от размера добавленной стоимости может меняться налогообложение, поэтому очень важно иметь актуальные данные о себестоимости.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>>>И каким образом должно учитываться содержание? G>>При желании сам разработчик может разбит документ на несколько.
A>Нет механизма client side includes, так что сам разработчик разбить документы на несколько не может.
Есть, фреймы называется.
А уж с помощью AJAX вообще можно сделать все.
G>>Вне офиса много чего находится. Я вот сильно сомневаюсь что "большой бизнес", с использованием компьютеров (именно такой нас интересует), делается в сортире. G>>Так что давай конкретнее. A>Послушай, если ты не знаешь что такое "вне офиса", то это конечно очень странно. По-твоему строители, например, в кабинете сидят? Есть виды деятельности где большая часть сотрудников занимается не перекладыванием бумажек, а чем-то другим.
Еще раз напомню что нас интересует тот бизнес, который делается с применением компьютеров.
Cеть бабушек, торгующих семечками, нас не интересует.
A>>>Есть фирмы для которых пара часов в месяц не мелочь. Вот представь себе что так. G>>Так они банально платят деньги чтобы получить 99,999% работосособности. A>Ты такой аптайм ни за какие деньги не купишь, потому что работоспособность линии связи не в полной мере зависит от деятельности владельца линии.
Не надо устраивать плачи в пользу бедных, за деньги можно купить любой аптайм, существует резервирование каналов и прочая хрень, которая в разы уменьшает вероятность отключения.
G>>Нужен, только не постоянно. G>>Можно по расписаних синхронизироватся через супер-пупер надежный GSM\GPRS.
A>Это не решение. Например, в зависимости от размера добавленной стоимости может меняться налогообложение, поэтому очень важно иметь актуальные данные о себестоимости.
Не надо налоги считать по факту совершения проводки, отчетность сдается за период.
В 1С например "документы" — информация о движении средств, отделена от "регистов" — непосредственно учетных единиц. Правла проведения документов можно менять, поменяются регистры, но документы останутся теми же.
Здравствуйте, gandjustas, Вы писали:
A>>Нет механизма client side includes, так что сам разработчик разбить документы на несколько не может. G>Есть, фреймы называется. G>А уж с помощью AJAX вообще можно сделать все.
Эти все технологии имеют очевидные минусы. Например, нельзя получить адрес страницы.
A>>Послушай, если ты не знаешь что такое "вне офиса", то это конечно очень странно. По-твоему строители, например, в кабинете сидят? Есть виды деятельности где большая часть сотрудников занимается не перекладыванием бумажек, а чем-то другим. G>Еще раз напомню что нас интересует тот бизнес, который делается с применением компьютеров. G>Cеть бабушек, торгующих семечками, нас не интересует.
У тебя очень узкое понятие компьютера, вспомни о покетах.
G>>>Так они банально платят деньги чтобы получить 99,999% работосособности. A>>Ты такой аптайм ни за какие деньги не купишь, потому что работоспособность линии связи не в полной мере зависит от деятельности владельца линии. G>Не надо устраивать плачи в пользу бедных, за деньги можно купить любой аптайм, существует резервирование каналов и прочая хрень, которая в разы уменьшает вероятность отключения.
Видишь ли, резервирование каналов не работает, если кабели разных компаний лежат в одной траншее. То есть, конечно, можно себя убеждать что покупая тырнет у разных фирм ты что-то меняешь, но хорошо бы и с физической топологией ознакомиться для начала. Реальная альтернатива кабелям — беспроводные сети. К сожалению качество работы разных WiMAX пока не впечатляет, а GSM провайдеры берут дорого.
A>>Это не решение. Например, в зависимости от размера добавленной стоимости может меняться налогообложение, поэтому очень важно иметь актуальные данные о себестоимости. G>Не надо налоги считать по факту совершения проводки, отчетность сдается за период. G>В 1С например "документы" — информация о движении средств, отделена от "регистов" — непосредственно учетных единиц. Правла проведения документов можно менять, поменяются регистры, но документы останутся теми же.
Ага, ага. Вот почему в 1С есть понятие "восстановления последовательности" Нельзя считать налоги постфактум если от конечной цены меняются налоги. Такое документы надо проводить оперативно. Кстати, 1С в этом смысле полностью облажались предложив рассчитывать себестоимость раз в 5 минут.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Нет механизма client side includes, так что сам разработчик разбить документы на несколько не может. G>>Есть, фреймы называется. G>>А уж с помощью AJAX вообще можно сделать все. A>Эти все технологии имеют очевидные минусы. Например, нельзя получить адрес страницы.
Какой страницы?
A>>>Послушай, если ты не знаешь что такое "вне офиса", то это конечно очень странно. По-твоему строители, например, в кабинете сидят? Есть виды деятельности где большая часть сотрудников занимается не перекладыванием бумажек, а чем-то другим. G>>Еще раз напомню что нас интересует тот бизнес, который делается с применением компьютеров. G>>Cеть бабушек, торгующих семечками, нас не интересует. A>У тебя очень узкое понятие компьютера, вспомни о покетах.
Угу, все подряд строители, ассенизаторы и бабушки с семечками юзают покеты с установленными торговыми системами
Давай более предметно.
A>Видишь ли, резервирование каналов не работает, если кабели разных компаний лежат в одной траншее. То есть, конечно, можно себя убеждать что покупая тырнет у разных фирм ты что-то меняешь, но хорошо бы и с физической топологией ознакомиться для начала. Реальная альтернатива кабелям — беспроводные сети. К сожалению качество работы разных WiMAX пока не впечатляет, а GSM провайдеры берут дорого.
Не надо плачей в пользу бедных. Кому надо, те делают.
A>>>Это не решение. Например, в зависимости от размера добавленной стоимости может меняться налогообложение, поэтому очень важно иметь актуальные данные о себестоимости. G>>Не надо налоги считать по факту совершения проводки, отчетность сдается за период. G>>В 1С например "документы" — информация о движении средств, отделена от "регистов" — непосредственно учетных единиц. Правла проведения документов можно менять, поменяются регистры, но документы останутся теми же.
A>Ага, ага. Вот почему в 1С есть понятие "восстановления последовательности" Нельзя считать налоги постфактум если от конечной цены меняются налоги. Такое документы надо проводить оперативно. Кстати, 1С в этом смысле полностью облажались предложив рассчитывать себестоимость раз в 5 минут.
Ниче не понял, приведи пример что нужно сделать. А потом расскажи как локальная реплика поможет в этом случае и как часто надо её синхронизировать.
Здравствуйте, gandjustas, Вы писали:
G>>>А уж с помощью AJAX вообще можно сделать все. A>>Эти все технологии имеют очевидные минусы. Например, нельзя получить адрес страницы. G>Какой страницы?
Той которую видишь. Зайди на сайт RSDN.ru, открой в дереве слева список форумов, щёлкни на форуме, шёлкни вверху на сообщении в форуме. Сверху будет адрес — rsdn.ru. Это про фреймы. Про AJAX — в GoogleMaps, аналогичная ситуация. Прокручиваешь карту, масштабируешь, а адрес не меняется.
G>>>Cеть бабушек, торгующих семечками, нас не интересует. A>>У тебя очень узкое понятие компьютера, вспомни о покетах. G>Угу, все подряд строители, ассенизаторы и бабушки с семечками юзают покеты с установленными торговыми системами
Более предметно, практически все до кого дошёл прогресс ходят с покетами. То есть ты конечно можешь смотреть в окно на красивые, не тронутые человеком, пейзажи Мухосранска, но с покетами сейчас ходят представители практически всех родов деятельности: менеджеры, почтальоны, официанты, полицейские, лекторы, студенты и т.д. Если этого где-то ещё нет, то это вопрос отставания от прогресса, а не отсутствия необходимости.
A>>Видишь ли, резервирование каналов не работает, если кабели разных компаний лежат в одной траншее. То есть, конечно, можно себя убеждать что покупая тырнет у разных фирм ты что-то меняешь, но хорошо бы и с физической топологией ознакомиться для начала. Реальная альтернатива кабелям — беспроводные сети. К сожалению качество работы разных WiMAX пока не впечатляет, а GSM провайдеры берут дорого. G>Не надо плачей в пользу бедных. Кому надо, те делают.
Ясно, с темой не знаком вообще.
A>>Ага, ага. Вот почему в 1С есть понятие "восстановления последовательности" Нельзя считать налоги постфактум если от конечной цены меняются налоги. Такое документы надо проводить оперативно. Кстати, 1С в этом смысле полностью облажались предложив рассчитывать себестоимость раз в 5 минут. G>Ниче не понял, приведи пример что нужно сделать.
Что не ясного? На момент продажи надо знать себестоимость, так как от размера прибыли меняется налоговая ставка.
G>А потом расскажи как локальная реплика поможет в этом случае и как часто надо её синхронизировать.
ЛОЛ. Вообще-то тут обсуждалась необходимость постоянного соединения, а не локальной реплики. Надо не только писать, но и читать иногда.
Здравствуйте, adontz, Вы писали:
A>Той которую видишь. Зайди на сайт RSDN.ru, открой в дереве слева список форумов, щёлкни на форуме, шёлкни вверху на сообщении в форуме. Сверху будет адрес — rsdn.ru. Это про фреймы. Про AJAX — в GoogleMaps, аналогичная ситуация. Прокручиваешь карту, масштабируешь, а адрес не меняется.
Зайди на википамию, посмотри как такие проблемы побеждаются.
G>>>>Cеть бабушек, торгующих семечками, нас не интересует. A>>>У тебя очень узкое понятие компьютера, вспомни о покетах. G>>Угу, все подряд строители, ассенизаторы и бабушки с семечками юзают покеты с установленными торговыми системами A>Более предметно, практически все до кого дошёл прогресс ходят с покетами. То есть ты конечно можешь смотреть в окно на красивые, не тронутые человеком, пейзажи Мухосранска, но с покетами сейчас ходят представители практически всех родов деятельности: менеджеры, почтальоны, официанты, полицейские, лекторы, студенты и т.д. Если этого где-то ещё нет, то это вопрос отставания от прогресса, а не отсутствия необходимости.
Конкретно опиши процесс "большого бизнеса" в котором используются массово кпк без наличия постоянного соединения.
A>>>Видишь ли, резервирование каналов не работает, если кабели разных компаний лежат в одной траншее. То есть, конечно, можно себя убеждать что покупая тырнет у разных фирм ты что-то меняешь, но хорошо бы и с физической топологией ознакомиться для начала. Реальная альтернатива кабелям — беспроводные сети. К сожалению качество работы разных WiMAX пока не впечатляет, а GSM провайдеры берут дорого. G>>Не надо плачей в пользу бедных. Кому надо, те делают. A>Ясно, с темой не знаком вообще.
Знаком. А в общем какая разница.
Мало какому бизнесу требуется постоянное соединение, а какому требуется, те платят деньги и обеспечивают себе таковое. Принципиальных преград в этом нет.
A>Что не ясного? На момент продажи надо знать себестоимость, так как от размера прибыли меняется налоговая ставка.
С чего ты это взял? На момент продажи нужна цена. Остальное считается потом.
Здравствуйте, gandjustas, Вы писали:
A>>Более предметно, практически все до кого дошёл прогресс ходят с покетами. То есть ты конечно можешь смотреть в окно на красивые, не тронутые человеком, пейзажи Мухосранска, но с покетами сейчас ходят представители практически всех родов деятельности: менеджеры, почтальоны, официанты, полицейские, лекторы, студенты и т.д. Если этого где-то ещё нет, то это вопрос отставания от прогресса, а не отсутствия необходимости. G>Конкретно опиши процесс "большого бизнеса" в котором используются массово кпк без наличия постоянного соединения.
Дистрибуция. Агент приходит с покетом в магазин брать заказ или продавать. Никаких гарантий интернета на "чужой" территории нет и быть не может.
G>>>Не надо плачей в пользу бедных. Кому надо, те делают. A>>Ясно, с темой не знаком вообще. G>Знаком. А в общем какая разница. G>Мало какому бизнесу требуется постоянное соединение, а какому требуется, те платят деньги и обеспечивают себе таковое. Принципиальных преград в этом нет.
Речь изначально шла о том, что тонкие клиенты не выход в общем случае.
A>>Что не ясного? На момент продажи надо знать себестоимость, так как от размера прибыли меняется налоговая ставка. G>С чего ты это взял?
Есть такая штука — налоговое законодательство.
G>На момент продажи нужна цена. Остальное считается потом.
Цена может меняться в зависимости от объёма партии и клиента. В общем твои аргументы не в кассу, потому что я говорю о реальной ситуации возникшей с 1С.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Более предметно, практически все до кого дошёл прогресс ходят с покетами. То есть ты конечно можешь смотреть в окно на красивые, не тронутые человеком, пейзажи Мухосранска, но с покетами сейчас ходят представители практически всех родов деятельности: менеджеры, почтальоны, официанты, полицейские, лекторы, студенты и т.д. Если этого где-то ещё нет, то это вопрос отставания от прогресса, а не отсутствия необходимости. G>>Конкретно опиши процесс "большого бизнеса" в котором используются массово кпк без наличия постоянного соединения.
A>Дистрибуция. Агент приходит с покетом в магазин брать заказ или продавать. Никаких гарантий интернета на "чужой" территории нет и быть не может.
Заказать через инет из офиса не проще?
Если нельзя через инет, то все равно товар оприходуется на складе в момент получения, так что покет агенту для учиастия в процессе нафиг не нужен, только чтобы список хранить.
G>>>>Не надо плачей в пользу бедных. Кому надо, те делают. A>>>Ясно, с темой не знаком вообще. G>>Знаком. А в общем какая разница. G>>Мало какому бизнесу требуется постоянное соединение, а какому требуется, те платят деньги и обеспечивают себе таковое. Принципиальных преград в этом нет. A>Речь изначально шла о том, что тонкие клиенты не выход в общем случае.
По тезису, который я привел выше — очень даже выход.
Даже покеты чуть ли не поголовно умеют выходить в инет через GPRS\3g\WiMax.
A>>>Что не ясного? На момент продажи надо знать себестоимость, так как от размера прибыли меняется налоговая ставка. G>>С чего ты это взял? A>Есть такая штука — налоговое законодательство.
Есть, и что? Отчеты сдаются несколько раз в год.
G>>На момент продажи нужна цена. Остальное считается потом. A>Цена может меняться в зависимости от объёма партии и клиента. В общем твои аргументы не в кассу, потому что я говорю о реальной ситуации возникшей с 1С.
Да мне как-то все равно что в 1с возникало. Я говорю что нету принципиальной необходимости знать что-то кроме цены на момент продажи.
Поэтоу даже если вдруг в магазине не будет связи с головной конторой, то продать все равно можно.
А если речь идет о торговле b2b, то её сейчас вообще мало кто без инета делает (ну или факсом счета отправляют).
Здравствуйте, gandjustas, Вы писали:
A>>Дистрибуция. Агент приходит с покетом в магазин брать заказ или продавать. Никаких гарантий интернета на "чужой" территории нет и быть не может. G>Заказать через инет из офиса не проще?
Кому заказать из офиса?
Агенту? Там несколько тысяч позиций, куда записывать заказ, в блокнот?
Клиенту? Это уменьшит продажи дистрибуторской фирмы в разы.
G>Если нельзя через инет, то все равно товар оприходуется на складе в момент получения, так что покет агенту для учиастия в процессе нафиг не нужен, только чтобы список хранить.
Бу-га-га.
G>>>Мало какому бизнесу требуется постоянное соединение, а какому требуется, те платят деньги и обеспечивают себе таковое. Принципиальных преград в этом нет. A>>Речь изначально шла о том, что тонкие клиенты не выход в общем случае. G>По тезису, который я привел выше — очень даже выход. G>Даже покеты чуть ли не поголовно умеют выходить в инет через GPRS\3g\WiMax.
То что у покетов есть GPRS вовсе не означает что это хорошее решение. Я сталкивался на своём ропыте с ситуацийе когда кабельного интернета (оптика) не было твое суток, GSM связи не было около суток. Торговые агенты при этом продолжали брать заказы и вообще работали почти как обычно.
G>Я говорю что нету принципиальной необходимости знать что-то кроме цены на момент продажи.
Это не верно.
G>Поэтому даже если вдруг в магазине не будет связи с головной конторой, то продать все равно можно.
Вопрос — какие скидки делать?
G>А если речь идет о торговле b2b, то её сейчас вообще мало кто без инета делает (ну или факсом счета отправляют).
Речь идёт об очень простой штукенции. У тебя промо-акция, например, на каждые 5 купленных штук ты одну даришь. Это в среднем, можно на 24 подарить 5, а можно на 100 подарить 3. Прочие скидки (на позицию, на группу товаров, на общую сумму) тоже работают. Есть вдруг продаёшь ниже себестоимости платишь дополнительный налог на данную конкретную продажу. Когда делается отчёт, через год или через два, по фиг. Ты из себя строишь супер-опытного, но когда я говорю об элементарнейших сценариях выясняется что ты вообще ничего не смыслишь с реальных бизнес процессах реальных компаний. Это странно для супер-опытного.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Дистрибуция. Агент приходит с покетом в магазин брать заказ или продавать. Никаких гарантий интернета на "чужой" территории нет и быть не может. G>>Заказать через инет из офиса не проще?
A>Кому заказать из офиса? A>Агенту? Там несколько тысяч позиций, куда записывать заказ, в блокнот? A>Клиенту? Это уменьшит продажи дистрибуторской фирмы в разы.
Не выдумывай, полмира делает закупки удаленно, а ты все про агентов с покетами.
A>То что у покетов есть GPRS вовсе не означает что это хорошее решение. Я сталкивался на своём ропыте с ситуацийе когда кабельного интернета (оптика) не было твое суток, GSM связи не было около суток. Торговые агенты при этом продолжали брать заказы и вообще работали почти как обычно.
У нормальных людей b2b системы стоят на выделенных серверах хостеров, которые обеспечивают uptime 99.5%-99.9% (SLA)
G>>Я говорю что нету принципиальной необходимости знать что-то кроме цены на момент продажи. A>Это не верно.
Докажи. Только не указывая ограничения конкретных программ и конкретных процессов.
Я уверен что любой твой придуманный сценарий можно свести к необходимости только знать цену на момент продажи.
G>>Поэтому даже если вдруг в магазине не будет связи с головной конторой, то продать все равно можно. A>Вопрос — какие скидки делать?
Это зависит от способа идентификации клиента. Если карточка — то вполне достаточно алгоритма валидации карты и считывания величины скидки с нее.
Если требуется lookup по базе клиентов, то никуда не денешься, реплицировать надо или соединение держать.
В случае розницы карточки удобнее, в случае b2b — гораздо удеобнее удаленное взаимодействие (вплоть до автоматического) без хождения агентов или еще кого-то.
G>>А если речь идет о торговле b2b, то её сейчас вообще мало кто без инета делает (ну или факсом счета отправляют). A>Речь идёт об очень простой штукенции. У тебя промо-акция, например, на каждые 5 купленных штук ты одну даришь. Это в среднем, можно на 24 подарить 5, а можно на 100 подарить 3. Прочие скидки (на позицию, на группу товаров, на общую сумму) тоже работают. Есть вдруг продаёшь ниже себестоимости платишь дополнительный налог на данную конкретную продажу. Когда делается отчёт, через год или через два, по фиг.
Ну и? Что кроме цены надо знать на момент продажи?
Ведь вся информация сохраняется, сколько продали за раз, сколько дали в подарок итп.
Это является "документом", когда проводится в бухгалтерской системе оно становится набором проводок и все счиается нормально.
A>Ты из себя строишь супер-опытного, но когда я говорю об элементарнейших сценариях выясняется что ты вообще ничего не смыслишь с реальных бизнес процессах реальных компаний. Это странно для супер-опытного.
Конечно я не знаю рельных процессов компаний, с которыми ты работал.
А вообще не стоит на личности переходить.
Лучше аргументированно доказывай свою точку зрения, если в какой-то фирме процесс поставлен так как ты описываешь, то это не значит что это единственный вариант работы.
Здравствуйте, gandjustas, Вы писали:
A>>Клиенту? Это уменьшит продажи дистрибуторской фирмы в разы. G>Не выдумывай, полмира делает закупки удаленно, а ты все про агентов с покетами.
Не говори глупости, если не разбираешься в предметной области.
G>Докажи. Только не указывая ограничения конкретных программ и конкретных процессов. G>Я уверен что любой твой придуманный сценарий можно свести к необходимости только знать цену на момент продажи.
gandjustas, я говорю о реальной(!) ситуации. Это у тебя всё теория сплошная.
A>>Речь идёт об очень простой штукенции. У тебя промо-акция, например, на каждые 5 купленных штук ты одну даришь. Это в среднем, можно на 24 подарить 5, а можно на 100 подарить 3. Прочие скидки (на позицию, на группу товаров, на общую сумму) тоже работают. Есть вдруг продаёшь ниже себестоимости платишь дополнительный налог на данную конкретную продажу. Когда делается отчёт, через год или через два, по фиг. G>Ну и? Что кроме цены надо знать на момент продажи? G>Ведь вся информация сохраняется, сколько продали за раз, сколько дали в подарок итп. G>Это является "документом", когда проводится в бухгалтерской системе оно становится набором проводок и все счиается нормально.
gandjustas, я не думаю что ты и правда такой не умный. Я описал реальную проблему дистрибуторской компании, ты талдычишь опять своё, про годовой отчёт.
Объясняю ещё раз на пальцах. Агент пришёл к клиенту с покетом продать товар. Утром себестоимость была 10, днём, когда агент пришёл к клиету — 11.
После начисления всех скидок конечная цена стала 10.5. Компании выгоднее продать по 11 оформив 0 прибыли, чем продать по 10.5 и заплатить налог за продажу ниже себестоимости. Для этого надо знать текущую себестоимость. Для этого надо иметь связь. Ты почему-то этот простейший пример, ситуацию которая встречается не так уж редко, совершенно не понимаешь.
Здравствуйте, adontz, Вы писали:
A>Объясняю ещё раз на пальцах. Агент пришёл к клиенту с покетом продать товар. Утром себестоимость была 10, днём, когда агент пришёл к клиету — 11. A>После начисления всех скидок конечная цена стала 10.5. Компании выгоднее продать по 11 оформив 0 прибыли, чем продать по 10.5 и заплатить налог за продажу ниже себестоимости. Для этого надо знать текущую себестоимость. Для этого надо иметь связь. Ты почему-то этот простейший пример, ситуацию которая встречается не так уж редко, совершенно не понимаешь.
Теперь понял, сразу бы такой сценарий описал.
Ну и нужна связь, тонкий клиент в таком случае очень даже работает. Если всегда надо знать текущую себестоимость, то накакое кеширование на клиенте не спасет.
Здравствуйте, gandjustas, Вы писали:
A>>Объясняю ещё раз на пальцах. Агент пришёл к клиенту с покетом продать товар. Утром себестоимость была 10, днём, когда агент пришёл к клиету — 11. A>>После начисления всех скидок конечная цена стала 10.5. Компании выгоднее продать по 11 оформив 0 прибыли, чем продать по 10.5 и заплатить налог за продажу ниже себестоимости. Для этого надо знать текущую себестоимость. Для этого надо иметь связь. Ты почему-то этот простейший пример, ситуацию которая встречается не так уж редко, совершенно не понимаешь. G>Теперь понял, сразу бы такой сценарий описал. G>Ну и нужна связь, тонкий клиент в таком случае очень даже работает. Если всегда надо знать текущую себестоимость, то накакое кеширование на клиенте не спасет.
Боже, а кто говорил что от этого кеширование спасает? Ты вообще заметил что мы тут несколько вопросов обсуждаем?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Объясняю ещё раз на пальцах. Агент пришёл к клиенту с покетом продать товар. Утром себестоимость была 10, днём, когда агент пришёл к клиету — 11. A>>>После начисления всех скидок конечная цена стала 10.5. Компании выгоднее продать по 11 оформив 0 прибыли, чем продать по 10.5 и заплатить налог за продажу ниже себестоимости. Для этого надо знать текущую себестоимость. Для этого надо иметь связь. Ты почему-то этот простейший пример, ситуацию которая встречается не так уж редко, совершенно не понимаешь. G>>Теперь понял, сразу бы такой сценарий описал. G>>Ну и нужна связь, тонкий клиент в таком случае очень даже работает. Если всегда надо знать текущую себестоимость, то накакое кеширование на клиенте не спасет.
A>Боже, а кто говорил что от этого кеширование спасает? Ты вообще заметил что мы тут несколько вопросов обсуждаем?
Дык весь разговор начался с того что тонкий клиент применить не везде возможно именно по причине отсустствия постоянного соединения. Именно локальная реплика + синхронизация позволяют работать в таких условиях.
А в итоге ты привел пример где нужно постоянное соединение даже при работе с мобильным устройством.
Здравствуйте, adontz, Вы писали:
A>Объясняю ещё раз на пальцах. Агент пришёл к клиенту с покетом продать товар. Утром себестоимость была 10, днём, когда агент пришёл к клиету — 11. A>После начисления всех скидок конечная цена стала 10.5. Компании выгоднее продать по 11 оформив 0 прибыли, чем продать по 10.5 и заплатить налог за продажу ниже себестоимости. Для этого надо знать текущую себестоимость. Для этого надо иметь связь. Ты почему-то этот простейший пример, ситуацию которая встречается не так уж редко, совершенно не понимаешь.
Кстати этот сценарий тоже попадает в категорию необходимости знания только цены. Ведь агента мало интересует налоги и прочее, достаточно знать цену по которой надо продавать.
Здравствуйте, gandjustas, Вы писали:
A>>Боже, а кто говорил что от этого кеширование спасает? Ты вообще заметил что мы тут несколько вопросов обсуждаем? G>Дык весь разговор начался с того что тонкий клиент применить не везде возможно именно по причине отсутствия постоянного соединения. Именно локальная реплика + синхронизация позволяют работать в таких условиях. А в итоге ты привел пример где нужно постоянное соединение даже при работе с мобильным устройством.
Всё несколько не так. Давай я ещё раз объясню.
Тонкие клиенты без кеша тратят кучу ресурсов на обновление данных, если текущая ситуация часто меняется. Например, при смене адреса, браузер полностью загружает новую страницу даже если изменилась небольшая часть. Толстые клиенты, кеширующие данные и получающие разницу состояний, являются выходом из ситуации. Они не потратят ресурсы на частое обновление данных.
Вот. С этим по большому счёту никто и не спорил, насколько я заметил.
Далее. Тонкие клиенты не позволяют работать в offline режиме, накапливая изменения. Мобильные сотрудники в связи с дешевизной мобильных компьютеров становятся всё более распространены. Работа в online режиме всегда хорошо, но не всегда возможно. Отсутствие связи не повод для отказа. Тут пошли разговоры про 99.999% аптайма каналов связи. Я не считаю что стоит полагаться на аптайм канала связи.
Вот это и повод для спора: что делать? Ты предлагаешь требовать работоспособность канала. Я считаю это недопустимым. Ты предлагаешь кешировать результаты отдельных запросов, я считаю что лучше делать реплику, так как она строиться сложно, по ресурсам (трафик, место) выгоднее и функциональнее. Ты почему-то считаешь что с репликой сложнее работать.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Боже, а кто говорил что от этого кеширование спасает? Ты вообще заметил что мы тут несколько вопросов обсуждаем? G>>Дык весь разговор начался с того что тонкий клиент применить не везде возможно именно по причине отсутствия постоянного соединения. Именно локальная реплика + синхронизация позволяют работать в таких условиях. А в итоге ты привел пример где нужно постоянное соединение даже при работе с мобильным устройством.
A>Всё несколько не так. Давай я ещё раз объясню.
A>Тонкие клиенты без кеша тратят кучу ресурсов на обновление данных, если текущая ситуация часто меняется. Например, при смене адреса, браузер полностью загружает новую страницу даже если изменилась небольшая часть. Толстые клиенты, кеширующие данные и получающие разницу состояний, являются выходом из ситуации. Они не потратят ресурсы на частое обновление данных.
A>Вот. С этим по большому счёту никто и не спорил, насколько я заметил.
Как раз с этим и спорили, потому что твое утверждение неверно в общем случае.
Тонкий клиент получает минимум данных, необходимых для отображения, причем можно организовать локальное кеширование на timestamp и rowversion (как в HTTP) для оптимизации. Самое главное что такой кеш не требует дополнительных приседания для поддержания его когерентности.
В случае с локальной репликой, как ты сам говорил, требуют ссылочно-целостного подмножества данных, чтобы не пришлоль разруливать конфликты целостности на сервере. Поддержание когерентности такой реплики при постоянно меняющихся данных требует больше ресурсов, как на клиенте, так и на сервере.
Единственный вариант, когда локальная реплика может оказаться предпочтительнее — когда для нормальной работы не требуются 100% актуальные данные, а сама реплика по размеру не велика. Пример такому — торговые терминалы.
A>Далее. Тонкие клиенты не позволяют работать в offline режиме, накапливая изменения. Мобильные сотрудники в связи с дешевизной мобильных компьютеров становятся всё более распространены. Работа в online режиме всегда хорошо, но не всегда возможно. Отсутствие связи не повод для отказа. Тут пошли разговоры про 99.999% аптайма каналов связи. Я не считаю что стоит полагаться на аптайм канала связи.
С мобильными компьютерами разщвивются и мобильные средства связи. Поэтому получить соединение — не проблема.
Многе сознательно отказываются от толстых клиентов в пользу веб-приложений чтобы избежать проблем с деплоем.
A>Вот это и повод для спора: что делать? Ты предлагаешь требовать работоспособность канала. Я считаю это недопустимым. Ты предлагаешь кешировать результаты отдельных запросов, я считаю что лучше делать реплику, так как она строиться сложно, по ресурсам (трафик, место) выгоднее и функциональнее. Ты почему-то считаешь что с репликой сложнее работать.
как уже написал выше в случае частых обновлений и необходимости иметь последние данные для корректной работы локальная реплика гораздо менее выгодна.
Требовать работоспособность канала — громко сказано. Требовать у клиента такое неполчучается. Обычно клиент приходит со своими параметрами и надо подбирать решенее, наиболее удовлетворяющее этим параметрам.
Только можно выбирать исходя из пессимистичных соображений, типа "связи с сервером вероятнее всего не будет", или из оптимистичных — "связь таки будет".
Нельзя считать налоги постфактум если от конечной цены меняются налоги. Такое документы надо проводить оперативно. Кстати, 1С в этом смысле полностью облажались предложив рассчитывать себестоимость раз в 5 минут.
