Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 79 80 81 82 83 [84] 85 86 87 88 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Изопропил
Sergei Obrastsov

Угу. То есть происходит обновление этого блока на клиентах. В чем проблема?

Обновление, или удаление тз кэша?


Не в курсе на 100% - но что Write Back стратегию уже отменили ?
9 янв 07, 19:50    [3618379]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
V52
Ниже изображены в М-представлении основные структуры данных по учету
товарно-материальных ценностей на предприятии. Некоторые мнемоники могут
быть непонятны, но это неважно для понимания сути вопроса.

^TMC(NN)=Naim,EDI,CodTipa,KolVUp,Rasfasovka,...

^Doc(Year,CMOL,PPV,NDC)=Date,CP,COP,Summa1,Summa2,Summa3,PID,YearR,MonthR
^Doc(Year,CMOL,PPV,NDC,1,NPP)=NN,Cena,Kol,Summa
^Doc(Year,CMOL,PPV,NDC,2,NPP)=CodNS,Summa
^Doc(Year,CMOL,PPV,NDC,3,1,NPP)=Deb,AD1,AD2,Cre,AC1,AC2,Summa
^Doc(Year,CMOL,PPV,NDC,3,2,NPP)=Deb,AD1,AD2,Cre,AC1,AC2,Summa

^Card(CMOL,NN)=OstN,Post,Vyb,OstK
^Card(CMOL,NN,Year,Month)=OstN,Post,Vyb,OstK
^Card(CMOL,NN,Year,Month,PPV)=Itogo
^Card(CMOL,NN,Yaer,Month,PPV,NPP)=Kol,NDC

^Rep(Year,Month,CMOL)=Summa1,Summa2,Status
^Rep(Year,Month,CMOL,NRep)=Summa1,Summa2,Status
^Rep(Year,Month,CMOL,NRep,PPV)=Summa,Status
^Rep(Year,Month,CMOL,NRep,PPV,NDC)=Summa,Status

Есть определенная технология обработки информации. Основная работа
осуществляется с глобалом ^Doc (документы). Путь мне нужно изменить документ.
Первое, что я делаю - копирую документ из общедоступного глобала ^Doc в глобал

Merge ^TmpDoc($Job,Year,CMOL,PPV,NDC)=^Doc(Year,CMOL,PPV,NDC)

Теперь в глобе ^TmpDoc я могу делать с документом что угодно без использования
транзакций и блокировок потому что я влепил в индексы системную переменную
$Job - уникальный номер под которым я зарегистрирован в системе и никто кроме
меня к данному документу в глобале ^TmpDoc доступа не имеет. Если я не хочу,
чтобы кто-то еще, после меня скорректировал этот документ и записал свой
скорректированный вариант раньше меня, я ставлю блокировку на документ

Lock +^Doc(Year,CMOL,PPV,NDC)

Теперь документ доступен для чтения, но недоступен для записи. (А может быть
недоступен и для чтения - это как прикладная программа построена).
После изменения документа я выполняю следующие действия как одну транзакцию

TStart -- начало транзакции
Do A -- процедура аннулирования разности прежнего документа (из глобала ^Doc) из картотеки ^Card
Do B -- процедура разноски в картотеку нового варианта документа из глобал ^TmpDoc
Kill ^Doc(Year,CMOL,PPV,NDC) -- удаление старого документа
Merge ^Doc(Year,CMOL,PPV,NDC)=^TmpDoc($Job,Year,CMOL,PPV,NDC) -- запись нового документа
TCommit -- конец транзакции

Kill ^TmpDoc($Job,Year,CMOL,PPV,NDC) -- удаление временной рабочей области

Lock -^Doc(Year,CMOL,PPV,NDC) -- снятие блокировки если она была установлена.

---------------------------------------------------------

Может я не догоняю последних высоконаучных достижений в области работы с базами
данных. Поэтому прошу объяснить мне - чего здесь не хватает, где и нафига я
должен использовать что-то еще и тем более оптимизатор запросов ? И что я могу
выиграть разложив эти структуры на таблицы и перейдя на реляционное представление ?


Объясняю.
то, что вы делаете, является аналогом exclusive lock - когда другой процесс может читать, но не может менять ваши данные. Высокие достижения в области работы баз данных заключаются в концепции shared lock - которая сигнализирует всем о том, что кто-то (скажем, отчет) работает с указанными данными, и их менять сейчас нельзя. В реальной жизни типов блокировок существенно больше, для разных специфичных целей вроде блокирования промежутка индексов и т.д. Кроме того, в зависимости от уровня изоляции, отличается количество налогаемых блокировок - от по одной на запись (строку) и каждое значение индекса до блокирования всех записей в таблице. Расскажите почтенной публике, как вы получите непротиворечивый отчет по суммам в вашем примере, если у вас миллион документов, и десяток юзеров, постоянно выполняющих апдейты ?
9 янв 07, 19:57    [3618391]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Ptn
Изопропил
Одновременно с этим кодом другой запрос может подсчитывать, например, сумму по всем документам, и если не повезёт, застанет базу в состоянии между kill и merge


Это можно обойти. Небесплатно - но и не невозможно.


Можно. Если вручную написать систему поддержки уровней изоляции, несколько лет отлаживать ее, и под страхом расстрела заставить разработчиков ею пользоваться. Которым придется предварительно изучить не только уровни изоляции (что делают и SQLщики), но и детали их имплементации. Как я уже говорил, для эффективного использования мумпс прикладной программист должен быть наполовину разработчиком движков баз данных.
9 янв 07, 20:02    [3618401]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Изопропил
Member

Откуда:
Сообщений: 31629
Sergei Obrastsov
Изопропил
Sergei Obrastsov

Угу. То есть происходит обновление этого блока на клиентах. В чем проблема?

Обновление, или удаление тз кэша?

Обновление, конечно. К нему же обращались


цитирую Интерсистемс:
Приложение записывает узел глобала
Set, Kill, $Increment, …
ECP-клиент проверяет есть ли записываемое значение в кэше ECP-клиента
Если блок есть и изменение происходит в рамках этого блока, то он обновляется
Если в результате изменения произойдет разделение блока (block split), то блок помечается как discarded и информация об этом посылается на ECP-сервер
ECP-клиент асинхронно посылает изменения узла глобала на ECP-сервер
Клиентский процесс не останавливается так как процесс уведомления ECP-сервера асинхронный
Процесс записи аналогичен записи в локальный кэш сервера Caché
ECP-сервер получит и обработает изменение узла глобала
Если измененный блок используют другие ECP-клиенты, то ECP-сервер уведомляет их том, что блоки, которые хранятся в их кэше, устарели

т есть наблюдаем сброс, а не обновление кэша
9 янв 07, 20:03    [3618404]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Sergei Obrastsov
kdv
Кто к кому пристает, собственно, с вопросом, "а чего это вы такие ущербные"?
Для меня-то M - пройденный этап, хотя и знаменательная веха в биографии. Писал на M, писал на всякой хрени, потом переехал на РСУБД. И ничего, по М не скучаю.
А вас-то чего так раздирает? РСУБД своим существованием покоя не дает? :-)

Вообще-то раздирает РСУБД-шников. Да что тут далеко ходить-то, просто повыбирайте темы в этом топике и посмотрите кто их начинает.


Раздирает, раздирает. Любопытство мучает : как же так, в РСУБД до хрена логики наверчено, тысячи человеколет потрачены на всякие оптимизаторы, уровни изоляции, транзакции и пр и пр. А поклонники мумпса говорят - фигня, вот у нас есть мумпс (каше), у него внутре неонка, и она все сама делает. Ну как тут не полюбопытствовать - что за неонка и каким магическим способом она все делает ?
Оказывается, таки да - неонка. Только не делает нихрена. Проще надо быть к народу, сначала юзеров выгнать, потом отчеты считать. "Сегодня потребности в уровнях изоляции у народа нет" (С)
9 янв 07, 20:16    [3618445]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Выбегалло
Ptn
Изопропил
Одновременно с этим кодом другой запрос может подсчитывать, например, сумму по всем документам, и если не повезёт, застанет базу в состоянии между kill и merge


Это можно обойти. Небесплатно - но и не невозможно.


Можно. Если вручную написать систему поддержки уровней изоляции, несколько лет отлаживать ее, и под страхом расстрела заставить разработчиков ею пользоваться. Которым придется предварительно изучить не только уровни изоляции (что делают и SQLщики), но и детали их имплементации. Как я уже говорил, для эффективного использования мумпс прикладной программист должен быть наполовину разработчиком движков баз данных.


[внимательно смотрить] интересно - сколько раз в этой ветке мупмсерам открывали глаза на "правду-матку" ? И каждый раз находится кто нибудь новый.
[Теперь видимо осталось дождаться момента когда нам начнут объяснять как работает $order]

Хорошо я повторю еще раз. ;) мне не сложно.
Ваши слова действительно имеют место быть - но увы как минимум с одним условием - если прикладному программисту на мупс всенепременно потребуется реализовать полный функционал РСУБД. Вот пока он его не повторить - он будет грызть локти и страдать.

Повторюсь - Это можно обойти. Небесплатно - но и не невозможно.

Любая задача имеет как минимум два решения.
9 янв 07, 20:20    [3618463]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Выбегалло
А поклонники мумпса говорят - фигня, вот у нас есть мумпс (каше), у него внутре неонка, и она все сама делает


ога ога - подобными "тынцами" просто все темы завалены.
9 янв 07, 20:27    [3618480]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Ptn
Выбегалло
Ptn
Изопропил
Одновременно с этим кодом другой запрос может подсчитывать, например, сумму по всем документам, и если не повезёт, застанет базу в состоянии между kill и merge


Это можно обойти. Небесплатно - но и не невозможно.


Можно. Если вручную написать систему поддержки уровней изоляции, несколько лет отлаживать ее, и под страхом расстрела заставить разработчиков ею пользоваться. Которым придется предварительно изучить не только уровни изоляции (что делают и SQLщики), но и детали их имплементации. Как я уже говорил, для эффективного использования мумпс прикладной программист должен быть наполовину разработчиком движков баз данных.


[внимательно смотрить] интересно - сколько раз в этой ветке мупмсерам открывали глаза на "правду-матку" ? И каждый раз находится кто нибудь новый.
[Теперь видимо осталось дождаться момента когда нам начнут объяснять как работает $order]

Хорошо я повторю еще раз. ;) мне не сложно.
Ваши слова действительно имеют место быть - но увы как минимум с одним условием - если прикладному программисту на мупс всенепременно потребуется реализовать полный функционал РСУБД. Вот пока он его не повторить - он будет грызть локти и страдать.

Повторюсь - Это можно обойти. Небесплатно - но и не невозможно.

Любая задача имеет как минимум два решения.


Да поняли мы ваше второе решение. "быть проще", не выделываться, отчеты гонять по ночам - пока юзеры спят.
9 янв 07, 20:28    [3618481]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Ptn
Выбегалло
А поклонники мумпса говорят - фигня, вот у нас есть мумпс (каше), у него внутре неонка, и она все сама делает


ога ога - подобными "тынцами" просто все темы завалены.


че-то сказать пытаетесь, или просто поржать захотелось ?
9 янв 07, 20:29    [3618485]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Выбегалло>>Да поняли мы ваше второе решение. "быть проще", не выделываться, отчеты гонять по ночам - пока юзеры спят.

Мое решение - озвученое Вами ? Чего так грязно передергивать то
Должен вас огорчить - JOB-ы никто в каше не отменял. Как и пакетные режимы.

А поводу тынц - я хотел сказать что слова ваши "неверны" и взяты с потолка.
Никто заслуги РСУБД в нуль не ровняет - но вот от мупсеров почему непременно требуют функционала РУСБД - не раз и не два - да хотя бы в этой ветке.

Интреснее только флемы Сионистов с Паскалистами читать.
9 янв 07, 20:37    [3618496]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Изопропил
Member

Откуда:
Сообщений: 31629
Ptn

Никто заслуги РСУБД в нуль не ровняет - но вот от мупсеров почему непременно требуют функционала РУСБД - не раз и не два - да хотя бы в этой ветке.


Ещё раз повторяю - проблема не в модели данных (иерархической/реляционной) а в реализации базовых механизмов - транзакций/изоляции/бэкапирования.
9 янв 07, 20:41    [3618506]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Изопропил
Ptn

Никто заслуги РСУБД в нуль не ровняет - но вот от мупсеров почему непременно требуют функционала РУСБД - не раз и не два - да хотя бы в этой ветке.


Ещё раз повторяю - проблема не в модели данных (иерархической/реляционной) а в реализации базовых механизмов - транзакций/изоляции/бэкапирования.


А разве Я говорил что то про проблемы в МД ?

Транзакции - есть. Изоляция - как ёё понимают РУСБД-ники нет. Бэкапирование - вообще нет никаких проблем.

Мне вот просто непонятно - как при "таких" проблемах в базовых механизмах - продуктам на основе М систем успешно удается существовать и здравствовать ?

Ну простой здравый смысл же. :)

PS: В С-и есть проблемы в реализации базовых механизмов типизации/обработки ошибок времени выполнения/ООП.
Значить ли это что всё должны перейти на Java или C# ?
Конечно же нет - каждому языку и продукту свою нишу.
9 янв 07, 20:49    [3618521]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
))
Guest
говорят, в языке M имеются сериализуемые транзакции. вы определенно должны перейти с постреляционного недоразумения к продуктам на основе М систем :)
9 янв 07, 22:23    [3618667]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
V52
Guest
Выбегалло
Объясняю.
то, что вы делаете, является аналогом exclusive lock - когда другой процесс может читать, но не может менять ваши данные. Высокие достижения в области работы баз данных заключаются в концепции shared lock - которая сигнализирует всем о том, что кто-то (скажем, отчет) работает с указанными данными, и их менять сейчас нельзя. В реальной жизни типов блокировок существенно больше, для разных специфичных целей вроде блокирования промежутка индексов и т.д. Кроме того, в зависимости от уровня изоляции, отличается количество налогаемых блокировок - от по одной на запись (строку) и каждое значение индекса до блокирования всех записей в таблице. Расскажите почтенной публике, как вы получите непротиворечивый отчет по суммам в вашем примере, если у вас миллион документов, и десяток юзеров, постоянно выполняющих апдейты ?


Я в курсе насчет shared lock. Команда TStart допускает еще ряд параметров где и определяется тип изоляции задействованных внутри транзакции данных. Однако, так я и не понял что и как я могу улучшить с помощью реляционного представления.

Насчет получения непротиворечнивого отчета по суммам у вас не возникло бы вопроса при знакомстве с технологией бухгалтреской обработки информации. Никто отчета по суммам на базе файла документов не делает. Это нелепо потому что до попадания документа в отчет материально-ответственного лица его (документа) статус неопределен. Для отчетов (пачек документов которые МОЛ передает в бухгалтерию) имеется другой приведенный мной глобал ^Rep. По нему и надо делать запросы. Но в течение отчетного периода запросы имеют оперативный характер, так как и документы и отчеты постоянно корректируются и добавляются новые. Сейчас вы получили одну сумму а через 5 минут другую. И это правильно по жизни. А когда все отчеты сформированы, период закрывается потому что после этого любая корректировка запрещена законом. И получайте непротиворечивых отчетов сколько хотите.

В связи с этим, вспомнил один случай. Пару лет назад одной довольно крупной фирме впарили систему учета как суперсовременную разработанную на реляционной БД с учетом последних достижений. Картинки красивые сделали с логотипом предприятия. Главбух писялась от счастья. Как и сколько времени внедряли - отдельная история. Наконец-то загнали в базу информацию за месяц и в торжественной обстановке научили главбухшу печатать баланс. Напечатал она ну и начала с ним работать. Полученные авансовые платежи прятать, прибыль прятать. Ясно, чтоб налогов вышло на рубль с копейками. В процессе работы баланс почеркала и решила напечатать еще один экземпляр. И, о чудо, цифры баланса получились другие. Она слегка охренела и напечатал третий экземпляр - цифры опять новые. Она, сердешная, чуть ласты не склеила. Еле валокордином откачали. С тех пор она суперсовременные решения на дух не переносит. Пользуются старой разработкой на М.

В таком вот апсекте.
9 янв 07, 22:41    [3618689]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Изопропил
Member

Откуда:
Сообщений: 31629
V52
Пользуются старой разработкой на М.
В таком вот апсекте.


Вопрос есть, на чём пользовательский интерфейс написан?
9 янв 07, 22:55    [3618709]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
V52
Сейчас вы получили одну сумму а через 5 минут другую


AAAAAAAAAAA !!! Оно действительно не понимает о чём ему толкуют :(


З.Ы. Для тех кто пытается понять (если таковые среди разработчиков на М имеются и не отравлены Ид.На.Нс.) -
Гугл рулит
Дело не в том что одну или другую в разные периоды, дело в том, что без дополнительного рыпанья, на уровне Read Uncommited правильную сумму получить тяжко, а результат дополнительного рыпанья (если он вообще может быть получен за приемлемый срок) будет несовместим с другими продуктами и частями системы (например генератора отчётов или портала). На второй странице этого обсуждения ВСЁ РАЗЖЕВАЛИ. И модель данных (сетевая, иерархичесткая реляционная черт_знает_какая) тут ни при чём и язык (M,SQL,QBE,Alpha,Tutorial D) тоже.

Пример для тех кому лень думать (в случае Оракла) :

http://www.oracle.com/global/ru/oramag/oct2006/w_dev_asktom_o65.html


Перед началом запроса имеются следующие данные:

Строка Account_Number (номер счета) Account_Balance (баланс счета)

1 123 $500.00
2 456 $240.25
...
342023 987 $100.00

Таблица 2. Таблица ACCOUNTS (банковские счета) перед началом модификации

Теперь мой оператор SELECT начинает выполняться и читать строку 1, строку 2 и т.д. В какой-то момент выполнения запроса некая транзакция переводит $400 со счета 123 на счет 987. Эта транзакция выполняет эти два обновления, но не фиксирует их. Таблица ACCOUNTS теперь выглядит следующим образом:

Строка Account_Number Account_Balance Заблокирована?

1 123 ($500.00) изменились на $100.00 X
2 456 $240.25 --
... --
342023 987 ($100.00) изменились на $500.00 X

Таблица 3. Таблица ACCOUNTS во время модификации

Как показывает таблица 3, обе обновленные строки заблокированы. Если кто-то попытается обновить их, он будет блокироваться. В этом отношении все СУБД работают примерно одинаково. Различия появятся, когда запрос доберется до заблокированных данных.

Добравшись до блока, содержащего заблокированную строку (строка 342 023), выполняемый запрос "поймет", что данные в ней изменились после начала выполнения запроса. Чтобы дать согласованный (правильный) ответ, сервер Oracle Database создаст копию этого блока, содержащего эту строку в том виде, в каком она была на момент начала выполнения запроса. То есть сервер читает значение, равное $100. Фактически сервер Oracle Database "обходит" модифицированные данные, реконструируя их из сегмента отката (rollback segment). Согласованный и правильный ответ получается без ожидания фиксации транзакции, обновляющей данные.

Однако СУБД, допускающая грязное чтение, просто вернет значение баланса счета 987 на момент его чтения, в данном случае $500. Этот запрос сосчитает перевод $400 дважды. Следовательно, он выдаст не только неправильный результат, но также возвратит сумму, которая никогда не фигурировала в таблице счетов. В многопользовательской системе базы данных грязное чтение может быть опасным, и лично я никогда не видел от него никакой пользы. Пусть вместо перевода денег с другого счета транзакция добавила бы $400 на счет 987. Грязное чтение сосчитало бы $400 и выдало "правильный" ответ, не так ли? А если будет выполнен откат незафиксированной транзакции? Нам только что предъявили $400, которых в базе данных фактически никогда не было.
9 янв 07, 23:18    [3618738]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
frutalino
Member [заблокирован]

Откуда:
Сообщений: 21
Локшин Марк
Кстати, прикольно у ребят получается. Кешировали себе кешировали данные (допустим из одной баальшой таблицы), все их читали-читали, и тут раз кто-то один запрос выполнил:
update table set field = 0
пардон, кракозябами писать не обучен, так что на SQL. И раз, у всех кеш накрылся медным тазом -читай заново. Только все прочитали, и тут кто-то бац
update table set field = 1
и опять сиквестр.


а делать update "одной баальшой таблицы" на реплицируемых РСУБД это не прикольно?
почему-то кажется, что обьем трафика по сети - будет в 10 раз больше, а может в 100.
9 янв 07, 23:26    [3618746]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
frutalino
Member [заблокирован]

Откуда:
Сообщений: 21
Изопропил
Если измененный блок используют другие ECP-клиенты, то ECP-сервер уведомляет их том, что блоки, которые хранятся в их кэше, устарели
т есть наблюдаем сброс, а не обновление кэша



Reload блоков с сервера по сети в м-клиенты вызовут юзеры - то есть это пройдет как минимум асинхронно - и 10 подряд изменений "большой таблицы" может не вызвать ничего в сети

а 10 подряд изменений "большой таблицы" в реплицируемых базах вызовут видимо пиковую нагрузку в сети

а кто-то тут говорил про сеть, что это узкое место
9 янв 07, 23:54    [3618768]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
V52
Выбегалло
Объясняю.
то, что вы делаете, является аналогом exclusive lock - когда другой процесс может читать, но не может менять ваши данные. Высокие достижения в области работы баз данных заключаются в концепции shared lock - которая сигнализирует всем о том, что кто-то (скажем, отчет) работает с указанными данными, и их менять сейчас нельзя. В реальной жизни типов блокировок существенно больше, для разных специфичных целей вроде блокирования промежутка индексов и т.д. Кроме того, в зависимости от уровня изоляции, отличается количество налогаемых блокировок - от по одной на запись (строку) и каждое значение индекса до блокирования всех записей в таблице. Расскажите почтенной публике, как вы получите непротиворечивый отчет по суммам в вашем примере, если у вас миллион документов, и десяток юзеров, постоянно выполняющих апдейты ?


Я в курсе насчет shared lock. Команда TStart допускает еще ряд параметров где и определяется тип изоляции задействованных внутри транзакции данных. Однако, так я и не понял что и как я могу улучшить с помощью реляционного представления.

Насчет получения непротиворечнивого отчета по суммам у вас не возникло бы вопроса при знакомстве с технологией бухгалтреской обработки информации. Никто отчета по суммам на базе файла документов не делает. Это нелепо потому что до попадания документа в отчет материально-ответственного лица его (документа) статус неопределен. Для отчетов (пачек документов которые МОЛ передает в бухгалтерию) имеется другой приведенный мной глобал ^Rep. По нему и надо делать запросы. Но в течение отчетного периода запросы имеют оперативный характер, так как и документы и отчеты постоянно корректируются и добавляются новые. Сейчас вы получили одну сумму а через 5 минут другую. И это правильно по жизни.


Понимаете, V52, вы рассуждаете с точки зрения разработчика доморощенных бухгалтерий. Попробуйте представить, что вам поручили сделать обработку платежей на большом веб-сайте. С доступом 24X7. Минута простоя которого стоит сотни К долларов. Вы и тут будете юзеров отключать, ждать, пока ваши отчеты выполнятся, да бэкапы пройдут ?
9 янв 07, 23:57    [3618771]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
frutalino
Локшин Марк
Кстати, прикольно у ребят получается. Кешировали себе кешировали данные (допустим из одной баальшой таблицы), все их читали-читали, и тут раз кто-то один запрос выполнил:
update table set field = 0
пардон, кракозябами писать не обучен, так что на SQL. И раз, у всех кеш накрылся медным тазом -читай заново. Только все прочитали, и тут кто-то бац
update table set field = 1
и опять сиквестр.


а делать update "одной баальшой таблицы" на реплицируемых РСУБД это не прикольно?
почему-то кажется, что обьем трафика по сети - будет в 10 раз больше, а может в 100.

Реплицируемым РСУБД будет направлен запрос
update table set field = 0
Пиковой загрузки сети он не вызовет.
10 янв 07, 00:19    [3618783]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
Ptn
c127 >>Поэтому если хотите что-то изобразить по этому пункту, то изображайте на М.

^T.TD=3
^T.TD(1)=$LB(1,3)
^T.TD(2)=$LB(1,2)
^T.TD(3)=$LB(2,3)

^T.TDI("a2Index",1,2,1)=""
^T.TDI("a2Index",1,3,2)=""
^T.TDI("a2Index",2,3,3)=""

Приводить весь сгенерированный М код не вижу смысла. Но вы правы - вопрос не мой.

А как быть с этой частью вопроса:
"Разумеется индекс должен автоматически поддерживаться при изменеии данных."
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351164&pg=75#3612620
Или решение в той части кода, приводить который вы не видите смысла?

К тому же я просил индекс по двум полям, а не два индекса по одному полю, но это уже мелочи. Хотя я может чего-то не понял, так объясните. Только не говорите, что объяснение тоже попало в ту часть кода, приводить которую Вы не видите смысла.

Ptn

80-ть страниц людям твердять что SQL это надстройка над М.
80-ть страниц люди отказываются не понимают о чем речь.
80-ть страниц людям твердять наличиствующих оссобенностях М.

Это все потому, что на 80 страницах М-адепты при любом удобном случае вместо удобного М норовят использовать программирования какую-то ОО надстройку над М или СКЛ, всеми силами избегая использовать М. Когда их тычут носом в проблемы этих надстроек, они заводят волынку, что эти надстройки использовать не нужно, а нужно использовать М, потому что на нем программировать раз плюнуть. И так много раз, причем каждый раз как в первый.


Локшин Марк
Ptn
Вот вам и сервер приложений в исполнении Каши.

Ну я с таким же успехом сервер приложений и на MS SQL и на Oracle написать могу.

Вот именно, ASCRUS выкладывал пример такого сервера на сайбейз АСА.



V52, с Вашей задачей вопрос закрыт, довольны реляционным решением?

Где ответ на мой вопрос, навеянный Вашими рассуждениями. Изобразите таблицу, это же на раз плюнуть. А то тут за Вас другие фанаты Му отдуваются. Жалкое зрелище, попробуйте Вы, может получится лучше. Напоминаю диалог на всякий случай:

V52> Теперь о модели данных. Кто-то когда-то где-то по своей неполноте знаний сказал, что М это иерархическая БД. Это подхватили сторонники Р концепции для того, чтобы можно было называть М СУБД иерархической и устаревшей, а мы, мол, работаем с Р, а это «суперсовременно». Модель данных М СУБД НЕ ИЕРАРХИЧЕСКАЯ. М СУБД МОЖЕТ хранить иерархические структуры, также как и реляционные таблицы, также как и сетевые и любые другие структуры. Изобразите нужную структуру данных в ОЗУ, добавьте спереди “^” и вы получите структуру БД. Т.е. М не зажата в рамках никакой парадигмы и Р это частный случай М.

c127> Будьте любезны, изобразите таблицу из трех полей типа целое, с ключом по одному из них и индексом по двум другим. Разумеется индекс должени автоматически поддерживаться при изменеии данных.

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351164&pg=75#3612620
10 янв 07, 01:34    [3618823]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
c127
Ptn
c127 >>Поэтому если хотите что-то изобразить по этому пункту, то изображайте на М.

^T.TD=3
^T.TD(1)=$LB(1,3)
^T.TD(2)=$LB(1,2)
^T.TD(3)=$LB(2,3)

^T.TDI("a2Index",1,2,1)=""
^T.TDI("a2Index",1,3,2)=""
^T.TDI("a2Index",2,3,3)=""

Приводить весь сгенерированный М код не вижу смысла. Но вы правы - вопрос не мой.

А как быть с этой частью вопроса:
"Разумеется индекс должен автоматически поддерживаться при изменеии данных."
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351164&pg=75#3612620
Или решение в той части кода, приводить который вы не видите смысла?


К тому же я просил индекс по двум полям, а не два индекса по одному полю, но это уже мелочи.

Хотя я может чего-то не понял, так объясните. Только не говорите, что объяснение тоже попало в ту часть кода, приводить которую Вы не видите смысла.


Хм - хорошо - сейчас выложу. Мне не жалко.

Индекс формируется автоматически.

По поводу числа индексов - их должно быть два - ибо PK объявляется в виде индекса - это метаописание - в структуре данных его нет. Обратите внимание что нода "a1Index", описывющая PK, в глобале индексов ^T.TDI отсуствует.

А понял - я в второпях пропустил модификатор PrimaryKey.
10 янв 07, 08:56    [3619095]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Ну и куда делось приложение ??? :(

К сообщению приложен файл (M.ZIP - 9Kb) cкачать
10 янв 07, 08:58    [3619102]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Это все потому, что на 80 страницах М-адепты при любом удобном случае вместо удобного М норовят использовать программирования какую-то ОО надстройку над М или СКЛ, всеми силами избегая использовать М

У как всё запущено - тогда вам пример не пойдет.
Никто М не избегает.
UDF и методы классов всех этих настроек пишуться именно на М, ровно как и генераторы.
Шаблоны и их расширения - пишутся на М.
Программы загрузки выкгрузки левой информации пишутся на М.

Хотите могу запостить пример системного класса - уберите ключевые слова и оцените сколько там кода на М.

Собсно - сейчась и приклеплю.

PS: С приклеплением косяк форума что ли ? После пред. просмотра теряет файлик

К сообщению приложен файл (cls.zip - 2Kb) cкачать
10 янв 07, 09:10    [3619144]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Выбегалло
Понимаете, V52, вы рассуждаете с точки зрения разработчика доморощенных бухгалтерий. Попробуйте представить, что вам поручили сделать обработку платежей на большом веб-сайте. С доступом 24X7. Минута простоя которого стоит сотни К долларов. Вы и тут будете юзеров отключать, ждать, пока ваши отчеты выполнятся, да бэкапы пройдут ?


B чем проблема ? информация в пределах аккаунта - по операциям блокируется на этапе проектирования - операции перебросок - блокируют всех участников блокировки. Делайте свои отчеты до посинения. Массовые отчеты либо оперативные с проверкой блокировки, либо всё равно оперируют понятием операционный день.
Журнал операций есть. Журналы Прихода, ухода тоже есть.

Машина должна работать, а программист думать.

А про бэкапы и отключения юзеров - ну поздравляю вас - родили новый миф

А Зеркальные сервера отменили видимо как класс.
10 янв 07, 09:23    [3619190]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 79 80 81 82 83 [84] 85 86 87 88 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить