Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
 Отличие пессимистической и оптимистической стратегии  [new]
пессимистической и оптимистическ
Guest
В чем отличие пессимистической и оптимистической стратегии в блокировочнике и версионнике и в каком случае возможен и/или наиболее вероятен update conflict, а в каком deadlock?

Насколько я понимаю:
1. Блокировочник:
1.1. Пессиместическая: накладывается U-блокировка на все прочитанные данные и X-на все измененные. Наиболее вероятен Deadlock. Не возможен Update Conflict.
1.2. Оптимистическая: накладывается S-блокировка только на момент чтения, как только трока прочитана - блокировка снимается. На все измененные накладывается X-блокировка. Менее вероятен чем в (1.1), но все же возможен Deadlock. Возможен Update Conflict, но не понятно по каким критериям его определит СУБД.

2. Версионник:
2.1. Пессиместическая: при чтении никакие блокировки не накладываются, а при изменениях накладываются X-блокировки. Вероятность Deadlock меньше чем у версионника (1.1) и (1.2). Не возможен Update Conflict.
2.2. Оптимистическая: ни при чтении, ни при записи никакие блокировки не накладываются. Deadlock невозможен. Возможен Update Conflict, но опять же не понятно по каким критериям его определит СУБД.

И какой стратегии придерживаются различные СУБД: Oracle, PostgreSQL, MS SQL, Firebird?
6 янв 12, 13:34    [11864483]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
что-то в последнее время многовато появляются тем от анонимов, которые потом просто скатываются в срач. Вот и сейчас, кажется что вот снова начнется. И откуда столько троллей.
6 янв 12, 13:47    [11864540]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54847

пессимистической и оптимистическ
2. Версионник:

Пытаться описать работу версионника в терминах блокировочника - заведомо провальная
стратегия. Они работают совсем не так.

Posted via ActualForum NNTP Server 1.5

6 янв 12, 13:51    [11864563]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
А полльзовался ли ТС поиском,перед тем как задать вопрос? Там столько доступной инфы, например вот кратко:http://atamanenko.blogspot.com/2009/04/blog-post_22.html
6 янв 12, 13:53    [11864571]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
или википедия: http://ru.wikipedia.org/wiki/%C1%EB%EE%EA%E8%F0%EE%E2%EA%E0_(%D1%D3%C1%C4)
та мля,столько инфы. Автор, идите лучше на ... в гугл...
6 янв 12, 13:55    [11864580]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Хорош тролить
Guest
Ggg_old
что-то в последнее время многовато появляются тем от анонимов, которые потом просто скатываются в срач. Вот и сейчас, кажется что вот снова начнется. И откуда столько троллей.

Не нервничай. По делу есть что сказать?
Модератор удалите оффтоп Ggg_old.
6 янв 12, 13:56    [11864581]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
А как он работает?
Guest
Dimitry Sibiryakov
пессимистической и оптимистическ
2. Версионник:

Пытаться описать работу версионника в терминах блокировочника - заведомо провальная
стратегия. Они работают совсем не так.

А как он работает?
На уровне синхронизации многопоточности все реализуется и соответственно описывается через блокировки, в том числе версионники.
6 янв 12, 13:59    [11864591]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Таблоид
Member

Откуда:
Сообщений: 9456
Блог
пессимистической и оптимистическ
<...>
2. Версионник:
2.1. Пессиместическая: при чтении никакие блокировки не накладываются, а при изменениях накладываются X-блокировки. Вероятность Deadlock меньше чем у версионника (1.1) и (1.2). Не возможен Update Conflict.
2.2. Оптимистическая: ни при чтении, ни при записи никакие блокировки не накладываются. Deadlock невозможен. Возможен Update Conflict, но опять же не понятно по каким критериям его определит СУБД.

<...> Firebird?

Сеанс в Firebird всегда сразу блокирует запись при выполнении update/delete. Другие сеансы точно не смогут изменить эту запись, а при работе в транзакции с no record_version - не смогут даже прочитать эту запись и все остальные после неё в порядке их обработки. Разумеется, из-за этого они не смогут и обновить такие записи (ведь их сначала надо найти - т.е. прочитать).

