powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / СУБД для учета финансовых потоков?
5 сообщений из 180, страница 8 из 8
СУБД для учета финансовых потоков?
    #34148535
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!!пока еще Yo! на откровенной лаже никто не ловил ;)
Можно начать отсюда и до конца. Особенно впечатляет Yo.!!у меня спросили совета для одной системы, я нашел красивое объеснение тормозов этой системы из-за темп-таблиц в транзакции, т.к. сайт красиво объясняло эфект который мы наблюдали.

P.S. Впрочем, бесполезно все это...
...
Рейтинг: 0 / 0
СУБД для учета финансовых потоков?
    #34148614
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ChAЯ делаю правильный вывод из Вашей фразы, что накапливают - плохо и не накапливают - тоже плохо ?
В целом примерно так :)

ChAИли, лучше, как поступает Oracle ? Можно цитату на аналогичную тему из документации ?
Oracle не вычисляет курсор заранее. Цитату сходу не найду, предпочту простой пример:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
SQL> declare
   2   
   3     type TIntTable is table of integer ;
   4   
   5     cursor crTest is
   6       select rownum n#
   7       from dba_objects, dba_objects, dba_objects, dba_objects,
   8            dba_objects, dba_objects, dba_objects, dba_objects ;
   9   
  10     time_start  timestamp := systimestamp ;
  11     obj_count   integer ;
  12     fetch_count integer :=  1  ;
  13     data        TIntTable ;
  14   
  15     procedure Mark ( msg varchar2 ) is
  16       seconds number := to_char ( systimestamp, 'SSSSS.FF' ) - to_char ( time_start, 'SSSSS.FF' ) ;
  17     begin
  18       dbms_output.put_line ( rpad ( msg || ' ',  70 , '.' ) || to_char ( seconds, '9990.00' )) ;
  19       time_start := systimestamp ;
  20     end ;
  21   
  22     procedure FetchNext is
  23       N constant integer :=  1000000  ;
  24     begin
  25       fetch crTest bulk collect into data limit N ;
  26       Mark ( 'Получение записей ' || fetch_count || ' - ' || ( fetch_count + N -  1  )) ;
  27       fetch_count := fetch_count + N ;
  28     end ;
  29   
  30   begin
  31     select count(*) into obj_count from dba_objects ;
  32     Mark ( 'Запрос кол-ва записей в dba_objects' ) ;
  33     open crTest ;
  34     Mark ( 'Открытие курсора на ' || power ( obj_count,  8  ) || ' записей' ) ;
  35     for i in  1 .. 10  loop FetchNext ; end loop ;
  36   end ;
  37   /

Запрос кол-ва записей в dba_objects ..................................     0 . 05 
Открытие курсора на  32326965938056011787168549511729891841  записей ...     0 . 00 
Получение записей  1  -  1000000  ........................................     1 . 19 
Получение записей  1000001  -  2000000  ..................................     0 . 75 
Получение записей  2000001  -  3000000  ..................................     0 . 77 
Получение записей  3000001  -  4000000  ..................................     0 . 75 
Получение записей  4000001  -  5000000  ..................................     0 . 73 
Получение записей  5000001  -  6000000  ..................................     0 . 77 
Получение записей  6000001  -  7000000  ..................................     0 . 75 
Получение записей  7000001  -  8000000  ..................................     0 . 75 
Получение записей  8000001  -  9000000  ..................................     0 . 73 
Получение записей  9000001  -  10000000  .................................     0 . 75 

PL/SQL procedure successfully completed

ChAИ, кстати, давайте не будем трогать трехзвенщиков в контексте нашего обсуждения ? Это совершенно отдельная и большая тема. И не думаю, что они работают только на платформе MSSQL
Согласен и согласен. Тема возникла исключительно потому, что они свои аргументы обжимают по "общему что есть у всех серверов", в частности несколько поднадоевший мне рефрен о необходимости как можно быстрее выфетчить с сервера БД всю выборку.

