Подскажите:

вот есть две части одной и той же базы:
- А (собранные данные до времени T);
- В (данные за время Т+t)

Вопрос: можно ли формировать пишущую транзакцию сначала по данным А (например снапшот в момент времени Т), затем по данным В (уже не обращаясь к данным А) - ?

То есть всегда ли можно так формировать пишущую транзакцию - (в каких случаях можно, и есть ли транзакции - когда нельзя)?

Что понимать под "формировать" - то есть проверить на все ограничения, на все триггеры и т.д.

White OwlЧего-чего????

Прошу прощения, уточним вопрос.

1) Создаем в момент времени Т транзакцию, с уровнем изоляции "snapshot" (в терминологии интербейса),
2) все новые данные, которые приходят после момента времени Т - пишем в дополнительную (пустую в начале) базу Temp.
3) Вручную (запросами) проверяем по основной базе все ограничения (unique key, foreign key, check, procedure, ...) на данныe, которые хотим писать в базу.
4) (после окончания проверки) В момент времени (Т+t) - меняем уровень изляции на "snapshot table stability" (то есть в основной базе блокируем поля, куда хотим писать).
5) После этого вручную (запросами) проверяем по базе Temp все ограничения (unique key, foreign key, check, procedure, ...) на данныe, которые хотим писать в базу.
6) если все проверки прошли - то пишем в базу (отключив при этом проверки сервера - допустим это возможно)
----------
Вопрос:
процедура из действий (1-6) -
тождественна - транзакции "snapshot table stability" в момент времени Т (и которая будет что то писать в базу)
-----------
(получилось много букв)

White OwlА вопрос то где? Тождественна ли эта процедура или нет?
Именно в этом и вопрос.
------------
"А все таки, что ты хочешь в конце получить?"
- изучаем кластера из SQL серверов.
------------
А без кластеров -
если мы начинаем транзакцию (в момент времени Т), с уровнем изоляции "snapshot" (то есть без блокировок чего либо) - и работаем (готовимся писать) по всей базе (большой),

и завершаем (в момент времени (Т+t) - меняем уровень изляции на "snapshot table stability") - на куске данных, значительно меньшего объема (Temp << всей базы)

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

White Owl Собственную СУБД?
(вроде) есть определение "линейные функции": если F(A+B)=F(C), где С=А+В, то функция F - линейна.
---------
Соответсвенно и вопрос: Линейны ли транзакции (пишущие)?
(где транзакции<=>F, C<=>база, А,С<=>части базы)

Пользователь White Owl Собственную СУБД?
(вроде) есть определение "линейные функции": если F(A+B)=F(C), где С=А+В, то функция F - линейна.
---------
Соответсвенно и вопрос: Линейны ли транзакции (пишущие)?
(где транзакции<=>F, C<=>база, А,С<=>части базы)
не, не так: верно ли для транзакций F(A)+F(B)=F(C)

White Owl Пользователь- то хотим получить бонус в виде меньшего времени блокировки базы (полей) (где то эдак на порядка три четыре). Неа, не получите.

Все гораздо проще:
(напишем литературный роман, букв еще больше)
---------
есть база конторы "рога и копыта", 10Гбайт,
светлым субботним утром в 10-00 начинаем транзакцию "snapshot table stability" (то есть в блокируем поля, куда хотим писать, и которые связаны с этими полями)
в 10-05 завершаем транзакцию
потратили 5 минут
начальство недовольно "ты учился чему нибудь у себя в универе, или нет? может тебе зарплату уменьшить?"
чешем репу...
---------
тут что то стукнуло - папка свалилась на голову (не смертельно)
попытка №2:
---------
та же контора, та же база,
уже в 11-00 начинаем транзакцию "snapshot" (ничего не блокируя)
и в течении 5 минут проверяем, хорошие данные (для нашей базы) - или нет (проверяем все констрейны)
в 11-05 - решили "зер гуд" - "олл райт" - можно писать в базу,
Но!
гады операторы за эти 5 минут набили еще 10 накладных в базу, пока мы ковырялись, и хрен знает - совместимы они с нашими данными (для записи), или нет
блокируем в базе поля, куда хотим писать (и еще некоторые, связанные) - чтоб эти операторы нам дальше кровь не портили... ("snapshot table stability")
через одно место (из временной базы Temp - куда мы паралельно эти новые накладные складывали) - достаем эти 10 накладных и проверяем на совместимость с нашими данными на запись,
уфф, отлегло на сердце, можно писать
и все пишем в базу (отключив нахрен проверки - чего дважды проверять)
в 11-06 завершили транзакцию.
---------
итого мы блокировали базу 1 минуту - вместо 5 минут
---------
идем к начальству "слышь, иваныч - премию хочу" - "будет тебе премия - в новом квартале, если план выполним и контору не разгонят"
чешем репу - и нафига столько мучений? - премии все равно нет...

maytonИМХО бред!
Обоснуй! (любопытно однако)
Или переведи - что сие означает?

mayton1) IMHO - In My Humble Opinion

2) В условиях, когда транзакции пользователей идут непрерывно - все ваши попытки получить актуальный отчет тщетны. Вы ВСЕГДА будете видеть ретроспективу.
По первому пункту - понятно.
По второму пункту - непонятно.
"транзакции пользователей идут непрерывно" - так ведь нет,
1) - имеем снапшот на момент Т, "транзакции пользователей идут непрерывно"
2) - имеем блокировки с момента времени Т+t - и ни каких "транзакции пользователей идут непрерывно" не будет.
--------------
Или мы каждый о своем, женском?

maytonДавайте вернемся в самое начало:
Верно я вас понял?
Конечно нет.
Это не репортаж с производственных фронтов, это литературное описание проблемы, вопроса - чтобы было понятнее.
-------------
А вопрос - "чисто теоретический вопрос по SQL", к конкретному типу SQL серверов отношение не имеет (тем более к производству)
-------------
Вопрос был:
Линейны ли транзакции (пишущие)?
(где транзакции<=>F, C<=>база, А,B<=>части базы, C=A+B)
верно ли для транзакций F(A)+F(B)=F(C)
--------------
и фактически весь тред, все мои литературные изыски - только комментарии к этому вопросу (ну не получается у меня сразу понятно излагать...)

White Owl ПользовательВопрос был:
Линейны ли транзакции (пишущие)?
(где транзакции<=>F, C<=>база, А,B<=>части базы, C=A+B)
верно ли для транзакций F(A)+F(B)=F(C)
Еще уточни что такое "части базы". И что ты подразумеваешь под линейностью?
Вот я знаю что такое атомарность транзакций, или что такое конкурентные транзакции, но что такое линейные???
"линейные" - это наше доморощенное изобретение!
- есть линейный функции, операции <=> так же определяем линейные транзакции. Под операцией, которую выполняет транзакция, интересует: проверка данных для записи по ограничениям (unique key, foreign key, check,..), триггерам - если проверка проходит - пишем данные в базу.

"части базы" - это не наше доморощенное изобретение,
например: база на момент времени Т (часть №1), приращение базы за время t (до момента времени T+t, часть №2)

White OwlТогда ответ будет: нет.
Никто не гарантирует что между F(A) и F(B) не влезет другой юзер со своей F(A1) а потом еще один с F(A2) и так далее.
А с точки зрения одного коннекта при условии монопользовательской работы с базой, F(A)+F(B) всегда будет равна F(A+B).
"Никто не гарантирует что между F(A) и F(B) не влезет другой юзер со своей F(A1) а потом еще один с F(A2) и так далее."
- если мы блокируем заинтересаванные поля - то ни кто на них не влезет.

"А с точки зрения одного коннекта при условии монопользовательской работы с базой, F(A)+F(B) всегда будет равна F(A+B)."
- скоре всего, для 99,99% реальных задач - транзакции линейны: F(A)+F(B)=F(A+B)
-----------------------------
Тогда - в случае равных прав у всех пользователей - мы можем почти на порядок уменьшить время блокирования базы при пишущих транзакциях - правда при некоторой доработке логики работы SQL сервера.
(и почему не слышно фанфар и восторженных аплодисментов?)

White Owl Пользователь"Никто не гарантирует что между F(A) и F(B) не влезет другой юзер со своей F(A1) а потом еще один с F(A2) и так далее."
- если мы блокируем заинтересаванные поля - то ни кто на них не влезет. Нет. Блокировка существует только на время транзакции. Как только транзакция закончена, все установоленные в ней блокировки снимаются.

- это да. Тут надо понимать так (как уже раза три здесь писалось):
транзакция А без блокировок, затем транзакция В - уже блокирует в начале, после чего - останов записи в базу Temp, и работа с базой Temp: и ни одна сволочь не проскочит!
--------
"А что, 99.99% реальных задач работают в режиме одна база - один юзер?"
- нет. столько линейных транзакций (я могу придумать нелинейные, но не вижу их реальных применений).
--------------
"Фанфар не будет. Будут тухлые яйца и гнилые помидоры :)"
- с (..) чего бы это? вроде все реально, или нет?

White Owl Пользовательтранзакция А без блокировокНевозможно в принципе. Ни одна БД не даст тебе делать изменения данных без блокирования других юзеров.
так и я о том же (напоминает разговор глухого со слепым).
транзакция А без блокировок - она и не пишет ничего - она просто готовит, проверяет данные для записи.
---------------
"Нет, не реально. "
хорошо. я здаюсь.
есть такой анегдот - как китайцы взломали сервер пентагона: после милиарда попыток ввести пароль "мао" - сервер здался и согласился.