Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
 Re: nested transaction vs savepoint  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

softwarer пишет:

> Вот это как раз очень спорный момент. Насколько я знаю, в некоторых
> серверах существует возможность менять уровень изоляции внутри
> транзации, но с моей точки зрения это - нонсенс. Вызвано это, насколько

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

Posted via ActualForum NNTP Server 1.4

28 сен 07, 00:06    [4727535]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

softwarer пишет:

> Насколько я понимаю, вложенные транзакции в MSSQL в значительной степени
> аргументируются именно этой возможностью.

В смысле, чтобы дать выполнится процедуре на любом нужном ей уровне транзакций ?
Тогда нет, вложенные транзакции могут и без процедур использоваться.

Posted via ActualForum NNTP Server 1.4

28 сен 07, 00:09    [4727541]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67504
Блог
MasterZiv
Это только кажется, что нонсенс.



MasterZiv
На самом деле в некоторых СУБД уровень изоляции можно менять даже для отдельной таблицы конкретного запроса.

Да. Я не стал об этом упоминать, дабы меня не заподозрили в желании поднять флейм о конкретных некоторых СУБД, но это безусловно пик бессмысленности. Можно помедитировать, например, над смыслом запроса, который дважды обращается к одной таблице с разными уровнями изоляции при этом.

Впрочем, это бред в любом случае, поскольку означает запрос на получение заведомо рассинхронизованных данных.

MasterZiv
И в общем-то оно понятно, поскольку уровень изоляции в конце концов лишь сила блокировок, накладываемых на обрабатываемые данные.

:) Чтобы оценить смысл какого-то действия, нужно отвлечься от физики его реализации. Например, "в конце концов любые данные есть последовательность битов", но из этого никак не следует осмысленность присваивания переменной "остаток средств на счету" значения "устав караульной службы Российской армии".

Так и здесь: из того, что нечто можно сделать (в частности, выполнить такой бардачный запрос) совершенно не следует, что это нужно делать.
28 сен 07, 01:18    [4727654]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 teras
Интересно, на чьи определения вы ссылаетесь? И не могли бы привести соответствующее определение вложенной транзакции? Хотя, если вам не нравится упоминание блокировок, можно написать более общо: вложенная транзакция полностью соблюдает свойство изоляции, без исключений - ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой, включая и родительскую.

Это, простите, какая-то чушь.
Вы, похоже, непонимаете, что изоляция - это защита (требуемого уровня) исполняемой транзакции от изменений во внешнем мире, а вовсе не защита внешнего мира от изменений в транзакции.
Фраза "ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой" в корне не верна. Запустите рядом транзакцию в Dirty Read - и ей будут видны еще незакомиченные изменения. Запустите рядом транзакцию в Serializable - и ей не будут видны даже и закомиченные.

Вот, что пишет по этому поводу wikipedia: Changes made by the nested transaction are not seen by the 'host' transaction until the nested transaction is committed.
Или здесь: A parent transaction's actions are considered to conflict with its child's actions but not vice versa. Thus, it cannot access a resource if a child's lock prohibits the access. Thus, the child's lock wins.

Что я могу ответить... Не читайте википедию.
По поводу того, что родительская транзакция в принципе не может смотреть на изменения дочерней - SergSuper уже написал. Только дочерняя может пытаться смотреть на изменения родительской. А раз уж "child's lock wins", то и вообще не нужны никакие блокировки между родительской и дочерней (ну либо в дэдлок войдём на ровном месте).

Очень просто - не все СУБД используют неявное задание транзакции - это когда транзакция связана с потоком, соединением и приложение не может выбирать с какой транзакцией работать в данный момент. Некоторые дают возможность явно выбрать транзакцию при исполнении.

Что это???
Все слова понятны, но общий смысл фразы мне недоступен.

Знаете, я как-то администрировал достаточно крупное приложение на oracle 7.3. ... Так вот - в нем каждая процедура была представлена в двух ипостасях - some_proc и some_proc_nc. Где some_proc, очевидно, вызывала some_proc_nc и commit. ... можно было бы сделать тоже самое, но проще - по крайней мере исчезла бы необходимость иметь коммитящую версию.

Сделать проще можно было бы - именно через полноценные вложенные транзакции. Процедура имеет вначале Begin Trans, в конце Commit Trans (или Rollback, по ситуации), вызывай её откуда хочешь, и никакого геморроя со счетчиками невнятными. В аксесе я именно так и поступал, горя не знал.
Но Вы то говорили про майкрософтовскую реализацию, которая к вложенным транзакциям не имеет никакого отношения, и работу со вложенными Begin/Commit/Rollback ничуть не упрощает, а только усложняет. Т.е. можно в начале процедуры проверять счетчик, и в зависимости от его значения либо сейвпоинт ставить, либо транзакцию открывать, при успешном завершении процедуры либо ничего не делать (если был сейвпоинт), либо коммитить транзакцию (если была транзакция), а при неуспешном завершении либо откатывать до сейвпоинта (если он был), либо откатывать транзакцию. Но это - увеличение геморроя, а вовсе не его уменьшение.

-------------------------------

2 softwarer
Еще раз. Для меня нонсенс - вообще желание менять уровни внутри одной транзакции, независимо от того, в какую сторону.

А для Вас вообще желание менять уровни изоляции (не внутри еще какой-нибудь, а просто так) - не является ли нонсенсом?
Ну т.е. открыли соединение, запустили пачку каких-нибудь одиночных (нетранзакционных) select/insert/update/delete, на каком уровне изоляции - хз, на каком-то умолчальном, потом начали транзакцию с уровнем изоляции А, что-то там сделали, закоммитились, начали транзакцию с уровнем изоляции B, что-то там сделали, закоммитились, начали транзакцию с уровнем изоляции C, что-то сделали, закоммитились...
Эта последовательность действий - нонсенс (для Вас), или нет?
Если нет, то почему та же самая последовательность действий превращается в нонсенс как только её оборачиваем в транзакцию?
Если да, то выходит, что по хорошему надо вообще запретить менять уровень изоляции. Как один какой-то уровень изоляции выставили, так с ним и работают. Причем все. Выставили всем сериалайзбл, и все довольны :).
28 сен 07, 07:43    [4727994]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
По поводу того, что родительская транзакция в принципе не может смотреть на незакомиченные изменения дочерней - SergSuper уже написал. Только дочерняя может пытаться смотреть на незакомиченные изменения родительской.

так корректнее.
28 сен 07, 07:46    [4728000]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Пьяный Лох
Gluk (Kazan)
То чего хотите есть у нас. Только называется по другому - автономная транзакция.

Это разные вещи.


почему ?
28 сен 07, 08:30    [4728050]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Gluk (Kazan)
Пьяный Лох
Gluk (Kazan)
То чего хотите есть у нас. Только называется по другому - автономная транзакция.

Это разные вещи.


почему ?

По поведению.
Rollback внешней транзакции не откатит автономную, если я правильно понимаю.
В случае же вложенных - rollback внейшней откатит и себя, и вложенную транзакцию.
28 сен 07, 08:54    [4728094]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
teras
Gluk (Kazan)
Это абстрактные рассуждения или вы где то (не в MS SQL) ИСПОЛЬЗУЕТЕ вложенные транзакции ?
И то и другое. Собственно, вопрос ведь вначале прозвучал абстрактно, так и отвечал. Сама модель - следствие чтения описаний алгоритмов, таких, как ARIES/NT и т.п. Что касается практики, то такой подход точно реализован в BDB, и, кроме, того встречался в документации на другие продукты.


вот тут не нашел каких-то феноменальных отличий от автономных транзакций

teras

MasterZiv
В определении моделей транзакций про блокировки ничего нет, потому как это уже реализация, а не модель.
Интересно, на чьи определения вы ссылаетесь? И не могли бы привести соответствующее определение вложенной транзакции? Хотя, если вам не нравится упоминание блокировок, можно написать более общо: вложенная транзакция полностью соблюдает свойство изоляции, без исключений - ни одно изменение, выполненное вложенной транзакцией не видно до ее завершения ни в какой другой, включая и родительскую.


Блокировки это один из механизмов обеспечения изоляции транзакций. Для версионников это особенно очевидно :)
28 сен 07, 09:23    [4728178]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Пьяный Лох
Gluk (Kazan)
Пьяный Лох
Gluk (Kazan)
То чего хотите есть у нас. Только называется по другому - автономная транзакция.

Это разные вещи.


почему ?

По поведению.
Rollback внешней транзакции не откатит автономную, если я правильно понимаю.
В случае же вложенных - rollback внейшней откатит и себя, и вложенную транзакцию.


Нет, родительская транзакция ждет завершения автономной и откатить ее не может по оппределению. Какие то тонкие различия могут быть в изоляции между родительской и вложенной, но по описанию BDB пока не уловил
28 сен 07, 09:37    [4728237]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Dimitry Sibiryakov
Member

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

Gluk (Kazan)
Для версионников это особенно очевидно :)

Вот только само существование версионников не для всех очевидно. Что
особенно неприятно, комитет по стандартам тоже в их числе. Отсюда в их
стандарте определение уровней изоляции через блокировки и феномены.

Posted via ActualForum NNTP Server 1.4

28 сен 07, 09:37    [4728239]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Пьяный Лох
Gluk (Kazan)
Пьяный Лох
Gluk (Kazan)
То чего хотите есть у нас. Только называется по другому - автономная транзакция.

Это разные вещи.


почему ?

По поведению.
Rollback внешней транзакции не откатит автономную, если я правильно понимаю.
В случае же вложенных - rollback внейшней откатит и себя, и вложенную транзакцию.


Sorry, теперь включился
На мой взгляд будет каша если реализовывать вложенные транзакции именно в такой форме.
28 сен 07, 09:39    [4728250]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Dimitry Sibiryakov

Gluk (Kazan)
Для версионников это особенно очевидно :)

Вот только само существование версионников не для всех очевидно. Что
особенно неприятно, комитет по стандартам тоже в их числе. Отсюда в их
стандарте определение уровней изоляции через блокировки и феномены.
Posted via ActualForum NNTP Server 1.4


Этим старым перичникам вообще мало что очевидно :(
Но Microsoft к примеры уже проголосовал за версионность, так что процесс идет
28 сен 07, 09:41    [4728265]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Gluk (Kazan)
Sorry, теперь включился
На мой взгляд будет каша если реализовывать вложенные транзакции именно в такой форме.

Пардон, в чём каша то?
Begin Transaction
-- что то делаем
Rollback Transaction
Rollback откатывает всё, что было сделано между Begin и Rollback, и ничего больше не трогает.
Имхо - абсолютно логичное поведение было бы, если бы оно было таким.
Почему такая конструкция не должна откатить что-то внутри - не понимаю.
Почему такая конструкция должна откатывать что-то снаружи - не понимаю тем более.

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

Хотя ИМХО было бы более правильно оформлять эту "маленькую зелёненькую пирамидку" именно как отдельную самую обычную транзакцию, просто со необычным уровнем изоляции - "изолирована от всего, за исключением одной отдельно взятой рядом исполняющейся транзакции".
28 сен 07, 09:59    [4728366]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
то что "маленькие зеленые пирамидки" нужны вопросов не вызывает (их активно использует сам Oracle). Необходимость же (и главное корректность) использования вложенных транзакций, для меня не очевидна
28 сен 07, 10:26    [4728536]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 Gluk (Kazan)
то что "маленькие зеленые пирамидки" нужны вопросов не вызывает

Не вызывает.
То, что нужно уметь исполнять две независимые транзакции - вопросов не вызывает. То, что одной транзакции иногда нужно уметь влезть в незакомиченные данные другой - тоже вопросов не вызывает.
Я как бы ни с чем и не спорю.
Просто если "маленькая зелёненькая пирамидка" по факту является независимой транзакцией со специфичным уровнем изоляции - то я бы предпочёл называть её именно независимой транзакцией со специфичным уровнем изоляции. Если её называют по другому - ничего страшного, главное не запутаться.
Если она по факту является чем-то другим - ну значит мои рассуждения на тему "как бы это покрасивше назвать" можно выкинуть в помойку, я не обижусь.

Необходимость же (и главное корректность) использования вложенных транзакций, для меня не очевидна

Необходимость "частичного" отката для Вас вопросов не вызывает? Надеюсь, что нет. Если да, то можно порассуждать на тему "зачем нужны сейвпоинты", но лучше не будем.
Необходимость "условного" коммита для Вас вопросов не вызывает? Ну т.е. для бОльшей реюзабельности кода хочется, чтобы Commit фиксировал изменения либо для всего мира (если это outermost транзакция), либо только для родителя (если куда-то вложились), а для всего остального мира эти изменения еще не закомиченны.

Если объединить "частичный" откат с "условным" коммитом - получится вполне съедобная вложенная транзакция.
Но у MS (в MS SQL Server) половина функционала (а именно условный коммит) - оставлена на Commit'е, а вторая половина (а именно частичный ролбек) - перекочевала в сейвпойнты.
В итоге получилась полная херня.

Самое непонятное, что эти же люди сделали Access, где "условный" Commit вполне нормально сосуществует с "частичным" Rollback.
(предлагаю воздержаться от оффтопа на тему Вашего неверия в существование транзакций в аксесе )
28 сен 07, 10:41    [4728624]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Пьяный Лох

То, что нужно уметь исполнять две независимые транзакции - вопросов не вызывает.


Вот это вызывает вопросы. И в Oracle этого нет
28 сен 07, 10:49    [4728671]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Gluk (Kazan)
Пьяный Лох

То, что нужно уметь исполнять две независимые транзакции - вопросов не вызывает.


Вот это вызывает вопросы. И в Oracle этого нет

Как это? Оракл не умеет две транзации исполнить? Скажите, что Вы пошутили :)
28 сен 07, 10:54    [4728696]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Пьяный Лох
Необходимость "условного" коммита для Вас вопросов не вызывает? Ну т.е. для бОльшей реюзабельности кода хочется, чтобы Commit фиксировал изменения либо для всего мира (если это outermost транзакция), либо только для родителя (если куда-то вложились), а для всего остального мира эти изменения еще не закомиченны.


Вызывает. Очень сильно вызывает :(
В Oracle 10g тоже наплодили всяких commit-ов которые не совсем commit-ы или совсем commit-ы, но только по субботам Лично меня это сильно печалит.

commit должен быть commit-ом для всех. И по субботам и по пятницам и даже по средам. Независимо от всех благих намерений коими руководствовались разработчики проектируя новую мегасуперфичу
28 сен 07, 10:54    [4728697]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Пьяный Лох
Gluk (Kazan)
Пьяный Лох

То, что нужно уметь исполнять две независимые транзакции - вопросов не вызывает.


Вот это вызывает вопросы. И в Oracle этого нет

Как это? Оракл не умеет две транзации исполнить? Скажите, что Вы пошутили :)


не то процитировал :(

Пьяный Лох
То, что одной транзакции иногда нужно уметь влезть в незакомиченные данные другой - тоже вопросов не вызывает.


вот это ВЫЗЫВАЕТ вопросы
28 сен 07, 10:55    [4728711]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 Gluk (Kazan)
Пьяный Лох
Необходимость "условного" коммита для Вас вопросов не вызывает? Ну т.е. для бОльшей реюзабельности кода хочется, чтобы Commit фиксировал изменения либо для всего мира (если это outermost транзакция), либо только для родителя (если куда-то вложились), а для всего остального мира эти изменения еще не закомиченны.


Вызывает. Очень сильно вызывает :(

А почему?
Вам так сильно хочется писать код в стиле упомянутого на прошлой странице, т.е.
Create Procedure SomeProc_nc
As
    Select ...
    Insert ...
    Update ...
    Delete ...

Create Procedure SomeProc
As
    Begin Transaction
    Exec SomeProc_nc
    Commit Transaction

Мне лично такое вовсе не нужно. Писать больше, думать потом еще, где какую вызвать... Ну его в пень.
Программист - животное ленивое.
Я вполне буду доволен, если смогу один раз написать
Create Procedure SomeProc
As
    Begin Transaction
        Select ...
        Insert ...
        Update ...
        Delete ...
    Commit Transaction
и использовать эту процедурину там, где мне она нужна, а уж об уровнях вложенности пусть сервер думает, у него голова большой.
Собственно, в MS SQL Server я именно так и могу сделать. Я не могу безбоязненно в эту процедурину Rollback запихнуть :)

не то процитировал :(

Пьяный Лох
То, что одной транзакции иногда нужно уметь влезть в незакомиченные данные другой - тоже вопросов не вызывает.


вот это ВЫЗЫВАЕТ вопросы

Но ведь автономная транзакция имеет доступ к измененным, но, разумеется, еще незакомеченным данным "родительской"? Или я не прав?
28 сен 07, 11:05    [4728787]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Gluk (Kazan)
commit должен быть commit-ом для всех. И по субботам и по пятницам и даже по средам. Независимо от всех благих намерений коими руководствовались разработчики проектируя новую мегасуперфичу

ну а допустим надо какое-то действие откатить, но записать об этом в лог
для лога должен быть commit, для основного действия rollback

мне например не нравится что в MS SQL такое не сделать стандартными средствами
28 сен 07, 11:05    [4728791]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
SergSuper
Gluk (Kazan)
commit должен быть commit-ом для всех. И по субботам и по пятницам и даже по средам. Независимо от всех благих намерений коими руководствовались разработчики проектируя новую мегасуперфичу

ну а допустим надо какое-то действие откатить, но записать об этом в лог
для лога должен быть commit, для основного действия rollback


Для того и были созданы автономные транзакции. Но автономная транзакция - независима от основной и полностью изолирована. Это просто способ выполнить какие-то транзакционные действия ЗА ПРЕДЕЛАМИ основной транзакции
28 сен 07, 11:11    [4728844]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

softwarer пишет:

> Впрочем, это бред в любом случае, поскольку означает запрос на получение
> заведомо рассинхронизованных данных.

Это не бред. Ты просто воинствующий идеалист. Транзакция - это абстракция,
и ее нельзя ограничивать какими-то соображениями, кроме базовых свойств,
потому что нельзя предсказать логику конкретного приложения - она может
быть любой. Любая возможность может быть востребована приложением.

Тебя напр. не смущает, что управляя транзакцией вручную (multi-statement)
можно даже целостность транзакции нарушать ? Ну и что, целостность -
тоже абстракция, она с точки зрения конкретного приложения может
быть совершенно другой.

> :) Чтобы оценить смысл какого-то действия, нужно отвлечься от физики его
> реализации. Например, "в конце концов любые данные есть

Получишь скорость сферического коня в вакууме. Оно интересно,
но только с чисто теоретической стороны.

> Так и здесь: из того, что нечто можно сделать (в частности, выполнить
> такой бардачный запрос) совершенно не следует, что это нужно делать.

Тебе не нужно. Но ты - не все приложения на свете.

Posted via ActualForum NNTP Server 1.4

28 сен 07, 11:12    [4728863]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
SergSuper
мне например не нравится что в MS SQL такое не сделать стандартными средствами


Это можно и стандартными средствами, если вспомнить, что табличные переменные не подвержены действию откатов транзакций.
28 сен 07, 11:15    [4728882]     Ответить | Цитировать Сообщить модератору
 Re: nested transaction vs savepoint  [new]
Gluk (Kazan)
Member

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

Тебя напр. не смущает, что управляя транзакцией вручную (multi-statement)
можно даже целостность транзакции нарушать ? Ну и что, целостность -
тоже абстракция, она с точки зрения конкретного приложения может
быть совершенно другой.


Целостность не нарушается ни на уровне операторов ни на уровне транзакции. Пока мы выполняем какие-то действия в транзакции, все наши действия - часть транзакции. Мы не можем нарушить ее целостность, мы можем только выполнить другую транзакцию. Сервер не обязан знать какой смысл вкладывает в выполняемые действия приложения
28 сен 07, 11:27    [4728975]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить