The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

SQL flame


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Date: Wed, 10 Jul 2002 18:14:30 +0400
From: Serg Oskin <Serg.Oskin@f20.n5020.z2.fidonet.org>
Subject: SQL flame

>>>>> "VK" == Vasily Korytov writes:

 SR> Alex Tomas <bzzz@tmi.comex.ru> wrote:
 AT> разве термин 'база данных' (хотя правильнее было бы сказать 'система
 AT> управления базами данных') подразумевает обязательное наличие транзакций
 AT> в известном виде? имеются задачи, которым не нужна возможность атомарного
 AT> изменения нескольких таблиц. или нет?

 SR> Если в СУБД нет транзакций и она не обеспечивает целостности данных
 SR> (лично я не представляю, как её обеспечить без транзакций), то я бы
 SR> не стал называть это СУБД. Хотя и для такой системы есть области
 SR> применения. Собственно, примерно это и говорилось в доках MySQL.

 VK> Давай почитаем вместе. =))

 VK> MySQL Reference Manual for version 3.23.33:

 VK> +----------------------------------------------------------------------
 VK> | MySQL has made a conscious decision to support another paradigm for
 VK> | data integrity, ``atomic operations.'' It is our thinking and
 VK> | experience that atomic operations offer equal or even better
 VK> | integrity with much better performance. We, nonetheless, appreciate
 VK> | and understand the transactional database paradigm and plan, within
 VK> | the next few releases, to introduce transaction-safe tables on a per
 VK> | table basis. We will be giving our users the possibility to decide
 VK> | if they need the speed of atomic operations or if they need to use
 VK> | transactional features in their applications.
 VK> +----------------------------------------------------------------------

Hе надо путаться в терминах (и нам и им). Достаточно взять в качестве
примера следующее:
1. update двух таблиц - если не удалось изменить вторую таблицу, нужно
   вернуть исходное состояние первой. При этом пока изменяем вторую,
   третью, ... таблицы изменения в первой никто кроме меняющего видеть не
   должен - иначе кто-то их заюзает, а мы их отменим...
2. _Работающие_ primary/foreign keys.
Без этих вещей нет правильной мультиюзерской работы по изменению данных и
следовательно их целостности.
Зная математику этих операций могу смело сказать, что без _значительного_
понижения скорости работы их не реализовать.

 VK> [...]

А здесь в основном говорится о "физической" целостности, а не о логической.

-- 
	Serg (mailto:oskin@macomnet.ru http://oskin.msk.ru/).
~
~
:q!

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру