Здравствуйте, Геннадий Васильев, Вы писали:

IT>>Этого не может быть Насчёт скорости, ты попробуй кеширование поиспользовать, очень сильно помогает

ГВ>Может. Это даже теоретически несложно доказать. Если грубо, то получаем либо перемещение либо complete-state, либо state-delta (разницу между двумя состояниями). В общем — тут уже много было сказано по этому поводу.

Это всё красиво в теории. У тебя есть примеры из практики?

Здравствуйте, vdimas, Вы писали:

V>Могу пояснить малость.

Все твои пояснения и аргументы сводятся к тому, что задача stateful плохо решается средствами stateless. С этим я даже спорить не буду. Я утверждаю, что любую задачу можно решить в stateless архитектуре. Если не на все 100%, то как минимум на 90%. Например, в твоём случае можно было бы оставить редактирование документа на клиенте, либо же наоборот, хранить временное состояние в БД.

V>Т.е. я исходил из предположения, что вряд ли будет более 65536 клиентов или сотрудников или товаров. (идентификация объектов не сквозная, разумеется, у кажого типа объектов — свой счетчик)

Ну ОЧЕНЬ опасное предположение. Т.е. например, в моей фирме — даже просто ошибочное для товаров и, тем более, для клиентов.

Раз уж так подробно описываешь — расскажи про рабочие мощности системы — кол-во пользователей, объемы данных, и все такое.

Здравствуйте, Igor Trofimov, Вы писали:

V>>Т.е. я исходил из предположения, что вряд ли будет более 65536 клиентов или сотрудников или товаров. (идентификация объектов не сквозная, разумеется, у кажого типа объектов — свой счетчик)

iT>Ну ОЧЕНЬ опасное предположение. Т.е. например, в моей фирме — даже просто ошибочное для товаров и, тем более, для клиентов.

Охотно верю. Но это не меняет сути — необходимо пользоваться как можно более "узкими" типами. Например, код бухгалтерского счета все еще должен влезть в 65536. Ведь большинство объема данных в базах — это движения (не беру сейчас OLAP с его предвычесленными срезами). Запись о движениях — это обычно голые числовые строки данных, ссылающиеся на объекты системы. Я же говорю, когда мне удалось сузить до 16 бит все ID справочников, то получил на голом месте прирост быстродействия в 4 раза (!!!).


iT>Раз уж так подробно описываешь — расскажи про рабочие мощности системы — кол-во пользователей, объемы данных, и все такое.

Поначалу было примерно 30 операторов + 2 кассира + 2 буха + менеджер + директор. На каждом операторе в среднем 10-15 оптовых накладных в день. Накладные 100-300 строк, + накладные переучета раз в 2 недели по 3-5 тыс и более строк (что-то около 15 розничных точек). База на MS SQL. Росла в среднем на 5-8 метров в рабочий день.

Первая версия системы работала на 3-м пне 333MHz, 256 оперативки (2000-й год), к концу второго месяца эксплуатации стала малость притормаживать . Тогда-то и занялся оптимизацией всего и вся. После этого стала работать вполне сносно. Через 3 месяца поставили 3-й пень 800MHz, 512 RAM — стала просто летать.

Ну и как это читать?!

Здравствуйте, IT, Вы писали:

IT>>>Этого не может быть Насчёт скорости, ты попробуй кеширование поиспользовать, очень сильно помогает
ГВ>>Может. Это даже теоретически несложно доказать. Если грубо, то получаем либо перемещение либо complete-state, либо state-delta (разницу между двумя состояниями). В общем — тут уже много было сказано по этому поводу.
IT>Это всё красиво в теории. У тебя есть примеры из практики?

А зачем? Чтобы ты попытался доказать, что всё можно было бы решить с помощью stateless? Так я в этом и не сомневаюсь. Как и не сомневаюсь в том, что stateful мне нравится больше. Или затем, чтобы проверить, что 2x2=4? Ну так, для этого нужно две аналогичные системы с использованием statless/stateful написать — а на фига оно?

Здравствуйте, O-Sam, Вы писали:

OS>Ну и как это читать?!

Через Janus, вестимо.

Здравствуйте, Tom, Вы писали:

Tom>здесь много вкусного

А куда это теперь уехало???

Здравствуйте, <Аноним>, Вы писали:

Tom>>здесь много вкусного

А>А куда это теперь уехало???

http://www.theserverside.com/patterns/index.tss