Session #1.
-- создаём таблицу, вводим три строки, выполняем update одной из них (без commit'a):
C:\1INSTALL\FIREBIRD\Data>isql -n aaa.fdb
Database: aaa.fdb
SQL> recreate table t(id int, f01 int); commit;
SQL> recreate table t(id int primary key, f01 int); commit;
SQL> create descending index t_idx on t(id); commit;
SQL> insert into t values(1,100);
SQL> insert into t values(2,200);
SQL> insert into t values(3,300);
SQL> commit;
SQL> update t set f01=199 where id=2;

Session #2.
C:\1INSTALL\FIREBIRD\Data>isql -n aaa.fdb
Database: aaa.fdb

---------- проверка доступности записи -----------

SQL> commit; set transaction read committed record_version;
SQL> update t set f01=201 where id=2;
^C -- срубил ввиду бесконечного ожидания

C:\1INSTALL\FIREBIRD\Data>isql -n aaa.fdb
Database: aaa.fdb
SQL> commit; set transaction read committed no record_version;
SQL> update t set f01=201 where id=2;
^C -- срубил ввиду бесконечного ожидания

C:\1INSTALL\FIREBIRD\Data>isql -n aaa.fdb
Database: aaa.fdb
SQL> commit; set transaction read committed record_version lock timeout 4;
SQL> update t set f01=201 where id=2;
Statement failed, SQLSTATE = 40001
lock time-out on wait transaction
-deadlock
-update conflicts with concurrent update
-concurrent transaction number is 30


SQL> commit; set transaction read committed no record_version lock timeout 4;
SQL> update t set f01=201 where id=2;
Statement failed, SQLSTATE = 40001
lock time-out on wait transaction
-deadlock


SQL> commit; set transaction snapshot lock timeout 4;
SQL> update t set f01=201 where id=2;
Statement failed, SQLSTATE = 40001
lock time-out on wait transaction
-deadlock
-update conflicts with concurrent update
-concurrent transaction number is 30


---------- проверка доступности чтения -----------

SQL> commit; set transaction read committed record_version lock timeout 4;
SQL> select * from t;

ID F01
============ ============
1 100
2 200
3 300

SQL> commit; set transaction read committed no record_version lock timeout 4;
SQL> select * from t;

ID F01
============ ============
1 100
Statement failed, SQLSTATE = 40001
lock time-out on wait transaction
-deadlock


SQL> commit; set transaction snapshot lock timeout 4;
SQL> select * from t;

ID F01
============ ============
1 100
2 200
3 300

-- пробуем при NO record_version прочитать всё, за исключением "проблемной" записи:
SQL> commit; set transaction read committed no record_version lock timeout 4;
SQL> select * from t where id<>2;

ID F01
============ ============
1 100
Statement failed, SQLSTATE = 40001
lock time-out on wait transaction
-deadlock


-- то же самое, но используя навигацию индексу:
SQL> set plan on;
SQL> commit; set transaction read committed no record_version lock timeout 4;
SQL> select * from t where id<>2 order by id desc;

PLAN (T ORDER T_IDX)

ID F01
============ ============
3 300
Statement failed, SQLSTATE = 40001
lock time-out on wait transaction
-deadlock
6 янв 12, 14:07    [11864628]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54847

А как он работает?
На уровне синхронизации многопоточности все реализуется и соответственно описывается через
блокировки, в том числе версионники.

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

RTFM:
http://www.ibphoenix.com/resources/documents/search/doc_27
http://ibase.ru/devinfo/mga.htm

Posted via ActualForum NNTP Server 1.5

6 янв 12, 14:08    [11864630]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Блокировочник vs Версионник
Guest
Смешались в кучу кони, люди... ((с) М.Ю. Лермонтов. Бородино)

пессимистической и оптимистическ
И какой стратегии придерживаются различные СУБД: Oracle, PostgreSQL, MS SQL, Firebird?


А СУБД то здесь причем, если выбор стратегии "оптимистическая" или "пессимистичекая" лежит полностью на плечах разработчика?!

Update Conflict в блокировочнике при выбранной оптимистической стратегии, опять же, без дополнительных телодвижений со стороны разработчика не то, чтобы не разрешим самой СУБД, он ей не детектируем.

Какую задачу пытаемся решить? Обсудить как каждая из СУБД, поддерживающая версионность, детектирует и разрешает Update Conflict?
6 янв 12, 15:13    [11864873]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
пессимистической и оптимистическ
Guest
Блокировочник vs Версионник
Update Conflict в блокировочнике при выбранной оптимистической стратегии, опять же, без дополнительных телодвижений со стороны разработчика не то, чтобы не разрешим самой СУБД, он ей не детектируем.

А Update Conflict в блокировочнике вообще возможен?
S-блокировка накладывается на все что читаем, X-на все что меняем, U-помогает избежать deadlock при изменении после чтения. Везде где наложена любая из этих блокировок изменение данных другими транзакциями не возможно - соответственно не возможен Update Conflict.

Допустим:
https://www.sql.ru/forum/afsearch.aspx?s=Update+Conflict&submit=%CD%E0%E9%F2%E8&bid=1
По этим словам в MS SQL только либо конфликт с FK, либо в версионной транзакции.

Блокировочник vs Версионник
Какую задачу пытаемся решить? Обсудить как каждая из СУБД, поддерживающая версионность, детектирует и разрешает Update Conflict?

Да, именно что.
Особенно интересует оптимистическая стратегия в версионниках и разрешение Update Conflict в них.
7 янв 12, 01:05    [11866826]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54847

пессимистической и оптимистическ
Особенно интересует оптимистическая стратегия в версионниках и разрешение Update Conflict
в них.

А Вам не приходило в голову, что каждый сервер это делает по-разному? И даже один и тот же
- в разных ситуациях?..
Firebird, например, детектирует update conflict по наличию версии записи с номером больше
чем ожидаемый. Но никогда сама не пытается этот конфликт разрешить, честно сообщая о нём
пользователю.
Oracle - наоборот, разрешает конфликт откатывая один из запросов и пытаясь начать всё заново.

Posted via ActualForum NNTP Server 1.5

7 янв 12, 01:28    [11866863]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
пессимистической и оптимистическ
Guest
Dimitry Sibiryakov
пессимистической и оптимистическ
Особенно интересует оптимистическая стратегия в версионниках и разрешение Update Conflict
в них.

А Вам не приходило в голову, что каждый сервер это делает по-разному? И даже один и тот же
- в разных ситуациях?..
Firebird, например, детектирует update conflict по наличию версии записи с номером больше
чем ожидаемый. Но никогда сама не пытается этот конфликт разрешить, честно сообщая о нём
пользователю.
Oracle - наоборот, разрешает конфликт откатывая один из запросов и пытаясь начать всё заново.
Так именно по этому и спрашиваю, что не знаю всех вариантов.
Т.е. Firebird при commit блокирует список всех всех прочтенных в этой транзакции записей, кстати он наверное иногда очень большой получается. Пробегает по этому списку и для каждой записи в ней смотрит последнюю версию. Ну а блокирует видимо для того, чтобы пока он это все делает не появилось новых записей, правильно?
Т.е. Firebird блокирует строки только изменяемые и только на время изменения записей и все строки во время commit?

А способы возникновения update conflict в Oracle и Firebird схожи, т.е. всегда когда другая транзакция меняет любую строчку которая читалась/менялась в нашей транзакции?
7 янв 12, 01:44    [11866894]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54847

пессимистической и оптимистическ
Т.е. Firebird при commit блокирует список всех всех прочтенных в этой транзакции записей

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

пессимистической и оптимистическ
Т.е. Firebird блокирует строки только изменяемые и только на время изменения записей и все
строки во время commit?

Нет, Firebird вообще не блокирует записи (только разделяемые ресурсы, такие как буфер
страницы в кэше) и тем более - при commit. Я же, блин, выше уже дал две ссылки. Чукча не
читатель?..

Posted via ActualForum NNTP Server 1.5

7 янв 12, 02:10    [11866926]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
пессимистической и оптимистическ
Guest
Dimitry Sibiryakov
пессимистической и оптимистическ
Т.е. Firebird при commit блокирует список всех всех прочтенных в этой транзакции записей

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

Понял. Откатывается Update Statment с ошибкой Update Conflict если во время него кто-то изменил то, что он тоже менял. А дальше клиент повторяет операцию и если предыдущая помешавшая транзакция ещё не закомитилась, т.е. Update Statment нарвался на незакомиченные версии, то в зависимости от wait/no wait ждет пока она закомитится (аки блокировку, но не блокировку). А если no wait, то снова откатывает Update Statment, но уже не с Update Conflict, а с Lock Conflict(deadlock).

А причины возникновения и способы детектирования Update Conflict в Oracle схожи, разница лишь в том, что Oracle автоматом заново проводит Update Statment до тех пор пока не станет успешной?

Dimitry Sibiryakov
пессимистической и оптимистическ
Т.е. Firebird блокирует строки только изменяемые и только на время изменения записей и все
строки во время commit?

Нет, Firebird вообще не блокирует записи (только разделяемые ресурсы, такие как буфер
страницы в кэше) и тем более - при commit. Я же, блин, выше уже дал две ссылки. Чукча не
читатель?..

Записи не блокируются - блокируется страница на которой лежит запись во время её изменения. Но это уже техническая реализация.

Кстати, т.к. Firebird опирается он только на номера версий, и в нем нету блокировок, то он не может пройти по их графу и найти deadlock, по этому в зависимости от wait/no wait он просто предполагает, что это обычное ожидание предыдущей транзакции или Lock Conflict(deadlock).
На сколько я понимаю в Oracle тоже нету блокировок и их графа и там разруливается deadlock подобным образом?
7 янв 12, 02:31    [11866960]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54847

пессимистической и оптимистическ
Кстати, т.к. Firebird опирается он только на номера версий, и в нем нету блокировок, то он
не может пройти по их графу и найти deadlock,

Так и не образуется никакого дедлока при самом апдейте. Только при ожидании завершения
конкурирующей транзакции, а тут уже граф локов есть. Или таймаут ожидания (в зависимости
опять же от параметров).

Posted via ActualForum NNTP Server 1.5

7 янв 12, 02:48    [11866977]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
пессимистической и оптимистическ
Guest
Dimitry Sibiryakov
пессимистической и оптимистическ
Кстати, т.к. Firebird опирается он только на номера версий, и в нем нету блокировок, то он
не может пройти по их графу и найти deadlock,

Так и не образуется никакого дедлока при самом апдейте. Только при ожидании завершения
конкурирующей транзакции, а тут уже граф локов есть. Или таймаут ожидания (в зависимости
опять же от параметров).

Здесь я уже общий случай рассматриваю. Может быть обычный долгий "лок", а может и "дедлок", если та транзакция которую ждут решит изменить запись которую изменил предыдущий стейтмент нашей ждущей транзакции.

А вот насчет графа локов не понял. Как может существовать граф блокировок без существования самих блокировок? :)
Или имеется ввиду некий граф ожиданий друг друга транзакциями?
7 янв 12, 03:04    [11866989]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7008
пессимистической и оптимистическ
А вот насчет графа локов не понял. Как может существовать граф блокировок без существования самих блокировок? :) Или имеется ввиду некий граф ожиданий друг друга транзакциями?

