Здравствуйте, TK, Вы писали:
TK>Не надо так утрировать. Документы отправляемые на сервер могут содержать достаточно много информации, что-бы считать веб метод обычной процедурой.
Не понял. У нас уже что — ООП от неООП отличается количеством информации, отправляемой на сервер? Странный подход.
Здравствуйте, TK, Вы писали:
TK>В случае с MS SQL на локальной машине использовать TCP/IP совсем не обязательно — он может использовать shared memory протокол. Скажу сразу — shared memory в сравнении с TCP/IP это не просто быстро, а очень быстро...
Как то не сочетаются высокая нагрузка, о которой речь и sql сервер вместе с сервером приложений на одной машине. А если нагрузка маленькая то к чему слова о плохой масштабируемости и нехватке памяти?
TK>Никто особенно не возражает, но не забываем, что у веб сервиса все таки есть какой никакой контекст.
Если использовать контекст, то это уже стейтфул модель, причем особо извращенным способом
Здравствуйте, Ведмедь, Вы писали:
AVK>>Если ты еще не в курсе то СОМ+ МС уже вобщем то похоронил
В>Как это похоронил... Весной помнится они заявили, что COM+ живее всех живых и таковым будет, только сольется с Web servic-ами и ремоутингом
С весенними ручьями он слился Вобщем утекает COM+ (да и COM вообще) как песок через пальцы...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
>> Предположение 1. Если режим == стейтлесс и используются Serializable объекты на стороне клиента, значит из (1) и (2) вся работа, связаная с бизнес логикой выполняется через вызовы Serviced объекта (т.е. по сути вызов процедур сервера).
TK>Не совсем так... Не зря пртокол назвается SOAP и Web метод тоже не спроста.
Сорри не верно выразился... Serviced объект — это как раз имеется в виду WebService.
>> Следствие 1. из (3) получаем, что методы объекту, который отдается клиенту как бы и не нужны (все равно он все должен на сервере делать) единственное, что нужно объекту, который отдается клиенту — методы для некоего упрощения отображения, >> типовых операций, которые можно сделать и в виде внешних классов на клиенте. >> То есть в случае, если верно (3) — стейтлесс получается не ООП, а процедурным программированием, что откатывает нас назад в развитии программирования, так как почти ничем не отличается от RDBMS
TK>Ну, самый простой бизнес процес из нашей, так сказать, жизни. TK>Вот собрался Синклер приехать к нам 15-го на встречу, ну и пообщаться тоже. На работе ему это оформляют под это дело командировку, дают командировочные, когда приедет — устроится в гостинницу (может и нет — смотря по реализации), потом мы сходим в Ms, посидим там, дальше поедем пить пиво, купим пиццы и т.п. (кстати — предположим ему компания оплачивает только две пиццы, а купили 3), дальше пиво допили, разъехались, Синклер вернулся домой, отчитался за командировочные (а может и нет — ну, потерял бумажки) и на этом процесс завершился. Все предельно просто.
TK>Вот опиши в двух словах как используюя ООП (так чтоб с наследованием, полиморфизмом и никаких процедур) и statefull сервера реализовать платформу для выполнения данного бизнес-процесса (командировка, пиво, пицца, возврат назад, отдача командировочных и взаимо-расчет)?
Ты этта — не передергивай... после леммы есть признание что для некоторых задач стейтлесс будет не только вполне нормально пригоден без "ручной" версионности — более того, он будет даже более пригоден ( по скорости) чем стейтфул... так чт онефиг
>> Вывод 1. из (4) Режим с стейтлесс и использованием Serializable объектов, отдаваемых на сторону клиента не является работой ООП, так как гонять что-либо сложнее структур нет никакого смысла — все равно все, что выполняется на клиенте требует копии кода на клиенте, а все, что выполняется на сервер требует вызовов сервера в стиле процедурного программирования, а не ООП.
TK>Не надо так утрировать. Документы отправляемые на сервер могут содержать достаточно много информации, что-бы считать веб метод обычной процедурой.
Тем не менее... какая разница? мы посылаем ДАННЫЕ вместо того, чтобы вызвать метод бизнес объекта.. значит — процедурный подход (где-то в соседней ветке было про всеобщее заблуждение по поводу ООП/Не ООП) >> Предположение 2. Пусть режим стейтлесс и используется не Serializable объекты, а MBR.
TK>А зачем использовать стейтлесс и MBR? Или это доказательство по индукции (типа так полохо, так тоже плохо — значит по любому плохо)?
В точку!
>> Утверждение 3. из (6) мы получаем ровно две стратегии для соблюдения атомарности изменений: >>
>> Стратегия № 1 ( известная как pessimistic locking + Repeatable Read): Мы должны блокировать объект, к которому кто-то получил доступ. Иначе, при начале изменений этим кем-то, все, кто уже получили тот же объект на чтение, будут иметь неактуальные (частичные) данные. В данной стратегии развития, мы получаем, что один человек, взявший в работу объект, не дает работать всем, кому этот объект нужен зачем-либо, пусть даже для join'ов.
TK>Ну это уже прошлый век. Никто так давно не делает...
Ну ты не прав... некоторым нужно делать именно так... кстати, если отвлечься от именно БД AppServer'ов и прочего — очень многие процессы внутри винды так и делают... да и поезда на перегонах ЖД таки стоят и ждут пока перегон (или сколько там? 2, 3, 4 ??? ) не освободится. Причем, вполне возможно, что один поезд уже проехал место, где должен остановиться второй. но второй все равно ждет (pessimistic locking в действии!)
>> стратегия №2 (на самом деле — их три, близких по смыслу, известных как Versioning, Read Commited, optimistic locking ) либо делать "скрытое копирование" (Versioning, Read Commited) с блокировкой на изменение объекта (Read Commited) или же просто блокировать объект с "отстрелом всех активных "читателей" (optimistic locking) при начале изменений объекта либо при начале транзакции.
TK>А зачем делать копирование, если и так используется stateless? Точно от противного...
MBR и не надо копировать??? ты что, на каждого клиента по копии держать бкдешь??? тогда это уже стейтфул — сервер знает, в чьем контексте какой объект..
так что — копирование on-demand.
>> >> Предположение 3. Вернемся к Предположению 1 (1). Итак, Serializable и мы позволяем клиенту делать с объектом(-ами) все, что угодно, а при пересылке его (их) на сервер проверяем валидность действий и либо принимаем транзакцию, либо отменяем. >> Следствие 4. из (11) мы получаем проблему. Если 10 человек взяли себе для просмотра объект и каждый решил его изменять (причем, с точки зрения сервера все это одновременно) — мы получим либо классическую проблему неадекватности данных "версионников" (кто последний — тот и прав), либо нам нужно делать блокировки, что подразумевает стейтфул модель данных, так как в стейтлесс блокировки невозможны, либо оповещать остальных клиентов об изменении данных и необходимости их обновить, что также требует хранения на сервере ВСЕХ контекстов ВСЕХ клиентов, что противоречит модели стейтлес.
TK>ты еще бы сказал про проблему версионников "кто последний тот и папа" — так вот, проблема эта от разврата. Делать надо все честно и по совести, если один успел, то все остальные желающие — даже и не суются и спокойно идут лесом. Либо синхронизирую свои данные до полной адекватности и повторяют попытку.
Ага! вот оно — таки pessimistic locking, а говоришь — никто не пользуется...
нет батенька, либо optimistic locking, либо pessimistic. без локов — не обойтись.
А реализовать все по схеме IT просто не выйдет — неверно это (вот если я хочу изменить только одно свойство, а кто-то в то же время другое — как это рулить в стейтлесс.
>> Вывод 4. Даже при использовании Serializable объектов, интерактивная система невозможна на основе стейтлес модели. >> Вывод 5. Из Выводов 1(5), 2(10) и 3 (13) мы видим, что построение интерактивных приложений, отображающих всегда актуальные данные, невозможно при использовании стейтлесс. >> [/list]
TK>Вобщем — какие-то не верные выводы... Можно тоже самое и про statefull написать.
Да ну? КАК ты добъешься актуальности данных в стейтлесс? будешь постоянно сдергивать с сервера "изменения за период времени"?? так это же твою сеть положит...
а сервер оповещать не сможет... он же стейтлесс — даже если он знает сколько у него клиентов — он что на каждый чих будет оповещать ВСЕХ???
а если их 100 000? >> стейтлес модель хороша только тогда, когда нам нужно выполнять резервирование/продажи, причем всякое действие не требует никакой интерактивности — то есть : >>
>>
>> мы взяли из "неизменного" источника товар
>> ввели количество
>> возможно исправили цену
>> Послали запрос и или получили success либо отопнуты по какой-либо причине (например — нет нужного количества товара
>>
>>
TK>Это совсем простая схема. В реальности — все на много сложнее.
Тем не менее — на таких задачах стейтлесс воистину рулит... стейтфул тут неудобнее.
>> TK>А может этих серверов нет просто потому, что нельзя в одном месте совместить плохо совместимые вещи? >> А может их нет потому, что просто никому не пришло в голову их делать, так как "не модно"? >> TK>так-же как и транзакции в памяти (зато быстро).
Транзакции в памяти... расплывчатое понятие... пояснишь?
Вот у меня есть некоторое понимание э-э-э..."транзакций в памяти" — оно вполне кислотно... расскажи, про что ТЫ говоришь...
>> TK>Почему-же нет? Грамотно организованное stateless приложение лучше подходит для перехода на offline работу... >> Да... возможно, но вот актуальность инофрмации в таком случае обеспечивать тем труднее, чем проще переход на оффлайн.
TK>Какие трудности видишь?
те же что уже писал — как добиться актуальности данных на клиенте, если у нас стейтлесс?.
>> >> Пример? Пожалуйста. Те же накладные нередко создаются с параметрами по умолчанию — ну там номер накладной, склад, можно даже номенклатуру по шаблону закачать... Собственно, сбор этих параметров вполне можно поручить App-серверу, что в критическом случае stateless-модели ляжет на сервер БД. В свою очередь, созданный документ именно в первые 3-5 минут после того, как оператор нажал на кнопку "Save" с вероятностью около 3% (по моим наблюдениям) подвергнется повторному редактированию или удалению — не тот киоск, не то имя, вообще всё не то. >> >> TK>Причем, все это время, данные будут сидеть в памяти app сервера. В то время как, stateless сервер уже давно обслуживать новые запросы, >> Читай выше, почему такая стратегия не жизненна в любом месте, где нужна строгость в соблюдении точности и актуальности данных.
TK>строгость в соблюдении точности и актуальности данных плохо согласуются с ручным / полу ручным вводом накладных. Так-же ничто не мешает и stateless делать все необходимые проверки.
А в стейтфул тебе НИЧЕГО делать не надо — сервер сам все сделает.
>> TK>SQL сервера достаточно хорошо подготовлены к сбоям питания. Непредсказуемых потерь (транзакции и все такое) — там не бывает... >> Да ну? они даже без потерь питания бывают... вот например есть диск, на котором лог файл.. пусть на этом диске есть всего 100 МБ свободного места если совершить достаточно длинную транзакцию — вся БД падает, причем — невосстановимо. самое забавное, что если ты двадцать раз изменяешь один и тот же объект — в лог пишется 20 записей (почему-то) а при отложеном до конца транзакции сбросе данных в БД места под лог вполне может хватить — все это случай из моего опфта... в транзакции было всего лишь 65000 объектов.
TK>В stateless у тебя вряд-ли будет задейтвованно такое количество объектов... все ориентированно именно на короткую работу.
то есть если мне нужно либо импортировать справочник товаров, либо не импортировать, НО ИМЕННО весь — все, стейтлесс отдыхает, да?
>> +1 плюс к тому же, можно в памяти хранить часть особо часто используемых индексов — это даст возможность еще больше разгрузить компьютер, так как на текущий момент самое узкое место всех AppServer'ов да и вообще серверов — это дисковая система. >>
TK>Ну, имитацию БД в рамках App сервера мы уже обсуждали...
Кто сказал про имитацию БД? я не предлагаю ЗАМЕНИТЬ БД или отказаться от БД...
я всего лишь говорю, что есть случаи, когди индексы в памяти настолько рулят, насколько никогда не рулили индексы в БД.
>> Да? насчет отложеных загрузок — я уже как-то приводил пример с графом объектов. >> представь себе, что объекты собраны в граф... нет, пусть будет дерево. в дереве — примерно ну например 64К объектов (совершенно реальная цифра — речь идет о справочнике товаров. >> Если мы берем вариант совсем без отложеной загрузки, то: >>
>> Либо мы утягиваем с сервера, при любом неосторожно запросе, весь граф объектов (а нам-то нужен был только один). >> Либо мы должны реализовывать отложеную загрузку своими руками, что сводит на нет одну из сильных сторон и аргументов в пользу AppServer'ов, ибо мы просто запрещаем таким образом хранить ссылочные данные. >>
TK>Вобщем — что-бы использовать stateless стоит пересмотреть архитектуру.
А ее нельзя пересматривать... либо мы имеем удобство разработки, то есть разработчик конечного приложения пишет что-т отипа:
Да, кстати, Остаток — не просто свойство, о обращение к картотеке с учетными карточками, то есть тоже некая выборка, о чем программист сидящий на конце клиента даже не знает И даже если знает, ему что — тащить на клиент всю картотеку?
Нет. Тогда надо либо делать специальную сущность ОстатокПоСкладу, либо же писать запрос к БД, который возвратит сумму в виде double, что опять неудобно — мы же говорим о работе в режиме ООП! В случае стейтфул можно в метаданных декларативно прописать, что вот этот самы Остаток есть SUM(balance) во всех карточек этого склада, для этого товара и AppServer спокойно выполнит этот запрос и вернет АКТУАЛЬНУЮ информацию, а не информацию на момент загрузки объекта в память клиента.
>> TK>С другой стороны — SQL Server он знает об эффективном хранении данных не по наслышке, добавим сюда возможности кеширования данных и выборки по различным критериям. >> Далеко не все. Проверено. >> Например — как в нем нормально хранить счетные данные типа вот такого: >>
у нас есть дерево и на каждом кровне нам нужно иметь в узле статистику по поддереву, которая считается рекрсивно.
>> Я думаю, что через известное отверстие даже такой случай можно будет разрулить с помощью indexed view, но какой ценой??? И сколько будет стоить изменение какой-либо части алгоритма?
>> В AppServer'е, использующем собственные (хранимые) индексы можно хранить даже такую экзотическую вещь.
TK>При желании — я в БД так-же могу построить индекс и по дереву. В чем приемущество AppServer который будет его каждый раз грузить на себя все данные и перестраивать индекс не ясно...
а зачем все данные??? что мешает пользоваться механизмом кеширования страниц подобным тому, который есть в MSSQL... и хранить эти страницы... да-да именно как коре бизнес объекты
>> TK>"взаимодействие с чем угодно" — это может обеспечивать любое стороннее приложение. К stateless / statefull архитектуре это имеет мало отношения... >> Ну не совсем.. часть данных, которые есть в AppServer'е могут быть, например, показаниями датчиков.. снимаемые в реальном времени. и ты об этом даже не узнаешь, так как они НИЧЕМ не отличаются от "обычных" бизнес объектов. >>
TK>Каждый датчик так-же может не отличаться от обчной stateless службы.
Ага, только его придется постоянно опрашивать клиенту, у в стейтфул сервер может оповестить заинтересованых клиентов о том, что значение поменялось.
>> А так — можно будет во многих случаях обойтись без этих специальных людий и посадить только одного такого Гуру (с большой буквы) который напишеть модуль O-R mapping'а и все. >>
TK>Вот читал форум по java — там до сих пор нормальные реализации O/R мапперов ищут. Так-же не забывай, что материализация объектов это тоже не самая быстрая операция.
Да, знаю... только в сетйтлес она происходит ну никак не реже, чем в стейтфул.. скорее — даже чаще.
>> правильно.. при увеличении производительности сервера цена сперва растет логарифмически, потом — экспоненциально (второе — совсем недолго) но в результате рост получается ниже линейного. Говорю как краеевед — я иногда железяками торгую, так что стараюсь быть в курсе.
TK>Что-же тогда google мега кластер не забабахали?
ну кто его знает
>> >> >> Да только вот незадача — как уже писалось выше ну не подходит стейтлес для интерактивных приложений... >>
TK>Это на твой взгляд
Да нет не на мой — наша контора занимается автоматизацией одного предприятия уже 13 лет. по скромным оценкам там от 500 до 1000 человеко-лет вложено.
И могу тебе сказать — большим предприятиям еще важнее актуальность информации, чем мелким. в конце концов, в мелком предприятии одну и ту же сущность могут менять один-два человека, а в больших счет идет на сотни.
>> TK>1. Центральная БД, не обязательно держать все данные на одной машине / таблице. Их можно распределять — это уменьшит количество блокировок, и нагрузку на конечный сервер. >> Насчет количества блокировок на отдельном сервере — согласен, а вот длительность блокировок будет длиннее, так как при завершении транзакции более сложной, чем изменение одной записи в одной некластеризованой таблице потребует (с большой вероятностью) согласования между серверами, распределенных транзакций, что лишь повысит нагрузку на сервер при блокировке... так что тяжело решить однозначно что тут лучше — от задачи зависит.
TK>что тебе так дался этот кластер? одну таблицу так-же можно на несколько серверов растащить... и без кластера.
я уже писал про кластеризованую таблицу. в данном случае имеется ввиду кластеризация как разделение одной сущности на несколько частей.
>> ЗЫ ко всему сразу... начал я писать этот ответ примерно в 09:00 по Москве, так что ежели чего пропустил — не обессудьте
TK>Мы тут так долго сотояние не держим =)
Ну, судя по перечитаному остальному треду — вполне...
... << RSDN@Home 1.1.2 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Ведмедь, Вы писали:
AVK>>>Если ты еще не в курсе то СОМ+ МС уже вобщем то похоронил
В>>Как это похоронил... Весной помнится они заявили, что COM+ живее всех живых и таковым будет, только сольется с Web servic-ами и ремоутингом
TK>С весенними ручьями он слился Вобщем утекает COM+ (да и COM вообще) как песок через пальцы...
Здравствуйте, Merle, Вы писали:
AVK>>А какой смысл фиксировать транзакцию в памяти? M>А это не я придумал..
А кто? Точно не я
M>Ну почитай сообщение ГВ с которого все началось. Он-то как раз пропагандирует отложенную запись в БД, то есть фактически фиксацию в памяти..
Отложеная запись это совершенно отдельный разговор. Мы же пока, надеюсь, говорим о stateless vs stateful.
Здравствуйте, Merle, Вы писали:
M>Правильно. Но по сценарию ГВ, с отложенной записью в БД, и закоммиченые тоже, поэтому durability и идет лесом.
Нет, если уж у нас запись отложеная то естественно ни о какой durability и речи быть не может. Все что можно съэкономить на записи в этом плане это при последующем чтении только что отмодифицированного объекта не лезть опять в БД.
M>Если же применяется UNDO схема — все не зафиксированные изменения держатся в памяти, то в силу того, что незафиксированых изменений, при большой нагрузке, может быть довольно много, будет происходить перерасход памяти. M>То есть сервер вносит изменения на диск, потому что в большинстве случаев так выгоднее.
Здравствуйте, Ведмедь, Вы писали:
В>Как это похоронил... Весной помнится они заявили, что COM+ живее всех живых и таковым будет, только сольется с Web servic-ами и ремоутингом
Ага, в экстазе. Причем настолько сольется что собственно от СОМ+ там почти ничего и не останется . ИМХО работу СОМ+ объектов в индиге через нетовский интероп сложно назвать нормальным развитием.
Здравствуйте, Sinclair, Вы писали:
S>Другой вопрос в том, что в такой технологии реализовать поиск по фамилии like 'Петр%' и зарплате > 5000 уже становится затруднительно, ибо надо правильно выбрать мап, по которому искать...
Здравствуйте, IT, Вы писали:
IT>Чушь полная. Все проверки которые можно сделать средствами БД нужно делать средствами БД.
А не передергиваешь? Нет, понятно что reference constraint нужно делать средствами БД, но городить навороченные триггеры точно не стоит. Вот у меня под боком живой пример. Обращение к одной из вьюх примерно в 200 раз медленнее прямого доступа к таблице. При этом вьюха отличается всего лишь проверками. Сервер приложений такую проверку сделает со свистом.
Здравствуйте, IT, Вы писали:
ГВ>>Во время, отведённое мне на разработку чего? А оптимизация... Не так страшен чёрт, как...
IT>Твоей системы конечно. Если у тебя это время не детерминировано, то тогда конечно. В противном же случае, запросы к объектной модели — это часть обеспечения функциональности системы. Так вот для написание и оптимизацию SQL запроса у меня уйдёт на порядок меньше времени чем у тебя на реализацию запроса к ОО модели.
Ну не скажи... B+Дерево пишется на коленке за 2 часа первый раз, а второй (я думаю) я напишу и того быстрее.. а если я его (вот извращение-то) напишу на MC++ в неменеджед классах с менеджед оберткой — оно вообще рулить будет.
А само исполнение запросов.. ну, могу тебе сказать, что в объектных системах SQL как таковой не нужен при запросах к бизнес данным. SQL нужен при запросе к хранилищу, а при запросе к бизнес данным все просто — у нас нет агрегирующих ыункций — раз и мы возвращаем объекты целиком — два (а иначе — это уже не ОО)
ГВ>>С какой это точки зрения кэш тем эффективнее, чем ближе к клиенту?
IT>Возьми хотя бы кеширование веб-страниц в веб-браузере. При повторном запросе никуда ходить не надо, HTML формировать не надо, даже самого интернета не надо. Страница лежит в кеше и всегда готова к отображению.
Ага... теперь смотрим по Ctrl+F5 ту же страницу.... упс, а она уже совсем другая незадача, однако...
... << RSDN@Home 1.1.2 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте, AndrewVK, Вы писали:
S>>Другой вопрос в том, что в такой технологии реализовать поиск по фамилии like 'Петр%' и зарплате > 5000 уже становится затруднительно, ибо надо правильно выбрать мап, по которому искать... AVK>Так с лайком и у sql-сервера не все шоколадно
Не, вот именно с таким лайком, как раз все шоколадно..
TK>[skip такому тестику]
>> >> попробуй выполнить и прочувствовать разницу. >> у меня профайлер сказал: >> M1 — 4,290 >> M2 — 165 >> >> Просто в последнее время стало модным забивать и забиватся на сервер БД. Ну не эффективно это во многих случаях и приходится ручками лепить довольно много. Не надо делать из сервера БД — спасателей, которые всегда спешат на помощь (c) TK.
TK>А теперь давай положим в эту табличку пару миллионов записей, и начнем выбирать данные из случайного места. И еще не забудь добавить в свой тестик обновление кеша — данные меняются и кеш надо иногда перезагружать. А для пущей реальности, добавим еще пару табличек роли — там какие-нибудь и еще какой-нибудь ерунды в том-же стиле... Плюс сделаем вид, пользователи иногда логинятся — так что, поищем еще и по имени... TK>И тогда, мы еще раз поиграем в спасателей. Только боюсь как-бы M2 не пролетел мимо дерева
А не надо везде, где не надо звать спасателей. У них работа другая. Я тебе хотел всего лишь показать, что не всегда правильно всё пихать на сервер БД. Умный кэш — это хорошее решение. Я ж не спорю, что база данных это зэ бэст. Я говорю, что можно сделать ещё лучше и мой тест — всего лишь тому подтверждение.
M>А когда ты ее начать успел? У тебя же все в памяти....
Ты меня совсем не понял. Вот скажем то о чм я говорю:
public class Foo
{
private String userName;
private String userPass;
public void Bar()
{
userPass = "123";
throw new SecurityException(); // вот после этого состояние userPass возвращается в исходное
}
}
Я не хотел ничего никуда на диск пихать. Я просто хотел сказать что это возможно и даже довольно красиво реализуется (я Так думаю )
IT>Сообщения у нас и так кешируются. Только не десять тысяч последних, а те к которым было недавнее обращение.
А толку то. Я имел в виду закэшировать скажем датасет с ~10000 сообщений. Что у нас самые частые операции? Я думаю
*чтение списка оглавления сообщений
*чтение списка сообщений некоторой темы
*чтение самого сообщения
Вот первые 2 пункта представляют собой довольно простые запросы. Если сделать нейкий кэш то работа должны ускорится довольно ощутимо. Ну нафига постоянно лазить в базу если у нас чтений на порядок больше чем записей.
Tom>>поправь меня если я тут это не прав в общем
IT>Неправ. Сообщения у нас кешируются не потому что sql сервер не успевает, а потому что расцветка синтаксиса тормозит. Вот и делай теперь выводы
Делаю. Надо её на клиента переносить. Причём и построение самого дерева тоже.
Здравствуйте, IT, Вы писали:
IT>Я боюсь, что ты не верно истолковал мои слова. Когда я говорю о целостности БД, я имею ввиду только проверку связей и допустимость значений. Т.е. FK и констрейнты. О тригерах я ничего не говорил.
Ну тогда и я неверно твои слова истолковал. ИМХО ты плохо выразился.
Здравствуйте, Tom, Вы писали:
Tom>Сделал мааааленький тестик. Если хранить таблицу users просто в датасете, то получается ~ 1mb per 1.000 users. Т.е всего 20mb пер олл юзерс. Можно ещё последних ~10 тысяч сообщений хранить. Вроде как памяти хватает а сиквел это должно порядочно разгрузить.
Хотелось бы только определится с тем кто виноват в тормозах. Может и не сиквел вовсе.
незадача, однако...
Мы уже победили, просто это еще не так заметно...