ChAХотя бы парочку примеров таких запретительных хинтов с кратким пояснением можете привести ?
Скажем,

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
SQL> create table t1 as select rownum id from dual connect by level <=  1000000  ;
SQL> create table t2 as select rownum id from dual connect by level <=  1000000  ;
SQL> create table t3 as select rownum id from dual connect by level <=  100  ;
SQL> alter table t1 add constraint t1_pk primary key ( id ) ;
SQL> alter table t2 add constraint t2_pk primary key ( id ) ;
SQL> alter table t3 add constraint t3_pk primary key ( id ) ;
SQL> exec dbms_stats.gather_schema_stats ( ownname => user ) ;

-- Нормальный план для запроса с подзапросом. Оптимизатор раскрывает подзапрос и 
-- меняет порядок join-ов, вытаскивая вперед маленькую таблицу t3

SQL> explain plan for
   2   select *
   3   from
   4     ( select t1.id id_1, t2.id id_2 from t1, t2 where t1.id = t2.id ) tt,
   5     t3
   6   where
   7     tt.id_1 = t3.id ;

-----------------------------------------------------------------------------
| Id  | Operation           | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|    0  | SELECT STATEMENT    |       |      1  |     11  |      3    ( 0 )|  00 : 00 : 01  |
|    1  |  NESTED LOOPS       |       |      1  |     11  |      3    ( 0 )|  00 : 00 : 01  |
|    2  |   NESTED LOOPS      |       |      1  |      7  |      2    ( 0 )|  00 : 00 : 01  |
|    3  |    INDEX FULL SCAN  | T3_PK |    100  |    300  |      1    ( 0 )|  00 : 00 : 01  |
|*   4  |    INDEX UNIQUE SCAN| T1_PK |      1  |      4  |      1    ( 0 )|  00 : 00 : 01  |
|*   5  |   INDEX UNIQUE SCAN | T2_PK |      1  |      4  |      1    ( 0 )|  00 : 00 : 01  |
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
    4  - access("T1"."ID"="T3"."ID")
    5  - access("T1"."ID"="T2"."ID")

-- Хинт NO_MERGE запрещает раскрывать подзапрос

SQL> explain plan for
   2   select *
   3   from
   4     ( select /*+ NO_MERGE */ t1.id id_1, t2.id id_2 from t1, t2 where t1.id = t2.id ) tt,
   5     t3
   6   where
   7     tt.id_1 = t3.id ;

--------------------------------------------------------------------------------
| Id  | Operation            | Name  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time
--------------------------------------------------------------------------------
|    0  | SELECT STATEMENT     |       |      1  |     29  |       |   2188    ( 4 )|  00 : 0 
|*   1  |  HASH JOIN           |       |      1  |     29  |       |   2188    ( 4 )|  00 : 0 
|    2  |   INDEX FULL SCAN    | T3_PK |    100  |    300  |       |      1    ( 0 )|  00 : 0 
|    3  |   VIEW               |       |  1000K|    24M|       |   2177    ( 3 )|  00 : 0 
|*   4  |    HASH JOIN         |       |  1000K|  7812K|    15M|   2177    ( 3 )|  00 : 0 
|    5  |     TABLE ACCESS FULL| T1    |  1000K|  3906K|       |    315    ( 5 )|  00 : 0 
|    6  |     TABLE ACCESS FULL| T2    |  1000K|  3906K|       |    315    ( 5 )|  00 : 0 
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
    1  - access("TT"."ID_1"="T3"."ID")
    4  - access("T1"."ID"="T2"."ID")

-- Продолжая издевательства, запрещаем использовать HASH JOIN
-- для подключения t3 к результату подзапроса

SQL> explain plan for
   2   select /*+ NO_USE_HASH (tt, t3) */ *
   3   from
   4     ( select /*+ NO_MERGE */ t1.id id_1, t2.id id_2 from t1, t2 where t1.id = t2.id ) tt,
   5     t3
   6   where
   7     tt.id_1 = t3.id ;

--------------------------------------------------------------------------------
| Id  | Operation            | Name  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time
--------------------------------------------------------------------------------
|    0  | SELECT STATEMENT     |       |      1  |     29  |       |   2851   ( 26 )|  00 : 0 
|    1  |  NESTED LOOPS        |       |      1  |     29  |       |   2851   ( 26 )|  00 : 0 
|    2  |   VIEW               |       |  1000K|    24M|       |   2177    ( 3 )|  00 : 0 
|*   3  |    HASH JOIN         |       |  1000K|  7812K|    15M|   2177    ( 3 )|  00 : 0 
|    4  |     TABLE ACCESS FULL| T1    |  1000K|  3906K|       |    315    ( 5 )|  00 : 0 
|    5  |     TABLE ACCESS FULL| T2    |  1000K|  3906K|       |    315    ( 5 )|  00 : 0 
|*   6  |   INDEX UNIQUE SCAN  | T3_PK |      1  |      3  |       |      0    ( 0 )|  00 : 0 
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
    3  - access("T1"."ID"="T2"."ID")
    6  - access("TT"."ID_1"="T3"."ID")

-- Наконец, запретим использовать индекс T3_PK. Обратите внимание, мы
-- запретили HASH JOIN, поэтому в прошлом случае оптимизатор выбрал NESTED LOOPS, 
-- а сейчас - MERGE JOIN. 

SQL> explain plan for
   2   select /*+ NO_USE_HASH (tt, t3) NO_INDEX (t3 t3_pk) */ *
   3   from
   4     ( select /*+ NO_MERGE */ t1.id id_1, t2.id id_2 from t1, t2 ) tt,
   5     t3
   6   where
   7     tt.id_1 = tt.id_2 and tt.id_1 = t3.id ;

--------------------------------------------------------------------------------
| Id  | Operation             | Name | Rows  | Bytes |TempSpc| Cost (%CPU)| Time
--------------------------------------------------------------------------------
|    0  | SELECT STATEMENT      |      |      1  |     29  |       |   9638    ( 2 )|  00 : 0 
|    1  |  MERGE JOIN           |      |      1  |     29  |       |   9638    ( 2 )|  00 : 0 
|    2  |   SORT JOIN           |      |    100  |    300  |       |      3   ( 34 )|  00 : 0 
|    3  |    TABLE ACCESS FULL  | T3   |    100  |    300  |       |      2    ( 0 )|  00 : 0 
|*   4  |   SORT JOIN           |      |  1000K|    24M|    69M|   9635    ( 2 )|  00 : 0 
|    5  |    VIEW               |      |  1000K|    24M|       |   2177    ( 3 )|  00 : 0 
|*   6  |     HASH JOIN         |      |  1000K|  7812K|    15M|   2177    ( 3 )|  00 : 0 
|    7  |      TABLE ACCESS FULL| T1   |  1000K|  3906K|       |    315    ( 5 )|  00 : 0 
|    8  |      TABLE ACCESS FULL| T2   |  1000K|  3906K|       |    315    ( 5 )|  00 : 0 
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
    4  - access("TT"."ID_1"="T3"."ID")
       filter("TT"."ID_1"="T3"."ID")
    6  - access("T1"."ID"="T2"."ID")

ChAВ Oracle есть временные таблицы и табличные функции ?
Есть.

ChAТаких хинтов, насколько понимаю, в Oracle на порядок больше, чем у MSSQL, что в значительной степени сложилось, как предполагаю, исторически. Когда оптимизатор был еще не очень качественным и требовалось много подсказок, чтобы он либо шел, либо не шел в заданном направлении.
Черт его знает, если честно, почему они сложились.

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

Что касается хинтов - у разных людей разная практика; точка зрения "в общем случае следует стараться не использовать хинтов" более популярна, но не сказать, что повсеместно победила. Дистанционно определять, действительно ли нужны хинты или просто человек недостаточно квалифицирован и затыкает ими дыры - сами понимаете, понять не так просто. Скажем, присутствующий здесь 3л0й недавно сказал, что в их DWH весь ETL жестко захинтован, но не из-за недостатков оптимизатора, а ради гарантий стабильности планов.

ChAПросто отсутствует необходимость сразу же все удалять, а можно отложить этот процесс на окончание текущей или начало следующей сессии, либо время от времени устраивать чистку
Здесь согласен. Я фокусировался на другом: механизм уборки мусора таки надо писать и следить за тем, чтобы он не отвалился. Лишние хлопоты, минус подходу.

ChAКстати, временные таблицы тоже придется чистить. Либо пересоздавать, причем на самом верхнем уровне,
Если не ошибаюсь, пересоздание - это обычный подход в MSSQL? А так.... может быть я ошибаюсь, но очистка временной таблицы представляется мне экстремально простым занятием, единственный truncate либо drop/create.

ChACREATE VIEW v
AS SELECT id FROM t WHERE spid = @@SPID
OK, понял мысль.

ChAВообще говоря, опять же ненамного. Нет необходимости дергать диск, зато активно пользуем ОЗУ
Ну, ОЗУ мы в любом случае активно пользуем, если активно дербаним данные в таблице. Насчет одной транзакции - безусловно, но в MSSQL вроде бы приняты короткие транзакции, соответственно как минимум каждый commit будет дергать диск, и это имхо довольно неприятно.
...
Рейтинг: 0 / 0
СУБД для учета финансовых потоков?
    #34149230
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!! SergSuper
Yo.!!, блин, ну надо же так разочаровать, а вот я до этого серьёзно относился к Вашим словам. Теперь не буду.

Зачем писать о том, в чем Вы не разбираетесь и слышали краем уха? Ну это еще ладно, но врать то зачем?

пока еще Yo! на откровенной лаже никто не ловил ;)

Значит я первый Yo.!!
SergSuper
При создании любой таблицы происходит вставка записи о ней в системную таблицу sysobjects. В версиях 6.5 и раньше вставка в таблицу блокировала последующие вставки в неё. Поскольку отдельный оператор - это отдельная транзакция, а select * into #t создаёт таблицу, то на время этой транзакции sysobjects была заблокирована, а транзакция длилась пока этот select шел. В 7-й версии уже появилась неблокирующая вставка в таблицу и таких косяков не было.

Специально сейчас проверил на 2000-м - не блокирует. 2005-го у меня нет, но уверен что и там не будет.

ну давайте вместе читать о чем я вам толкую "конструкция insert into #t select блокирует системные таблицы на время всего запроса ", разницу между запросом и транзакцией надеюсь чуете ? а что вы там тестировали ? я не утверждал, что лок поставится на всю транзакцию, я говорил о запросе т.е. на время "insert into #t select"

сделал запрос который работает 20 сек и его select * into #t. Тоже самое если делать и insert into #t select. Во время выполнения запроса таблицы спокойно создаются и модифицируются.
Yo.!!, ну Вы подумайте, ну как можно было бы работать если бы они всё время блокировались?
Yo.!!
уверен что на "select * into #t" вылезет тот же косяк, т.к. проблема в том, что локи выставляются на время создания таблицы.

попробуйте. Хотя не стоит - потом же стыдно будет
Yo.!!
ЗЫ. интересно, что майкрософт до сих пор утверждает , что лок в sql2k ставится на всю транзакцию :)
Даже я с моим никаким английским могу понять что это совсем про другое
If you create a local temporary table in a stored procedure, enter a user- defined transaction, and then cancel the query , exclusive and update locks appear on the tempdb system catalog
...
Рейтинг: 0 / 0
СУБД для учета финансовых потоков?
    #34151993
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer ChAЯ делаю правильный вывод из Вашей фразы, что накапливают - плохо и не накапливают - тоже плохо ?
В целом примерно так :)Отлично, а если без интриги ? Более конкретно ?

softwarer ChAИли, лучше, как поступает Oracle ? Можно цитату на аналогичную тему из документации ?
Oracle не вычисляет курсор заранее. Цитату сходу не найду, предпочту простой пример:Возможно не уловил смысла скрипта. Вы хотели показать, что он, как и MSSQL тоже передает сразу, не накапливая результат ? И это его стандартное поведение ?

softwarer ChAХотя бы парочку примеров таких запретительных хинтов с кратким пояснением можете привести ?
Скажем,
Да, подобных хинтов в MSSQL нет, ну разве что запрет на раскрытие индексированных view. Навскидку трудно оценить практическую полезность приведенных хинтов, но их наличие, вероятно, лучше, чем их отсутствие.

softwarerНасчет упрощения запросов - скажем так, сложность запросов ограничена возможностями программиста по написанию таких запросов. Существует известная рекомендация "все, что можно сделать одним запросом, делать одним запросом".Тут я полностью согласен. Но есть маленький нюанс, умение писать запросы тренируется. В самом начале пути программист, обычно, "тормозит" даже на простых запросах, пока не запомнит хотя бы базовый синтаксис SQL на уровне рефлексов и не научится оперировать в голове множествами. Поэтому вначале многие запросы могут показаться просто невозможными для написания без разбиения или использования курсоров в смысле ANSI. Со временем, и ростом опыта, все что может быть выражено одним оператором DML, скорее всего, так и будет написано.

softwarerЧто касается хинтов - у разных людей разная практика; точка зрения "в общем случае следует стараться не использовать хинтов" более популярна, но не сказать, что повсеместно победила. Дистанционно определять, действительно ли нужны хинты или просто человек недостаточно квалифицирован и затыкает ими дыры - сами понимаете, понять не так просто.И опять же согласен, любые хинты должны применятся только тогда, когда другого пути получения требуемого результата или поведения не существует или его достижение становится слишком дорогим в каком-либо смысле.
softwarerСкажем, присутствующий здесь 3л0й недавно сказал, что в их DWH весь ETL жестко захинтован, но не из-за недостатков оптимизатора, а ради гарантий стабильности планов.Вот тут не уловил, оптимизатор как бы "хороший", а планы нестабильные ?
IMHO, если приходится пользоватся хинтами, то ровно потому, что оптимизатор может "врать", по крайней мере, в какой-то конкретной ситуации.
Еще один случай, о котором неоднократно уже шла речь ранее, ограничением свободы оптимизатора можно получить экономию ресурсов на построение и/или перестройку планов и, соответственно, повышение предсказуемости поведения на production. Но стабильность плана в таком случае уже не является самоцелью, это просто следствие борьбы за общую производительность.
Если цель состоит только в стабильности планов, то этого можно добиваться и другими способами, косвенными, в частности, постараться убрать причины, которые могут привести к изменению плана, ну, например, запретить изменение табличной статистики.

softwarer ChAКстати, временные таблицы тоже придется чистить. Либо пересоздавать, причем на самом верхнем уровне, Если не ошибаюсь, пересоздание - это обычный подход в MSSQL?Ээээ потерял контекст. Обычный подход к чему ? К работе с временными таблицами ? Тогда, да. Или что-то еще подразумевается ?

softwarerединственный truncate либо drop/create.Это при условии, если нет идентификатора по фильтрам, ведь различных выборок по разным условиям может быть несколько. Все таки с MDI работаем, здесь выборка, там выборка. И уже появляются сложности. В какой момент и с каким наименованием надо создавать временную таблицу. Некоторые процедуры могут одинаково работать с разными выборками, но тогда динамические запросы съедят всю пользу от подхода "одна ВТ - один Фильтр". Значит придется делать одну, но с теми же идентификаторами по фильтрам. Естественно, ни truncate, ни drop/create уже не "катят".

softwarer ChAВообще говоря, опять же ненамного. Нет необходимости дергать диск, зато активно пользуем ОЗУ
Ну, ОЗУ мы в любом случае активно пользуем, если активно дербаним данные в таблице. Насчет одной транзакции - безусловно, но в MSSQL вроде бы приняты короткие транзакции, соответственно как минимум каждый commit будет дергать диск, и это имхо довольно неприятно.Ну, не думаю, что в Oracle поощряются длинные транзакции. Они должны продолжаться ровно столько, сколько нужно в конкретном случае. В этом смысле, MSSQL не отличается от других RDBMS. В тоже время, понимая особенности работы с логом, нетрудно получить значительный выигрыш при использовании явных транзакций вместо стандарного autocommit-а. Например
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
use pubs
GO
CREATE TABLE t (id int primary key)
GO
DECLARE @i int, @d datetime
SELECT @i =  0 , @d = CURRENT_TIMESTAMP
WHILE @i <  10000  BEGIN
	INSERT INTO t SELECT @i
	SET @i = @i +  1 
END
PRINT DATEDIFF(ms, @d, CURRENT_TIMESTAMP)
TRUNCATE TABLE t
SELECT @i =  0 , @d = CURRENT_TIMESTAMP
BEGIN TRAN
WHILE @i <  10000  BEGIN
	INSERT INTO t SELECT @i
	SET @i = @i +  1 
END
COMMIT
PRINT DATEDIFF(ms, @d, CURRENT_TIMESTAMP)
GO
DROP TABLE t
Результат:
Код: plaintext
1.
2.
2826
1046
В данном случае выигрыш почти в 3 раза и то, благодаря тому, что у меня SCSI-диски с приличными оборотами и кэшем, а также БД и логи живут на разных дисках. В более прозаческих ситуациях разница может быть сильно больше.


P.S. Off: Книгу получили ?
...
Рейтинг: 0 / 0
СУБД для учета финансовых потоков?
    #34164998
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ChAОтлично, а если без интриги ? Более конкретно ?
Я же сказал, оптимально - не вычислять курсор раньше, чем данные реально потребуются.

ChAВозможно не уловил смысла скрипта. Вы хотели показать, что он, как и MSSQL тоже передает сразу, не накапливая результат ?
Нет. "Передача" здесь идет с сервера на сервер же, из курсора в ХП. И любая попытка вычислить 32326965938056011787168549511729891841 запись и выполнялась бы..... как минимум, довольно долго. Суть этого скрипта в том, что хотя запрошено вышеуказанное количество записей, реально вычисляются 10'000'000 - столько, сколь профетчено.

ChAНо есть маленький нюанс, умение писать запросы тренируется.
Само собой. Я здесь имел в виду уже натренированное умение; все же есть некая граница размера запроса, которую программист постарается не переходить.

ChAВот тут не уловил, оптимизатор как бы "хороший", а планы нестабильные ?
Тут за подробностями к автору. Я понял его так, что "дуют на воду", при их объемах в этом есть свой смысл.

ChAЭэээ потерял контекст. Обычный подход к чему ? К работе с временными таблицами ?
Да, именно.

ChAЭто при условии, если нет идентификатора по фильтрам, ведь различных выборок по разным условиям может быть несколько. Все таки с MDI работаем, здесь выборка, там выборка.
Да, пожалуй. Я привык делать немодальные окна в разных сессиях, соответственно не учел варианта "многие в одной".

ChAНу, не думаю, что в Oracle поощряются длинные транзакции. Они должны продолжаться ровно столько, сколько нужно в конкретном случае.
В Oracle длинные транзакции не составляют проблемы, и соответственно "сколько нужно в конкретном случае" оказывается именно "сколько нужно", а не "сколько не удается уменьшить".

ChAP.S. Off: Книгу получили ?
Да, спасибо.
...
Рейтинг: 0 / 0
5 сообщений из 180, страница 8 из 8
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / СУБД для учета финансовых потоков?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]