ожидание коммита/роллбека конкурирующей транзакции реализовано через менеджер блокировок, просто уровень блокировок другой (транзакции, а не записи).
7 янв 12, 06:06    [11867129]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
В документацию по TOPLink/S (универсальный O/R framework для Smalltalk'ов) про их реализацию "оптимизма" рассказывалось так:

* в таблице заводится дополнительное поле version (числовое);
* обновление (TOPLink'ом) производится так:
UPDATE таблица
SET version = version + 1
WHERE (поиск-по-ключу) AND version = :считанная-нами-версия

(можно также использовать не числовую, а Timestamp'овую version)

И если этот UPDATE обновил 1 запись, то всё хорошо. А если 0, то это означает, что кто-то обновил эту запись до, и TOPLink выбрасывает исключение, и разбирайтесь с этим, как знаете (к примеру, уведомите юзера, что кто-то успел раньше).

Вот и всё. Конечно, чтобы оно работало на блокировочнике действительно "оптимистично", надо помнить, что даже чтение (обычно) накладывает блокировку. Какая блокировка и на что, каков её срок жизни - зависит от уровня изоляции (а курсор with hold и его блокировки даже переживут commit, хотя не rollback). На блокировочнике надо будет выбрать изоляцию пониже и коммититься почаще.
7 янв 12, 12:42    [11867362]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
поправка
UPDATE таблица
SET version = version + 1, ... прочие изменения
WHERE (поиск-по-ключу) AND version = :считанная-ранее-нами-версия
7 янв 12, 13:40    [11867417]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
пессимистической и оптимистическ
Guest
Victor Metelitsa
поправка
UPDATE таблица
SET version = version + 1, ... прочие изменения
WHERE (поиск-по-ключу) AND version = :считанная-ранее-нами-версия

И этот Update Statment крутиться в цикле до первого успешного изменения?
7 янв 12, 15:27    [11867576]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
из 10 возможных только 9
Guest
Victor Metelitsa
И если этот UPDATE обновил 1 запись, то всё хорошо. А если 0, то это означает, что кто-то обновил эту запись до, и TOPLink выбрасывает исключение, и разбирайтесь с этим, как знаете (к примеру, уведомите юзера, что кто-то успел раньше).

А если UPDATE STATMENT обновляет не 1, а 10 записей, или из 10 возможных обновил только 9 это считается успешным?
7 янв 12, 17:41    [11867890]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
пессимистической и оптимистическ
Victor Metelitsa
поправка
UPDATE таблица
SET version = version + 1, ... прочие изменения
WHERE (поиск-по-ключу) AND version = :считанная-ранее-нами-версия

И этот Update Statment крутиться в цикле до первого успешного изменения?


Я уже сказал - выбрасывается исключение. Как оно будет обрабатываться - уже не забота TOPLink'а. В принципе, цикл здесь подразумевается, но со взаимодействем с пользователем.

Пользователь прочитал данные (в какой-то форме), изменил, нажал кнопку "сохранить". Выскочило исключение: "Пока, мол, вы чем-то занимались, данные уже изменились. Теперь они не такие-то, а такие-то. Хотите ли изменить их?". Пользователь, предположим, правит их, нажимает на кнопку сохранить. А ему в ответ - "ой, а эти данные опять кто-то успел изменить". И так далее. Цикл, пока сохранение не пройдёт или пользователю не надоест.

Ни о каких 10 записях в этом примере не может быть и речи. Ключ - это первичный или уникальный ключ, обновляется или одна запись, или ни одной.

Если расширять пример до N записей (и надо ещё придумать, как), то только N успешно обновлённых записей может быть успехом.

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

Классический вариант, который я видел "везде" - проверить все старые значения полей.
UPDATE таблица
SET version = version + 1, ... прочие изменения
WHERE (поиск-по-ключу) AND поле1 = :старое-значение-поля1 AND ... AND полеN = :старое-значение-поляN

но вариант выше с version проще и универсальнее (LOB'ы обычно сравнить не так легко).
7 янв 12, 21:16    [11868450]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
Victor Metelitsa
Классический вариант, который я видел "везде" - проверить все старые значения полей.

"Классический", надеюсь, не всегда синоним слова "тупой". Корректно проверить все старые значения полей обычно немного тяжеловато, ибо во-первых, из-за null-ов, сравнение получается громоздким, во-вторых, блобы обычно немного неудобно сравнивать на равенство, в-третьих, объёмы...
8 янв 12, 10:55    [11869703]     Ответить | Цитировать Сообщить модератору
 Re: Отличие пессимистической и оптимистической стратегии  [new]
Таблоид
Member

Откуда:
Сообщений: 9456
Блог
softwarer
из-за null-ов, сравнение получается громоздким
в Firebird есть замечательная конструкция для этого: a is [not] distinct from b.
8 янв 12, 12:17    [11869816]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить