Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12   вперед  Ctrl      все
 Re: MySQL и Firebird для Web  [new]
Yo.!
Guest
kdv

блин, записался. Имел в виду что поведение Оракла относительно оператора в RC эквивалентно снапшоту в ФБ потому что в начале оператора Оракл как раз как бы стартует микро-снапшот-транзакцию на время работы оператора.

ну хоть что-то FB умеет делать как все

kdv

я посмотрел статью только в части update и delete, и вижу тут только одно отличие ФБ от Оракла

смеялсо.
6 авг 10, 18:50    [9226497]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
Yo.!
artemana

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

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

Это будут твои, как прикладного программиста, косяки. Сам сделал, сам и разбирайся.
То есть в данном случае мне не нужна защита для дураков, ограничивающая мои возможности.
Подавляющее большинство языков программирования разрешает
а. вызов проц.A из A.
б.Перекрестный вызов проц.B из A и A из B.
Умеешь и считаешь возможным - пользуйся, не умеешь - учись или меняй профессию.
6 авг 10, 18:55    [9226526]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
Yo.!
Guest
artemana

Это будут твои, как прикладного программиста, косяки. Сам сделал, сам и разбирайся.

ясно, этот безнадежный.
6 авг 10, 19:04    [9226577]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
Yo!
смеялсо.

да, я тоже поржал. там Оракл столько телодвижений производит, явно видно тяжелое наследие прошлого.
6 авг 10, 19:09    [9226605]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
Yo.!, твой слив принят.
6 авг 10, 19:09    [9226606]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
Dimitry Sibiryakov
Member

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

Yo.!
ясно, этот безнадежный.

Так и запишем: Oracle - сервер для криворуких домохозяек, которые научились
программировать за курсах за 21 день, а про отладку и тестирование ничего не слышали.

Posted via ActualForum NNTP Server 1.4

6 авг 10, 19:17    [9226649]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
Yo.!
Guest
хи-хи, и как же Yo! переживет такой позор
kdv, скажи честно, ты как и наш молодняк считаешь, что отладив на определенном наборе данных тригера на этом же наборе и этих же тригерах сюрпризов не получить ?
6 авг 10, 19:26    [9226687]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
Yo.!
хи-хи, и как же Yo! переживет такой позор
kdv, скажи честно, ты как и наш молодняк считаешь, что отладив на определенном наборе данных тригера на этом же наборе и этих же тригерах сюрпризов не получить ?

Конечно. Если записи, отрабатываемые (вставляемые, удаляемые) триггерами, имеют такие значения полей, которые делают их недоступными для внешней команды. Соблюдай это правило и никаких сюрпризов не будет. Ты же настаиваешь на ликвидации возможности как таковой.

Повторю, напортачить в программирование можно с помошью всего. Если это 'всего' запретить, то программирования исчезнет. Нужен взвешенный подход, и в данном случае оракловский запрет не оправдан.
P.S.
Не позорь свою седую ...., не переходи на личности.
6 авг 10, 19:43    [9226775]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
Dimitry Sibiryakov
Member

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

Yo.!
и как же Yo! переживет такой позор

Так же как и раньше: продолжишь долдонить "FoxPro - лучшая СУБД всех времён и
народов
а у вас лога нет".

Posted via ActualForum NNTP Server 1.4

6 авг 10, 19:51    [9226819]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
Yo!
kdv, скажи честно, ты как и наш молодняк считаешь, что отладив на определенном наборе данных тригера на этом же наборе и этих же тригерах сюрпризов не получить ?

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

Вообще я бы разделял нестабильность курсоров, триггеры, и т.п. Причем даже нестабильность курсоров в отношении insert into select, просто select, и update/delete я бы разделил. Потому что на практике на нестабильность select в RC в ФБ людям покласть. Они ее не замечают, а если и замечают, она их не интересует.

Больше пострадавших от update/delete ... where select from, если иметь в виду одну и ту же таблицу.
Да, тут увы и ах.

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

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

Но можно и закопаться в ад. Кто-то меня в начале 2000 годов спрашивал про видимость изменений в нескольких before-триггерах которые еще и модифицируют эту же таблицу, и т.п. К сожалению подробностей не помню, а мой мозг самостоятельно такой ужас придумывать отказывается.
6 авг 10, 20:50    [9227076]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
Gluk (Kazan)
Member

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

Вообще я бы разделял нестабильность курсоров, триггеры, и т.п. Причем даже нестабильность курсоров в отношении insert into select, просто select, и update/delete я бы разделил. Потому что на практике на нестабильность select в RC в ФБ людям покласть. Они ее не замечают, а если и замечают, она их не интересует.


А я бы не стал отделять. Потому что все их можно поршать одним средством, не придумывая костыли на каждый отдельный случай. Но это IMHO, разумеется.

kdv

Больше пострадавших от update/delete ... where select from, если иметь в виду одну и ту же таблицу.
Да, тут увы и ах.


Ага. Увы ... и Ах
и может быть еще Ой

kdv

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


Теперь можно считать доказанным, что органы слуха у тараканов расположены на лапках (c)

kdv

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


Три года безупречной работы бомбы замедленного действия, это безусловно очень грамотно, завидую.
Что Вы там говорили, про то что Ваши решения не нужно отлаживать ???
6 авг 10, 22:08    [9227272]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
Gluk
Потому что все их можно поршать одним средством, не придумывая костыли на каждый отдельный случай. Но это IMHO, разумеется.

о каких костылях идет речь я не понял. Потому что со стороны-то порешать можно легко. Но в наших дискуссиях я уже объяснял, что решить проблему нестабильности курсора, а именно
insert into select from
update/delete from select
неатомарность select

можно введением в ФБ старта snapshot-транзакций в момент старта DML оператора, как это и видно в приведенной статье про микро-откаты. Но только вот стоимость старта снапшотов, как я считаю, достаточно высока в ФБ, т.к. при этом сервер делает локальную копию transaction inventory page.
В Оракле наоборот, для этого идет постоянная "долботня" с блокировками, перечитыванием данных и прочими ужасами.
Так что, на тему возможности и стоимости такого решения могут ответить только разработчики Firebird. И если до сих пор это не было сделано, то значит, не так-то уж это легко.

Gluk
Теперь можно считать доказанным, что органы слуха у тараканов расположены на лапках (c)

все это мудотня, ибо является бессмысленной фразой. Поконкретнее выражайтесь, пожалуйста. Риторики в этом топике и так достаточно.

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

никакой бомбы нет. Откуда Вы взяли бомбу? Как Вы вообще можете предположить, что в той логике какую я реализовал, есть бомба, которая сработает хер знает когда? Это Ваши сугубые домыслы, основания под которыми я не вижу, совершенно.

То есть, вот этот какой то бредовый наезд, что из триггера на таблицу эту же таблицу ну никак нельзя модифицировать, я считаю порождением факта о мутирующих таблицах в Оракле, и ничем иным. Для Вас, похоже, авторитет Оракла настолько непререкаем, что Вы даже и усомниться в его функционировании не можете.
Помню, была совершенно идиотская битва с MS SQL-цами, на тему, зачем нужно вообще в одном коннекте стартовать несколько транзакций одновременно, и боже сохрани, иметь в одной транзакции несколько открытых курсоров с возможностью поочередного фетча.
Это просто не укладывалось в их мозгу, потому что этого НЕТ в MS SQL, а значит и НЕ ДОЛЖНО быть ни в какой другой СУБД.
Вы аналогичные мысли пытаетесь проталкивать?

С таким же успехом можно было сказать, что текущую функциональность Firebird благословил Господь, и все кто усомнились в ее праведности, есть еретики. Но этого же нет. С вами пытаются вести дискуссию разработчики Firebird, которые, уверяю, имеют опыт работы как с Ораклом так и с MS SQL, и внимательно изучают в т.ч. и их тонкости функционирования.
Впечатление такое, что Вы находитесь в какой-то иной плоскости, которая сродни религиозному фанатизму. Прошу Вас, разуверьте меня, скажите, что Вам в Oracle нравится не все.
Мне вот, в ФБ действительно нравится не все.
7 авг 10, 00:23    [9227743]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
Yo.!
Guest
kdv

Вообще я бы разделял нестабильность курсоров, триггеры, и т.п.

это радует, хоть кто из вашей веселой братии еще различает теплое и мягкое

kdv

Потому что на практике на нестабильность select в RC в ФБ людям покласть. Они ее не замечают, а если и замечают, она их не интересует.

а это я бы назвал национальной чертой ФБ-лабателей

kdv

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

мда, представляю сколько говнокода налабано этой братией. ладно, пробую разжувать: уход в бесконечный цикл это просто один из побочных фифектов, причем самый дружественный, т.к. его не возможно не заметить. основная проблема мутирующих таблиц в декларативной природе SQL. модифицирующий запрос не может гарантировать порядок попадание строк в триггер, соответственно если тригер обращается к мутирующей таблице он не сможет гарантировать того что в следующий раз этот же запрос отошлет в тригер строки в этом же порядке. вот это страшно: до обеда простенький DML дергал тригер так, а после обеда оптимайзер нашел более оптимальный план и тригер теперь на ТОТ ЖЕ DML выдаст другие результаты.
7 авг 10, 00:41    [9227791]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
Yo.!
а это я бы назвал национальной чертой ФБ-лабателей

Пациенты с лоботомускультомией исчезли из топика.
7 авг 10, 01:47    [9227949]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
eBase
Member

Откуда: Ukraine, Kharkiv
Сообщений: 142
Gluk (Kazan)
Три года безупречной работы бомбы замедленного действия, это безусловно очень грамотно, завидую.
Вы приобрели себе хрустальный шар и видите у кого как построена база и когда она рухнет? :) Ваши домыслы полная фигня ибо спорите сами не понимаете о чем, какой-то штатный програмистик учит разработчиков СУБД как правильно нужно жить, ну-ну...
7 авг 10, 09:21    [9228210]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
Yo.!
мда, представляю сколько говнокода налабано этой братией. ладно, пробую разжувать: уход в бесконечный цикл это просто один из побочных фифектов, причем самый дружественный, т.к. его не возможно не заметить. основная проблема мутирующих таблиц в декларативной природе SQL. модифицирующий запрос не может гарантировать порядок попадание строк в триггер,

Но множество строк, подвергающихся операции (попадающих в тригер), определяется однозначно. И этого достаточно (управление порядком не нужно) для избежание любых проблем мутации. Это понятно?
7 авг 10, 12:46    [9228437]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
Yo.!
а это я бы назвал национальной чертой ФБ-лабателей

я уже объяснял свою позицию на тему нестабильности select в readcommitted в ФБ.
https://www.sql.ru/forum/actualthread.aspx?bid=2&tid=173455&pg=1#1449214
(и далее, со следующей страницы, там много на эту тему, кстати, как раз 2005 год)
только я там "стабильность курсора" называю "атомарностью select".

Вот еще оттуда же, зачем обычно используют RC
https://www.sql.ru/forum/actualthread.aspx?bid=2&tid=173455&pg=3#1460836

Yo!
мда, представляю сколько говнокода налабано этой братией.

да Вы идеалист. Можно подумать, что на Оракле говнокод не пишут. Еще как, не сомневайтесь, я абсолютно уверен в этом. Причастность к Ораклу не дает каких-то особенных мозговых преимуществ.
Но уровень вхождения в ФБ - да, ниже, и это тоже нормально. То есть, я полагаю, что Оракл был бы не против мирового господства, но к счастью, не получится.

Yo!
модифицирующий запрос не может гарантировать порядок попадание строк в триггер, соответственно если тригер обращается к мутирующей таблице он не сможет гарантировать того что в следующий раз этот же запрос отошлет в тригер строки в этом же порядке.

какой еще в дуду "порядок"... может, в оракле привыкли пользоваться rownum, я не знаю, но у людей, использующих FB, привычки к "порядку строк" нет, потому что в SQL тоже порядок строк не гарантируется (кроме сортировок order by).
7 авг 10, 13:33    [9228483]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
kdv

Yo!
модифицирующий запрос не может гарантировать порядок попадание строк в триггер, соответственно если тригер обращается к мутирующей таблице он не сможет гарантировать того что в следующий раз этот же запрос отошлет в тригер строки в этом же порядке.

какой еще в дуду "порядок"... может, в оракле привыкли пользоваться rownum, я не знаю, но у людей, использующих FB, привычки к "порядку строк" нет, потому что в SQL тоже порядок строк не гарантируется (кроме сортировок order by).

Он утверждает, что раз в командах update и delete нет order by, значит проблемы, вызваные мутацией, неизбежны. Такой вот он ошибочный логический вывод сделал.
7 авг 10, 14:30    [9228582]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
Dimitry Sibiryakov
Member

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

artemana
проблемы, вызваные мутацией, неизбежны.

Единственная проблема, вызываемая мутацией, это невозможность обратиться к таблицам из
триггеров. И никакие order by эту проблему обойти не помогут.

Posted via ActualForum NNTP Server 1.4

7 авг 10, 15:51    [9228731]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
eBase
Gluk (Kazan)
Три года безупречной работы бомбы замедленного действия, это безусловно очень грамотно, завидую.
Вы приобрели себе хрустальный шар и видите у кого как построена база и когда она рухнет? :) Ваши домыслы полная фигня ибо спорите сами не понимаете о чем, какой-то штатный програмистик учит разработчиков СУБД как правильно нужно жить, ну-ну...


Ой как все всполошились :)
Видаь\ть чего-то живое зачепил, даром что штатный программистик
8 авг 10, 21:19    [9231179]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
Gluk (Kazan)
Member

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

artemana
проблемы, вызваные мутацией, неизбежны.

Единственная проблема, вызываемая мутацией, это невозможность обратиться к таблицам из
триггеров. И никакие order by эту проблему обойти не помогут.


Ой, да ну бросьте. Можно к ним обращаться. И писать можно (геморойно правда).
Вот намедни заказчик осчастливил.

1. Имеется таблица, все действия с которой, записывают копию строки в таблицу журнал
2. Записи собираются из основной таблицы и журнальной по union all
3. Выясняется, что записи в журнале тоже можно редактировать (такой вот хитрый заказчик)
4. Куда бы вы думали журналируются изменения журнальных записей ???

Правильно, в ту же журнальную таблицу. Что вы, серьезно думаете, что мутация кого-то остановила ???
8 авг 10, 21:26    [9231198]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
Gluk (Kazan)
Member

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

какой еще в дуду "порядок"... может, в оракле привыкли пользоваться rownum, я не знаю, но у людей, использующих FB, привычки к "порядку строк" нет, потому что в SQL тоже порядок строк не гарантируется (кроме сортировок order by).


Дык тебе и говорят про order by, чудак (в update-е правда )
какой к чертям свинячим rownum? Это у Вас такие фантазии про ораклистов??? Ну ну, проецируйте дальше
8 авг 10, 21:30    [9231206]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
Gluk (Kazan)
Member

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

Gluk
Теперь можно считать доказанным, что органы слуха у тараканов расположены на лапках (c)

все это мудотня, ибо является бессмысленной фразой. Поконкретнее выражайтесь, пожалуйста. Риторики в этом топике и так достаточно.


Мне вот интересно :) Я вроде тут по матушке (еще пока) никого не называл, вел себя тихо блаародно, а мне в ответ мудотня да буи разныя. Или только пролетариям дозволяется выражаться в рфср-е ???
Довольно обидные Ваши слова, Коллега.

Что-же до конкретики, то в посте:

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


я ее тоже не нашел
Да были демоны ... напарывались на рекурсию в триггерах, но после того как Старшие Товарищи объясняли им Политику Партии, они самоликвидировались и больше не появлялись.
Наверное, потому, что у них ВСЕ хорошо, ага ... я тоже на это надеюсь
8 авг 10, 21:38    [9231229]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
kdv
Gluk
Потому что все их можно поршать одним средством, не придумывая костыли на каждый отдельный случай. Но это IMHO, разумеется.

о каких костылях идет речь я не понял. Потому что со стороны-то порешать можно легко. Но в наших дискуссиях я уже объяснял, что решить проблему нестабильности курсора, а именно
insert into select from
update/delete from select
неатомарность select

можно введением в ФБ старта snapshot-транзакций в момент старта DML оператора, как это и видно в приведенной статье про микро-откаты. Но только вот стоимость старта снапшотов, как я считаю, достаточно высока в ФБ, т.к. при этом сервер делает локальную копию transaction inventory page.


А по моему, все вы прекрасно поняли :)
Мне вот только из Вашего поста непонятно, можно решить, или именно таким образом и решили ??? Все таки стоимость высока, ага ...

kdv

В Оракле наоборот, для этого идет постоянная "долботня" с блокировками, перечитыванием данных и прочими ужасами.


А вот эти ужасы вообще непонятно откуда придуманы :(
Можете расшифровать на простом примере, где там долботня, перечитывания и блокировки (кстати в Oracle очень дешевые). Конкретно и предметно обсудим, так ли страшен чорт
8 авг 10, 21:44    [9231243]     Ответить | Цитировать Сообщить модератору
 Re: MySQL и Firebird для Web  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Думаю что тут порылась собака:

kdv

это же read committed (!), то есть он обязан видеть все, что успело стать committed.


В Oracle считают, что он обязан видеть все что закомичено к моменту начала запроса, и не должен видеть, того что появилось позже. Благо версионность это позволяет (дорого ли дешево - это другой вопрос). Ситуацию же когда видим не кратное 100 записям, в случае если комитим по 100 (я все правильно понял?) иначе как ахтунгом назвать вообще сложно Мы должны видеть изменения, выполненные транзакцией либо целиком, либо не видеть их вообще.
8 авг 10, 21:54    [9231286]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить