[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 240: Undefined array key 1
Привет Русскоязычный информационно-болтологический форум 2004-10-16T03:39:31+01:00 https://forum.privet.com/feed/topic/48469 2004-10-16T03:39:31+01:00 2004-10-16T03:39:31+01:00 https://forum.privet.com/viewtopic.php?p=1212710#p1212710 <![CDATA[Уровни изоляции в Юконе]]>
Alex Shtern wrote:VC,

ITLs do not contain information about all the rows but each row header for
locked row contains byte - this byte is a number of Interester Transaction Slot
in the ITL . :lol:

И если бы ты прочитал прошлое сообшение, то увидел бы
что именно ето там и написано :umnik1:


A little knowledge is a dangerous thing...

Code:

create table t1 (x varchar2(10)); -- table with two ITL slots (the default)


-- Row one
insert into t1 values('ROW ONE');
commit;

-- Block dump:

scn: 0x0000.207b8fd2 seq: 0x01 flg: 0x02 tail: 0x8fd20601
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0001.018.0001d45f  0x0080000a.0ce5.0e  --U-    1  fsc 0x0000.207b8fd2
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000

block_row_dump:
tab 0, row 0, @0x1f8d
tl: 11 fb: --H-FL-- lb: 0x1  cc: 1
col  0: [ 7]  52 4f 57 20 4f 4e 45

-- the transaction took slot 1 and the row lock byte points at slot 1: lb = 0x1
--

-- Insert row  two
insert into t1 values('ROW TWO');
commit;

scn: 0x0000.207b9076 seq: 0x01 flg: 0x02 tail: 0x90760601
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0001.018.0001d45f  0x0080000a.0ce5.0e  --U-    1  fsc 0x0000.207b8fd2
0x02   0x000a.022.00018db4  0x0080009e.0b4a.13  --U-    1  fsc 0x0000.207b9076
 
block_row_dump:
tab 0, row 0, @0x1f8d
tl: 11 fb: --H-FL-- lb: 0x1  cc: 1
col  0: [ 7]  52 4f 57 20 4f 4e 45
tab 0, row 1, @0x1f82
tl: 11 fb: --H-FL-- lb: 0x2  cc: 1
col  0: [ 7]  52 4f 57 20 54 57 4f


-- the new transaction took slot 2 and the row lock byte points at slot 2: lb = 0x2
--

-- Insert row three
insert into t1 values('ROW THREE');
commit;

scn: 0x0000.207b90cf seq: 0x01 flg: 0x02 tail: 0x90cf0601

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0004.00c.0001baf5  0x00800235.0a54.4c  --U-    1  fsc 0x0000.207b90cf
0x02   0x000a.022.00018db4  0x0080009e.0b4a.13  C---    0  scn 0x0000.207b9076
 
block_row_dump:
tab 0, row 0, @0x1f8d
tl: 11 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [ 7]  52 4f 57 20 4f 4e 45
tab 0, row 1, @0x1f82
tl: 11 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [ 7]  52 4f 57 20 54 57 4f
tab 0, row 2, @0x1f75
tl: 13 fb: --H-FL-- lb: 0x1  cc: 1
col  0: [ 9]  52 4f 57 20 54 48 52 45 45

-- the new transaction over-wrote slot 1 and the row 3 lock byte points at slot 1: lb = 0x1
-- the lock bytes for rows 1 and 2 were zeroed.

Statistics: Posted by vc — 16 Oct 2004 03:39


]]>
2004-10-15T21:37:54+01:00 2004-10-15T21:37:54+01:00 https://forum.privet.com/viewtopic.php?p=1212246#p1212246 <![CDATA[Уровни изоляции в Юконе]]>
Alex Shtern wrote:ITLs do not contain information about all the rows but each row header for locked row contains byte - this byte is a number of Interester Transaction Slot in the ITL.

Alex - Вы придираетесь не по делу. VC имел в виду другое: как только ITL слот переиспользуется новой транзакцией, во всех строках блока, указывающих на этот слот, байт-индекс ITL слота последней блокировавшей эти строки транзакции безжалостно обнуляется и информация о том, кто трогал эти строки (и трогал ли вообще) безвозвратно теряется. Поэтому в таких случаях Oracle вынужден делать реконструкцию блока даже если нужная версия строки реально находится в текущем блоке.

Statistics: Posted by tengiz — 15 Oct 2004 21:37


]]>
2004-10-15T20:59:04+01:00 2004-10-15T20:59:04+01:00 https://forum.privet.com/viewtopic.php?p=1212166#p1212166 <![CDATA[Уровни изоляции в Юконе]]>
ITLs do not contain information about all the rows but each row header for
locked row contains byte - this byte is a number of Interester Transaction Slot
in the ITL . :lol:

И если бы ты прочитал прошлое сообшение, то увидел бы
что именно ето там и написано :umnik1:

Statistics: Posted by Alex Shtern — 15 Oct 2004 20:59


]]>
2004-10-15T20:32:04+01:00 2004-10-15T20:32:04+01:00 https://forum.privet.com/viewtopic.php?p=1212070#p1212070 <![CDATA[Уровни изоляции в Юконе]]>
Alex Shtern wrote:....

Правда что строки не имеют метки последней транзакции, метку транзакции имеет сама страница, но в странице на самом деле есть такая штука
как ITL interested transactions list и там записаны
ВСЕ uncommited (и может быть кое какие commited - ето зависит от initrans)
транзакции, которые модифицируют данные на етой странице а каждая модифицированная row has byte with transaction slot number in the ITL -
так что Oracle всегда знает какие rows in data page has been modified.


This is incorrect. Oracle timestamps the entire block, not individual rows so the block has to be reconstructed as a whole. ITLs do not contain information about all the rows, they contain information about transactions modifying the block. Besides, there are fewer ITLs (usually) in the block than there are rows.

VC

Statistics: Posted by vc — 15 Oct 2004 20:32


]]>
2004-10-15T19:12:30+01:00 2004-10-15T19:12:30+01:00 https://forum.privet.com/viewtopic.php?p=1211904#p1211904 <![CDATA[Уровни изоляции в Юконе]]>
Ето все ето чистая правда с точки зрения теории баз данных.

