|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Vladimir Pavlikov 2:5020/400 26 Dec 2002 18:44:24 To : Ilya Zvyagin Subject : Re: Синхронизация доступа к БД -------------------------------------------------------------------------------- Hello, Ilya Zvyagin! You wrote to Vladimir Pavlikov on Wed, 25 Dec 2002 07:20:12 +0000 (UTC): IZ> Там нет проблем с разведением таких транзакций. Там проблема с IZ> приведением базы в рабочий вид после разведения этих транзакций. Рабочий вид восстанавливать не надо - он всегда такой. А чистка неактуальных версий... ну есть одна дополнительная транзакция, никак не мешающая остальным - это не проблема. IZ> Ладно, фиг с ними, со спорами, просто интересно - и почему же самые IZ> "продвинутые" на рынок СУБД (т.е. лидеры) до сих пор не версионники IZ> Скажешь "А зачем им ? Пипл и так хавает" ? Конечно, именно так и скажу. Тот же mySQL, которой вовсе не сервер, является одним из наиболее распространенных просто потому, что быстрый, и для своих задач (Web) чаще всего достаточен. Кроме того, "есть мнение", что до 80+% использования bd2, oracle, mssql прихо- дится на режим "из пушки по воробьям" : мощность самих серверов и "подлежащего" железа столь велика для задач, что сервера работают, в основном, в однопользовательском режиме в почти любой момент времени - тут и блокирование почти не применяется. Отсюда и самодовольные "у меня нет проблем!", с которыми мы частенько сталкиваемся :) Тем не менее, PostrgeSQL, MS Exchange (хоть это и не БД сервер) и Opacle - вещи довольно широко исполь- зуемые. А одного того факта, что [тогда] практически чуть ли не единолочный лидер Оракл стал хоть и "сбоку"-, но все же вер- сионником - достаточно, чтобы оценить, насколько это важно : "просто так" никто не будет решать столь непростую задачу для сверхпопулярного _лидера_ рынка. --------------------------------------------- Владимир Павликов. -- Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: Talk.Mail.Ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/6488ff30ee32.html, оценка из 5, голосов 10
|