к тому же с удовольствием прочитал те главы из
CONCURRENCY CONTROL AND RECOVERY IN DATABASE SYSTEMS
которые ты где то советовал ...

Да, в Oracle, только до 255 трансакзий могут одновремено
модифицировать страницы в 8-32кб. страницы в 2 и 4 кб редко
кто использует ..

Ну скажем на практике, 2 года назад я учацтвовал в benchmark в
Sun Labs (Oregon) на Sun Fire 15K
with 106 CPUs и видел, как то раз, 16 активных трансакзий на block.

Ну и к тому же в Oracle 10g добавилась такая вещь как
guaranteed undo retention которая решит большую часть реально
связанных с етим проблем, пусть и за счет болшего количества
disk space, чем ето сделано в Yukon.

Statistics: Posted by Alex Shtern — 15 Oct 2004 19:12


]]>
2004-10-15T18:32:07+01:00 2004-10-15T18:32:07+01:00 https://forum.privet.com/viewtopic.php?p=1211807#p1211807 <![CDATA[Уровни изоляции в Юконе]]>
Alex Shtern wrote:Правда что строки не имеют метки последней транзакции, метку транзакции имеет сама страница, но в странице на самом деле есть такая штука как ITL interested transactions list и там записаны ВСЕ uncommited (и может быть кое какие commited - ето зависит от initrans) ранзакции, которые модифицируют данные на етой странице а каждая модифицированная row has byte with transaction slot number in the ITL - так что Oracle всегда знает какие rows in data page has been modified.

Alex, когдя я написал, что в Oracle "строки не имеют метки последней транзакции, метку транзакции имеет сама страница, также есть внутристраничный кеш с некоторой информацией о последних транзакциях (глубина этой мини-истории - настраиваемый параметр)" именно ITL я и имел в виду. Однако ввиду ограниченной глубины этой истории при интенсивном обновлении страницы "Oracle не всегда может точно определить есть ли нужная версия строки на текущей странице" по причине того, что для читающей транзакции одинаково важно иметь информацию как об активных тразнакциях, модифицирующих страницу (информация о всех из них действительно имеется в ITL - , кстати, это одно из узких мест Oracle - жёсткое ограничение на количество активных транзакций модифицирующих конкретную страницу), так и о зафиксированных до того, как читающая транзакция началась (а вот этого уже никто не гарантирует).

Statistics: Posted by tengiz — 15 Oct 2004 18:32


]]>
2004-10-15T16:00:27+01:00 2004-10-15T16:00:27+01:00 https://forum.privet.com/viewtopic.php?p=1211527#p1211527 <![CDATA[Уровни изоляции в Юконе]]>
Из того что здесь написано, выглядит что Yukon SI больше напоминает
Interbase/FireBird row versioning - только у них old row versions
хранятса прямо в data blocks и вообше нет Redo Log -
hot backup делают через row versioning :-)

Правда соответственно у них нет и point-in-time recovery.

Вообше то, хоть ето и не тема топика но у меня есть
один коментарий к тому что сказал tengiz об Oracle.

Правда что строки не имеют метки последней транзакции, метку транзакции имеет сама страница, но в странице на самом деле есть такая штука
как ITL interested transactions list и там записаны
ВСЕ uncommited (и может быть кое какие commited - ето зависит от initrans)
транзакции, которые модифицируют данные на етой странице а каждая модифицированная row has byte with transaction slot number in the ITL -
так что Oracle всегда знает какие rows in data page has been modified.

Statistics: Posted by Alex Shtern — 15 Oct 2004 16:00


]]>
2003-12-05T23:55:04+01:00 2003-12-05T23:55:04+01:00 https://forum.privet.com/viewtopic.php?p=828405#p828405 <![CDATA[Уровни изоляции в Юконе]]>
Merle wrote:Скажите, а как наиболее адекватно перевести термины snapshot isolation framework и version store heaps?

К сожалению, я не знаю ни устойчивой русской терминологии, ни русского технического жаргона в этой подтеме. Прямой перевод - думаю знаете сами.

А что из себя представляет snapshot isolation framework? Это сервис, процесс, механизм или просто режим работы сервера с базой?

Это набор алоритмов, реализующий их код и структуры данных в Storage Engine, которые обеспечивает shapsot isolation. Это не сервис, не процесс, а действительно режим работы в Access Methods. Объём кода для его реализации небольшой - благодаря качественному основанию, которое уже имелось. Реализованный алгоритм - один из самых прямолинейно простых и ясных для понимания вариантов мультиверсионности. Никаких изысков.

Statistics: Posted by tengiz — 05 Dec 2003 23:55


]]>
2003-12-05T17:14:42+01:00 2003-12-05T17:14:42+01:00 https://forum.privet.com/viewtopic.php?p=827684#p827684 <![CDATA[Уровни изоляции в Юконе]]>
Dmitry67 wrote:Я понял
Проблема в том что Вы пишете Folder=0 и получаете все дерево
Вся замечатлеьно
Можно также написать для какого то узла, Folder=@var

Но я то думал что есть способ сделать что нибудь в духе

with d2 (...)
slect * from SomeFolderList, d2 where dé.Folder=SomeFolderList.Folder

то есть каждый раз начинать от нового корня...


What's wrong with:

Code:

 with d2(id, folder, level) as ( 
     select id, folder, 0 as level
     from docs
     where folder in (2,3)
    union all
     select d1.id, d1.folder, level+1
     from docs d1 join d2 on d1.folder=d2.id
 )
 select * from d2

5   2   0
7   3   0
8   3   0
10   2   0
6   5   1


???

Rgds.

Statistics: Posted by vc — 05 Dec 2003 17:14


]]>
2003-12-05T16:45:01+01:00 2003-12-05T16:45:01+01:00 https://forum.privet.com/viewtopic.php?p=827631#p827631 <![CDATA[Уровни изоляции в Юконе]]> Проблема в том что Вы пишете Folder=0 и получаете все дерево
Вся замечатлеьно
Можно также написать для какого то узла, Folder=@var

Но я то думал что есть способ сделать что нибудь в духе

with d2 (...)
slect * from SomeFolderList, d2 where dé.Folder=SomeFolderList.Folder

то есть каждый раз начинать от нового корня...

Statistics: Posted by Dmitry67 — 05 Dec 2003 16:45


]]>
2003-12-05T16:20:29+01:00 2003-12-05T16:20:29+01:00 https://forum.privet.com/viewtopic.php?p=827610#p827610 <![CDATA[Уровни изоляции в Юконе]]> Statistics: Posted by vc — 05 Dec 2003 16:20


]]>
2003-12-05T16:19:28+01:00 2003-12-05T16:19:28+01:00 https://forum.privet.com/viewtopic.php?p=827607#p827607 <![CDATA[Уровни изоляции в Юконе]]>
Dmitry67 wrote:tengiz, а вот по поводу рекурсивных кверей
я про
with () select

Во превых я не понял зачем это. Если без рекурсии, то тоже самое (и больше) делают inline view

Для рекурсии я нашел только примеры BOL с двумя таблицами. А вот для самосвязанной таблицы как построить не понимаю

Например

create table Docs(ID int identity, Folder int)
Folder -> ref to Docs.ID
Root: Folder is NULL


Code:

drop table docs;
create table Docs(ID int , Folder int);
insert into docs values(1,0);
insert into docs values(2,1);
insert into docs values(3,1);
insert into docs values(4,1);
insert into docs values(5,2);
insert into docs values(6,5);
insert into docs values(7,3);
insert into docs values(8,3);
insert into docs values(9,4);
insert into docs values(10,2);


select * from docs

ID          Folder
----------- -----------
          1           0
          2           1
          3           1
          4           1
          5           2
          6           5
          7           3
          8           3
          9           4
         10           2

 with d2(id, folder, level) as (
     select id, folder, 0 as level
     from docs
     where folder=0
    union all
     select d1.id, d1.folder, level+1
     from docs d1 join d2 on d1.folder=d2.id
 )
 select * from d2

id          folder      level
----------- ----------- -----------
          1           0           0
          2           1           1
          3           1           1
          4           1           1
          9           4           2
          7           3           2
          8           3           2
          5           2           2
         10           2           2
          6           5           3

(10 rows affected)
1>


Rgds.

Statistics: Posted by vc — 05 Dec 2003 16:19


]]>
2003-12-05T15:46:49+01:00 2003-12-05T15:46:49+01:00 https://forum.privet.com/viewtopic.php?p=827570#p827570 <![CDATA[Уровни изоляции в Юконе]]>
tengiz wrote:все вопросы к группам User Education и Documentaion.

Ага, добраться бы до них.. :)

Скажите, а как наиболее адекватно перевести термины snapshot isolation framework и version store heaps?
Ну и далее немного уточнений.. =)
А что из себя представляет snapshot isolation framework? Это сервис, процесс, механизм или просто режим работы сервера с базой?

Statistics: Posted by Merle — 05 Dec 2003 15:46


]]>
2003-12-05T15:05:28+01:00 2003-12-05T15:05:28+01:00 https://forum.privet.com/viewtopic.php?p=827537#p827537 <![CDATA[Уровни изоляции в Юконе]]>
Dmitry67 wrote:tengiz, а вот по поводу рекурсивных кверей
я про
with () select

Во превых я не понял зачем это. Если без рекурсии, то тоже самое (и больше) делают inline view

А как с inline view? Вообще with() - это кажется стандарт....

Для рекурсии я нашел только примеры BOL с двумя таблицами. А вот для самосвязанной таблицы как построить не понимаю[/quote]
Вот в этой статье есть еще примеры:http://msdn.microsoft.com/library/en-us/dnsql90/html/sql_YukonTSQLEnhance.asp

Statistics: Posted by Merle — 05 Dec 2003 15:05


]]>
2003-12-05T11:42:57+01:00 2003-12-05T11:42:57+01:00 https://forum.privet.com/viewtopic.php?p=827484#p827484 <![CDATA[Уровни изоляции в Юконе]]> я про
with () select

Во превых я не понял зачем это. Если без рекурсии, то тоже самое (и больше) делают inline view

Для рекурсии я нашел только примеры BOL с двумя таблицами. А вот для самосвязанной таблицы как построить не понимаю

Например

create table Docs(ID int identity, Folder int)
Folder -> ref to Docs.ID
Root: Folder is NULL

Statistics: Posted by Dmitry67 — 05 Dec 2003 11:42


]]>
2003-12-03T20:36:56+01:00 2003-12-03T20:36:56+01:00 https://forum.privet.com/viewtopic.php?p=824481#p824481 <![CDATA[Уровни изоляции в Юконе]]>
Merle wrote:Tengiz, скажите, а в новой базе в Юконе имена всех разработчиков новой версии есть? :)

Это Вы про AdventureWorks спрашиваете? Любые совпадения случайны и к реальным людям отношения не имеют :) - все вопросы к группам User Education и Documentaion.

Statistics: Posted by tengiz — 03 Dec 2003 20:36


]]>
2003-12-03T20:20:26+01:00 2003-12-03T20:20:26+01:00 https://forum.privet.com/viewtopic.php?p=824446#p824446 <![CDATA[Уровни изоляции в Юконе]]>
Dmitry67 wrote:Потом на основе Btrieve был сделан NetWare SQL, переименованный в Perversive :) SQL, кстати, кто знает его судьбу ?

Ну насчет судьбы вообще не знаю, но где-то кто-то на нем еще что-то поддерживает и даже драйвера более-менее актуальные можно найти..

Tengiz, скажите, а в новой базе в Юконе имена всех разработчиков новой версии есть? :)

Statistics: Posted by Merle — 03 Dec 2003 20:20


]]>
2003-12-02T09:09:16+01:00 2003-12-02T09:09:16+01:00 https://forum.privet.com/viewtopic.php?p=822378#p822378 <![CDATA[Уровни изоляции в Юконе]]> В Btrieve еще очень давно тоже была версионность, я бы назвал эту базу 'двухверсионником'
Она хранила dirty data так, что readers читали только committed data.
При update одной и той же страницы возникала блокировка.

Потом на основе Btrieve был сделан NetWare SQL, переименованный в Perversive :) SQL, кстати, кто знает его судьбу ?

Statistics: Posted by Dmitry67 — 02 Dec 2003 09:09


]]>
2003-12-02T00:25:42+01:00 2003-12-02T00:25:42+01:00 https://forum.privet.com/viewtopic.php?p=821758#p821758 <![CDATA[Уровни изоляции в Юконе]]>
Merle wrote:А каким образом версионный скан догадывается какую именно строку надо смотреть в tempdb, если она к тому времени в основной базе уже заблокирована и изменена. 14 байтный кусочек с меткой транзакции и ссылкой остается по прежнему доступным?

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

Statistics: Posted by tengiz — 02 Dec 2003 00:25


]]>
2003-12-01T12:39:29+01:00 2003-12-01T12:39:29+01:00 https://forum.privet.com/viewtopic.php?p=821124#p821124 <![CDATA[Уровни изоляции в Юконе]]>
tengiz wrote:Копирование старой версии строки происходит в момент изменения строки. Наложение X блокировки ещё ничего не создаёт. Если в этот момент (после наложения блокировки но до фактического изменения) другой транзакции на версионном уровне изоляции понадобилось прочитать это строку, то строка будет прочитана безотносительно к блокировке.

А каким образом версионный скан догадывается какую именно строку надо смотреть в tempdb, если она к тому времени в основной базе уже заблокирована и изменена.
14 байтный кусочек с меткой транзакции и ссылкой остается по прежнему доступным?

Statistics: Posted by Merle — 01 Dec 2003 12:39


]]>
2003-12-01T02:04:09+01:00 2003-12-01T02:04:09+01:00 https://forum.privet.com/viewtopic.php?p=820509#p820509 <![CDATA[Уровни изоляции в Юконе]]>
zVlad wrote:Что касается нужности или не нужности версионности. Попробуйте провести опрос среди прикладных программеров. Вы узнаете что 80-90% даже не в курсе существования уровней как таковых. Так что доказывать или опровергать нужность или ненужность того о существовании чего большинство участников процесса даже не подозревают - совершенно бессмысленное занятие.

Именно. То, что большинство разработчиков не в курсе существования уровней изоляции совершенно не означает, что они появились зря. То же самое с версионностью. Её наличие только добавляет причин не знать о том, что такой зверь вообще бывает. Идеально - нужно только два режима работы - полная изоляция, и полная изоляция + readonly. Как только появится удовлетворительное по скорости более-менее универсальное алгоритмическое решение для обеспечения идеальной сериализуемости, понятие уровней изоляции просто исчезнет.
Кстати, интересен вопрос: как можно ощутить, измерить (потрогать) наличие (или отсутствие) версионности, если приложение написано исходя из принципов блокировочника? Не даст ли в этом случае версионность негативного эффекта?

Конечно, есть масса ситуаций, когда приложение, правильно работающее на блокировочном уровне изоляции, будет работать иначе на аналогичном версионном уровне изоляции. Причём "иначе" - не всегда означает "правильно". Некоторые варианты неправильного поведения мы как раз и рассматривали в последней дискуссии о write consistency в Oracle. SQL Server или DB2 в большинстве похожих ситуаций, на том же уровне изоляции отработают безупречно. Т.е. кое-какие вещи при переходе на версионность придётся переделать, иначе будут ошибки.

Statistics: Posted by tengiz — 01 Dec 2003 02:04


]]>
2003-12-01T01:51:33+01:00 2003-12-01T01:51:33+01:00 https://forum.privet.com/viewtopic.php?p=820497#p820497 <![CDATA[Уровни изоляции в Юконе]]>
Dmitry67 wrote:Я имел ввиду Workbench...

Ну тут уже я пас - я SQL Workbench использую только как более удобную функциональную замену QA. Типа такой Visual SQL Studio. Когда выйдет вторая бета и появятся открытые usenet конференции по поводу Yukon B2 - приглашаю Вас принять в них активное участие и высказать все замечания и предложения. За этими usenet группами будут внимательно следить как люди из поддержки, так и разработчики.

Statistics: Posted by tengiz — 01 Dec 2003 01:51


]]>
2003-12-01T01:46:11+01:00 2003-12-01T01:46:11+01:00 https://forum.privet.com/viewtopic.php?p=820492#p820492 <![CDATA[Уровни изоляции в Юконе]]>
Я не могу ответить на все Ваши вопросы - я не уверен, что всё, что Вы спрашиваете планируется сделать доступным публике. Вот ответы на часть из них:
как вообще происходит очистка устаревших версий? Это какой-то процесс который запускается по расписанию?
Примерно также как и происходит отработка контрольных точек (checkpoints)- по времени или по необходимости, если нет места в tempdb. Нагрузка учитывается - через отслеживание наличия активных транзакций, которым требуются версии.

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

не вступают ли в конфликт методы оптимизации для версионности и методы оптимизации необходимые для работы с временными таблицами? Не станет ли работа с временными таблицами из-за этого более тяжелой?
Нет, не вступают. Нет, не станет.

Statistics: Posted by tengiz — 01 Dec 2003 01:46


]]>
2003-11-30T22:50:29+01:00 2003-11-30T22:50:29+01:00 https://forum.privet.com/viewtopic.php?p=820383#p820383 <![CDATA[Уровни изоляции в Юконе]]>
Dmitry67 wrote:
zVlad wrote: В рамках же обсуждаемой темы я вижу один лишь поинт зачем Microsoft это (snapshot) понадобилось - чтобы упростить перевод приложений с Оракл на SQL Server. Разве не так?

Вы многократно и очень убедительно доказывали, что serialazable - есть только цель достойная достижения в теоритическом смысле. Как коммунизм в теории развития общества. Но если коммунизм, по разным причинам, оказался на данном этапе не возможен, то в нашем случае, и без чудес, а просто используя адекватные по мощности сервера и другие компоненты системы можно уже сегодня переводить приложения в режим serializable, обеспечивающий требуемую параллельность.


Я так понимаю, проблема в том, что из "большой тройки" только у DB2 теперь нет версионности и стоит задача доказать, что версионность никому не нужна ? :)

Как зелен виноград! - лиса здохнула, не в силах дотянуться до плодов. (c)


1. Наверняка в ИБМ велось и ведется изучение версионности. Возможно существование исследовательского версионного варианта ИБМ RDBMS.

2. Не исключаю, хотя и не понимаю зачем бы это было нужно (разве для облегчения перевода приложений с Оракл на DB2) что в очередной версии DB2 версионность появится.

3. Что касается нужности или не нужности версионности. Попробуйте провести опрос среди прикладных программеров. Вы узнаете что 80-90% даже не в курсе существования уровней как таковых. Так что доказывать или опровергать нужность или ненужность того о существовании чего большинство участников процесса даже не подозревают - совершенно бессмысленное занятие.
Кстати, интересен вопрос: как можно ощутить, измерить (потрогать) наличие (или отсутствие) версионности, если приложение написано исходя из принципов блокировочника? Не даст ли в этом случае версионность негативного эффекта?

Statistics: Posted by zVlad — 30 Nov 2003 22:50


]]>
2003-11-30T19:00:59+01:00 2003-11-30T19:00:59+01:00 https://forum.privet.com/viewtopic.php?p=820136#p820136 <![CDATA[Уровни изоляции в Юконе]]>
zVlad wrote: В рамках же обсуждаемой темы я вижу один лишь поинт зачем Microsoft это (snapshot) понадобилось - чтобы упростить перевод приложений с Оракл на SQL Server. Разве не так?

Вы многократно и очень убедительно доказывали, что serialazable - есть только цель достойная достижения в теоритическом смысле. Как коммунизм в теории развития общества. Но если коммунизм, по разным причинам, оказался на данном этапе не возможен, то в нашем случае, и без чудес, а просто используя адекватные по мощности сервера и другие компоненты системы можно уже сегодня переводить приложения в режим serializable, обеспечивающий требуемую параллельность.


Я так понимаю, проблема в том, что из "большой тройки" только у DB2 теперь нет версионности и стоит задача доказать, что версионность никому не нужна ? :)

Как зелен виноград! - лиса здохнула, не в силах дотянуться до плодов. (c)

Statistics: Posted by Dmitry67 — 30 Nov 2003 19:00


]]>
2003-11-30T17:53:49+01:00 2003-11-30T17:53:49+01:00 https://forum.privet.com/viewtopic.php?p=820095#p820095 <![CDATA[Уровни изоляции в Юконе]]>
tengiz wrote:
Dmitry67 wrote:Пока вот какой минус. Конечно работал я мало... но... c интерфейсом надо чтото делать То что раньше занимало один клик, теперь целаю проблема.

Спасибо за Ваше частное мнение :)

Об интерфейсе чего идёт речь? Единственный интерфейс, с которым я сталкиваюсь - это setup, SQL Workbench, и BOL - я больше ничего никогда не включал ввиду сцепифики ядра сервера. Что касается setup - то по-моему там всё достаточно просто. SQL Workbench сначала бесит почти всех (дайте взад наш QA!), но потом, после того, как немного освоишься (через неделю-другую), обратно на QA уже не перетащишь. Тоже почти всех.


Я имел ввиду Workbench.
Пытаешься удалить таблицу. Было как ? Клик, delete, OK, все
Теперь - окно с глюкалками запускается, этапы процесса удаления показывает... Правда более одной таблицы за раз не выбрать и после удаления список таблиц не рефрешится...
Квери незаконнекченные которые при попытке запуска просят себя законеектить... Все это замечательно, но как только законнектился - она начинает выполняться по master...
Вот пока что всбесило

Statistics: Posted by Dmitry67 — 30 Nov 2003 17:53


]]>
2003-11-30T15:09:41+01:00 2003-11-30T15:09:41+01:00 https://forum.privet.com/viewtopic.php?p=820025#p820025 <![CDATA[Уровни изоляции в Юконе]]>
tengiz wrote:
zVlad wrote:Tengiz! Положа руку на сердце скажите: есть нынче, на уровне SQL 2000 неразрешимые проблемы конкурентного доступа?..........

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

Для опытного разработчика приложений неразрешимых проблем нет :).

Если серьёзно - а Вы разве забыли, что своей популярностью реляционные СУБД и SQL обязаны тем, что системы предыдущих поколений были значительно менее удобны для прикладных программистов? Почему Вы полагаете, что движение в сторону удобства и логичной простоты без ущерба для функциональности и производительности должно почему-то прекратиться?

Даже если проблема оптимальной изоляции транзакций снимется с повестки дня для самого широкого спректра приложений (давайте помечтаем - например, СУБД будут иметь только два надёжных и качественных режима работы каким-то ещё чудом обеспечивающих максимальную параллельность - serializable и readonly), не переживайте - без интересной и уважаемой работы не окажетесь: для DBA и опытных разработчиков приложений баз данных всё равно остаётся огромная область приложения ума и сил помимо шаманства вокруг изоляции транзакций - оптимально построенные модели данных, аккуратно спроектированные и написанные запросы, тонкая настройка производительности приложений, оптимальное индексирование и пр.


По порядку:
1. "....Если серьёзно - а Вы разве забыли, что своей популярностью реляционные СУБД и SQL обязаны тем, что системы предыдущих поколений были значительно менее удобны для прикладных программистов?"
Нет не забыл. Потому что уже давно (скорее никогда) в эту сказку не верю. А Вы ни разу не видели мук программистов переходящих скажем с "удобств" IDMS на "удобства" RDBMS?
Есть два-три поинта почему RDBMS завоевали рынок, например, производительность труда программера - т.е. сколько с него можно выдоить за единицу времени, или модифицируемость приложения. Но никак не "удобства".

В рамках же обсуждаемой темы я вижу один лишь поинт зачем Microsoft это (snapshot) понадобилось - чтобы упростить перевод приложений с Оракл на SQL Server. Разве не так?

2. "...давайте помечтаем - например, СУБД будут иметь только два надёжных и качественных режима работы каким-то ещё чудом обеспечивающих максимальную параллельность - serializable и readonly".

Вы многократно и очень убедительно доказывали, что serialazable - есть только цель достойная достижения в теоритическом смысле. Как коммунизм в теории развития общества. Но если коммунизм, по разным причинам, оказался на данном этапе не возможен, то в нашем случае, и без чудес, а просто используя адекватные по мощности сервера и другие компоненты системы можно уже сегодня переводить приложения в режим serializable, обеспечивающий требуемую параллельность.

Statistics: Posted by zVlad — 30 Nov 2003 15:09


]]>
2003-11-30T13:29:47+01:00 2003-11-30T13:29:47+01:00 https://forum.privet.com/viewtopic.php?p=820005#p820005 <![CDATA[Уровни изоляции в Юконе]]>
tengiz wrote:Догадайтесь :).

Лучшая догадка - экспериментально подтвержденная... :)

Если я Вам еще не надоел :) , то вот очередная порция вопросов..
1. Маркируется ли как нибудь последняя запись в цепочке версий в tempdb или в этом нет необходимости? И как вообще происходит очистка устаревших версий? Это какой-то процесс который запускается по расписанию? И учитывается ли при этом как-нибудь нагрузка?
2. Как именно происходит копирование старых версий из базы в tempdb? Может ли возникнуть ситуация при которой пишущая транзакция уже захватила запись на изменение, но зафиксированной копии в tempdb еще не появилось? Как я понял из документации обязанность класть копию записи в tempdb возлагается на изменяющую транзакцию?
3. Проводились ли какие-нибудь хитрые оптимизации над tempdb, возможно даже другая структура? И не вступают ли в конфликт методы оптимизации для версионности и методы оптимизации необходимые для работы с временными таблицами? Не станет ли работа с временными таблицами из-за этого более тяжелой?

Statistics: Posted by Merle — 30 Nov 2003 13:29


]]>
2003-11-30T00:09:35+01:00 2003-11-30T00:09:35+01:00 https://forum.privet.com/viewtopic.php?p=819493#p819493 <![CDATA[Уровни изоляции в Юконе]]>
Merle wrote:А как сейчас происходит в Юконе join таблиц из разных баз одна из которых с поддержкой версионности, а другая без?

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

Да, в BOL есть некая неточность...

Спасибо - я перешлю Вашу находку в группу документации.

Statistics: Posted by tengiz — 30 Nov 2003 00:09


]]>
2003-11-29T20:30:51+01:00 2003-11-29T20:30:51+01:00 https://forum.privet.com/viewtopic.php?p=819320#p819320 <![CDATA[Уровни изоляции в Юконе]]>
tengiz wrote: Тенхически это элементарно. Но по сути добавляет проблем концептуального характера - например, как делать join таблицы с версиями с таблицами без поддержки весрионности? Очевидно, что о согласованных результатах в таком случае не может идти и речи. Поэтому эта фича ещё требует тщательного продумывания.

А как сейчас происходит в Юконе join таблиц из разных баз одна из которых с поддержкой версионности, а другая без?

Что касается WorkBench, то я наоборот, сначала был от него в диком восторге, и пытался даже с 2000 в нем работать =), но потом перешел обратно в QA, уж очень WB медленный... Иногда просто встревает и долго-долго над чем-то думает... Впрочем я склонен списывать все это на его раньюю беттовость, там похоже половина функций not yet implemented..

Да, в BOL есть некая неточность, в том месте, где описывается snapshot уровень изоляции, глава "Understanding Snapshot Isolation". В примере отсутствует команда commit для snapshot трананзакции, из-за этого не ясно когда она завершается, и сам пример похоже не для snapshot транзакции, а для версионного read committed.
Страничка кажется вот эта:ms-help://MS.SQLSVR9/accdb9/htm/acd_locks_4ule.htm

Statistics: Posted by Merle — 29 Nov 2003 20:30


]]>
2003-11-29T18:45:36+01:00 2003-11-29T18:45:36+01:00 https://forum.privet.com/viewtopic.php?p=819253#p819253 <![CDATA[Уровни изоляции в Юконе]]>
Merle wrote:Как правило все начинается с промежуточных агрегатных табличек, индексированых въюшек, в крайнем случае отдельной базы. Более того, подобное разделение - это практически стандартный паттерн для проектировщика БД, который в конечном итоге дает гораздо больший эффект на выходе нежели версионность, так как тут две отдельных сущности заточенные имено под свои задачи.

Самые эффективные агрегатные таблицы имеют очень неприятное свойство создания дополнительных hotspots - например, если даже если в исходных таблицах большинство оперативных транзакций легко "разводятся" благодаря тому, что в основом трогают разные данные, при агрегации те же самые транзакции начинают сталкиваться лбами на значительно более узком пространстве, в результате серьёзно замедляя работу. В итоге почти полностью дискредитируя главную идею материализованных представлений. А вот версионность в сочетании с кое-какими другими, пока ещё экзотическими техниками, позволяет использовать значительно более тонкие алгоритмы оперативного создания и поддержки материализованных агрегатов.

Вообще идеальным мне видится вариант, при котором поддержка версий может выставляться не на уровне базы, а на уровне отдельной таблицы.

Возможность включать и выключать поддержку версионности на уровне отдельной таблицы к сожалению не попала в Yukon - по причинам не связанным с ресурсами или временем на разработку/внедрение. Тенхически это элементарно. Но по сути добавляет проблем концептуального характера - например, как делать join таблицы с версиями с таблицами без поддержки весрионности? Очевидно, что о согласованных результатах в таком случае не может идти и речи. Поэтому эта фича ещё требует тщательного продумывания.

Statistics: Posted by tengiz — 29 Nov 2003 18:45


]]>
2003-11-29T18:25:15+01:00 2003-11-29T18:25:15+01:00 https://forum.privet.com/viewtopic.php?p=819240#p819240 <![CDATA[Уровни изоляции в Юконе]]>
Dmitry67 wrote:Пока вот какой минус. Конечно работал я мало... но... c интерфейсом надо чтото делать То что раньше занимало один клик, теперь целаю проблема.

Спасибо за Ваше частное мнение :)

Об интерфейсе чего идёт речь? Единственный интерфейс, с которым я сталкиваюсь - это setup, SQL Workbench, и BOL - я больше ничего никогда не включал ввиду сцепифики ядра сервера. Что касается setup - то по-моему там всё достаточно просто. SQL Workbench сначала бесит почти всех (дайте взад наш QA!), но потом, после того, как немного освоишься (через неделю-другую), обратно на QA уже не перетащишь. Тоже почти всех.

Statistics: Posted by tengiz — 29 Nov 2003 18:25


]]>
2003-11-29T15:46:43+01:00 2003-11-29T15:46:43+01:00 https://forum.privet.com/viewtopic.php?p=819168#p819168 <![CDATA[Уровни изоляции в Юконе]]>
zVlad wrote:Эта проблема решается элементарно репликацией (warehouse, data mart and so on). А также адекватным пониманием того что есть OLAP и что есть OLTP. Я имею в виду когда говорят что мол нужен отчет по всей базе и именно на любой текущий момент времени - то это есть не понимание сути OLAP. Проблема устраняется путем непродолжительной душевной беседы с тем кто этого просит.


1. репликацией это не решается никак. Потому что в target database реплицация отливается на основании общих механизмов, так что там тоже возникают блокировки. Короче, та же ж... только вид сбоку. Ну и дополнительный геморрой с репликацией.

2. Дело не в том что хотят отчет в любой момент времени. Если хотят OLAP отчет на 11/11/2003 12:34:45, то это непонимание сути OLAP
Но как правило момент то говорится не потому что секунды важны
А важен просто CONSISTENT отчет. А вот без версионности это ох как сложно !

2 tengiz
Меня порадовали новые возможности Yukon. Я правда пока повозился пару часов а потом у меня упала VMWare :)
В понедельник переставлю
Пока вот какой минус. Конечно работал я мало... но... c интерфейсом надо чтото делать
То что раньше занимало один клик, теперь целаю проблема. Похоже программисты соревновались у кого больше на экране глюкалок и прогресс баром больше будет, а об эргономике не думали вообще
Это мое частное и предварительное мнение

Statistics: Posted by Dmitry67 — 29 Nov 2003 15:46


]]>
2003-11-29T13:16:32+01:00 2003-11-29T13:16:32+01:00 https://forum.privet.com/viewtopic.php?p=819144#p819144 <![CDATA[Уровни изоляции в Юконе]]> Реально именно выигрыш в производительности будет получаться для достаточно узкого круга задач, когда блокировочнику уже начинают при массовых чтениях мешаться пишущие запросы, но этих пишущих запросов еще не на столько много, чтобы начало сказываться замедление от необходимости сохранять устаревшие версии и поиска по этим версиям нужной.
К тому же OLAP/OLTP - это достаточно грубое деление. Обычно нет необходимости выносить OLAP в отдельный экземпляр или сервер, если есть такая необходимость, то никакая версионность не спасет. Как правило все начинается с промежуточных агрегатных табличек, индексированых въюшек, в крайнем случае отдельной базы. Более того, подобное разделение - это практически стандартный паттерн для проектировщика БД, который в конечном итоге дает гораздо больший эффект на выходе нежели версионность, так как тут две отдельных сущности заточенные имено под свои задачи.
Но все же версионность штука очень полезная. От какой же головной боли она может избавить!
Вообще идеальным мне видится вариант, при котором поддержка версий может выставляться не на уровне базы, а на уровне отдельной таблицы.

Statistics: Posted by Merle — 29 Nov 2003 13:16


]]>
2003-11-29T06:32:48+01:00 2003-11-29T06:32:48+01:00 https://forum.privet.com/viewtopic.php?p=818986#p818986 <![CDATA[Уровни изоляции в Юконе]]>
zVlad wrote:
Поступает запрос: "А столько у нас на данный момент изделий "Ю" имеется на складе?"

Это как раз OLPT проблема. И как Вам здесь поможет OLAP?

Много лет назад, в другой сфере, обсуждался вопрос: что есть диалоговый запрос, а что есть пакетное задание - до сих пор нет однозначного решения. Так же и с OLTP/OLAP.

Ну для меня водораздел между оперативной обработкой транзакций и всем остальным проходит довольно чётко - если данные используются для принятия оперативного решения, причём под решением имеется в виду в том числе и изменение других оперативных данных, и если ошибка при принятии решения должна быть поймана немедленно - то это оперативная обработка. В вашем примере - если ответ на вопрос об изделии Ю нужен для организации немедленной погрузки в вагон, который стоит у ворот, причём если попросили 50 ящиков этого изделия, то в вагон гарантированно должны попасть 50 поэтому никто больше эти 50 ящиков тронуть не должен, то это OLTP. Объёмы обрабатываемой информации - признак вторичный, хотя, как правило, в виду требования "оперативности" объёмы изо всех сил стараются не раздувать.

Правильной (на мой взгляд) реакцией девелоперов СУБД являются: триггеры и их более понятное для прикладных программеров воплощение - материализованные "примочки". Ну не понимаю я SnapShot Isolation Level!

Вы удивитесь как много интересного позволяет сделать snapshot isolation для того, чтобы "триггеры и материализовнные примочки" работали ещё лучше и ещё более оперативно. Дайте срок - обязательно убедитесь.

Statistics: Posted by tengiz — 29 Nov 2003 06:32


]]>
2003-11-29T06:19:21+01:00 2003-11-29T06:19:21+01:00 https://forum.privet.com/viewtopic.php?p=818973#p818973 <![CDATA[Уровни изоляции в Юконе]]>
zVlad wrote:Tengiz! Положа руку на сердце скажите: есть нынче, на уровне SQL 2000 неразрешимые проблемы конкурентного доступа? Не надуманные - настоящие, неразрешимые. Я имею в виду, которых нельзя было бы разрешить правильным прикладным решением - не на уровне СУБД?...

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

Для опытного разработчика приложений неразрешимых проблем нет :).

Если серьёзно - а Вы разве забыли, что своей популярностью реляционные СУБД и SQL обязаны тем, что системы предыдущих поколений были значительно менее удобны для прикладных программистов? Почему Вы полагаете, что движение в сторону удобства и логичной простоты без ущерба для функциональности и производительности должно почему-то прекратиться?

Даже если проблема оптимальной изоляции транзакций снимется с повестки дня для самого широкого спректра приложений (давайте помечтаем - например, СУБД будут иметь только два надёжных и качественных режима работы каким-то ещё чудом обеспечивающих максимальную параллельность - serializable и readonly), не переживайте - без интересной и уважаемой работы не окажетесь: для DBA и опытных разработчиков приложений баз данных всё равно остаётся огромная область приложения ума и сил помимо шаманства вокруг изоляции транзакций - оптимально построенные модели данных, аккуратно спроектированные и написанные запросы, тонкая настройка производительности приложений, оптимальное индексирование и пр.

Statistics: Posted by tengiz — 29 Nov 2003 06:19


]]>
2003-11-29T04:50:12+01:00 2003-11-29T04:50:12+01:00 https://forum.privet.com/viewtopic.php?p=818900#p818900 <![CDATA[Уровни изоляции в Юконе]]>
tengiz wrote:
zVlad wrote:А зачем усложнять и гоняться за решениями, которые противоречат естественному ходу вещей в материальной природе и обществе, отражать которые призваны наши системы?

........
Представьте например ситуацию когда на складе идет приемка новых партии различных единиц хранения и выдача их же. Учет бумажный. Поступает запрос: "А столько у нас на данный момент изделий "Ю" имеется на складе?"

Это как раз OLPT проблема. И как Вам здесь поможет OLAP?


Много лет назад, в другой сфере, обсуждался вопрос: что есть диалоговый запрос, а что есть пакетное задание - до сих пор нет однозначного решения. Так же и с OLTP/OLAP. Когда я вижу "online" транзакцию перелопачивающую многомиллионную таблицу (соединение многомиллионнострочных таблиц!) в то время как Service Level Agreement (SLA) требует sub-second responce time, я вспоминаю ту диллему и думаю есть вещи которым нет однозначного определения. Так и с OLTP/OLAP дела обстоят. И, естественно, мне (и любому другому) OLAP никак помочь не может, ни здесь ни где-либо еще поскольку это лишь набор слов, отражающий возмущение против ресурсоемких запросов к базе данных. Правильной (на мой взгляд) реакцией девелоперов СУБД являются: триггеры и их более понятное для прикладных программеров воплощение - материализованные "примочки". Ну не понимаю я SnapShot Isolation Level!

Statistics: Posted by zVlad — 29 Nov 2003 04:50


]]>
2003-11-29T05:07:12+01:00 2003-11-29T04:12:17+01:00 https://forum.privet.com/viewtopic.php?p=818859#p818859 <![CDATA[Уровни изоляции в Юконе]]> Да, известен факт, что так называемые прикладные програмисты редко знают об уровнях, блокировках, commit-ах - объяснения этих простых вещей составляет львиную долю моего участия в том что делает наш прикладной суппорт.
А теперь давайте представим чудо - они об этом хорошо знают, учитывают при написании приклада, используют ньюансы существующих механизмов изоляции, избегают проблем конкурентного доступа в корне. Что тогда будет?
Tengiz! Положа руку на сердце скажите: есть нынче, на уровне SQL 2000 неразрешимые проблемы конкурентного доступа? Не надуманные - настоящие, неразрешимые. Я имею в виду, которых нельзя было бы разрешить правильным прикладным решением - не на уровне СУБД?
Согласен, будет круче, не надо будет вкладываться в образование прикладных программеров, СУБД будет толлерантна ко многим глубостям. Наверное это может согреть сердце девелопера СУБД, но.... как-то противится этому душа DBA-я, работающего "в поле".

Statistics: Posted by zVlad — 29 Nov 2003 04:12


]]>
2003-11-29T02:34:39+01:00 2003-11-29T02:34:39+01:00 https://forum.privet.com/viewtopic.php?p=818784#p818784 <![CDATA[Уровни изоляции в Юконе]]>
zVlad wrote:А зачем усложнять и гоняться за решениями, которые противоречат естественному ходу вещей в материальной природе и обществе, отражать которые призваны наши системы?

zVlad, усложнение, о котором Вы говорите, является таковым только для фирм-производителей СУБД. Для пользователей это только упрощение. Представьте - вместо того, чтобы разворачивать тяжёлую бронетехнику в виде OLAP для получения согласованных отчётов и при этом не подсадить OLTP базу данных, пользватель всего лишь включает режим изоляции snapshot - и извольте, Ваши данные готовы! Цель - удобство и простота работы пользователей.

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

Однако обеспечение этого идеала входит в противоречие с производительностью. Отсюда и полезла ересь чистой сериализации в виде ослабленных уровней изоляции. Это было сделано от бессилия совместить идеальную изоляцию с приемлимой скоростью. Версионность позволяет совместить одно с другим в довольно важном классе приложений. Что же в этом плохого, если разработчикам приложений облегчают жизнь не заставляя их жертвовать ни безошибочностью работы программ, ни скоростью, ни временем на разворачивание и поддержку дополнительных системых сервисов?

Представьте например ситуацию когда на складе идет приемка новых партии различных единиц хранения и выдача их же. Учет бумажный. Поступает запрос: "А столько у нас на данный момент изделий "Ю" имеется на складе?"

Это как раз OLPT проблема. И как Вам здесь поможет OLAP?

Statistics: Posted by tengiz — 29 Nov 2003 02:34


]]>
2003-11-28T22:12:50+01:00 2003-11-28T22:12:50+01:00 https://forum.privet.com/viewtopic.php?p=818572#p818572 <![CDATA[Уровни изоляции в Юконе]]>
Dmitry67 wrote:
zVlad wrote:Эта проблема решается элементарно репликацией (warehouse, data mart and so on). А также адекватным пониманием того что есть OLAP и что есть OLTP. Я имею в виду когда говорят что мол нужен отчет по всей базе и именно на любой текущий момент времени - то это есть не понимание сути OLAP. Проблема устраняется путем непродолжительной душевной беседы с тем кто этого просит.


Так просто ? И элементарно ?
zVlad, Вы можете зашибать огромные деньги путем "непродолжительной душевной беседы". Мы тут просто ничего не понимаем.


А зачем усложнять и гоняться за решениями, которые противоречат естественному ходу вещей в материальной природе и обществе, отражать которые призваны наши системы?
Представьте например ситуацию когда на складе идет приемка новых партии различных единиц хранения и выдача их же. Учет бумажный. Поступает запрос: "А столько у нас на данный момент изделий "Ю" имеется на складе?"
Ваши Варианты решения?

Statistics: Posted by zVlad — 28 Nov 2003 22:12


]]>