Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8   вперед  Ctrl      все
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Надежда юзера может быть оправдана ТОЛЬКО при помощи order by
16 мар 06, 11:59    [2454954]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
Yo.!!
Guest
gardenman
о план запроса постепенно меняться не может. Он всегда ведь пересматривается полностью.

где ? в оракле ?? не говорите чепухи. даже в db2 динамик sql из кеша берет план.

gardenman
Юзер надеется что в выборке все будет упорядочено по алфавиту.


с каждым постом вы меня удивляете все сильней, вы вообще вкурсе что SQL это декларативный язык ?
16 мар 06, 12:03    [2454993]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Gluk (Kazan)
Надежда юзера может быть оправдана ТОЛЬКО при помощи order by


Это ток у вашего MSSQL такая последняя единственная надежда. А у меня есть надежда еще и на Static SQL. И еще ни разу не подводила.
Если вдруг для этого ORDER BY ваш сервак сначала просканирует, отсортирует и отфильтрует всю таблицу - юзеры будут сильно недовольны производительностью. А у меня таких систуаций ВООБЩЕ не наблюдается.

Кстати тот же select max(id) from .. может выполняться по-разному. По тем же причинам. И я предпочитаю иметь в этих случаях стабильный план запроса и не полагаться на волю случая. Да что говорить - чем больше соединений в запросе, тем больше вариантов планов доступа. А собирать статистику, чтобы оптимизатор ее правильно интерпретировал - это большое искусство. Поэтому я предпочитаю знать что у меня в сервере происходит. DB2 дает мне эту возможность а другие СУБД - нет.

несмотря на то что SQL декларативный язык - нам далеко не безразлично каким способом данные вытаскиваются.

Вообще все так навалились на static sql - дескать нафиг он не нужен. будьте в конце концов честными - в MSSQL и Oracle хинтов гораздо больше чем в DB2. И все только для того, чтоб стабилизировать план запроса, чтобы знать что происходит в машине. Откажитесь от хинтов - и потом доказывайте что я не прав.
16 мар 06, 14:37    [2456049]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Не последняя, а единственная :)
остальное хак, хотя-бы потому как непереносимо
16 мар 06, 16:12    [2456562]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
Gluk (Kazan)
Не последняя, а единственная :)
остальное хак, хотя-бы потому как непереносимо

Имхо, проблема с order by появилась из-за merry-go-round scan, это оптимизация производительности скана таблицы несколькими процессами, так что первопричина здесь как раз повышение производительности :)
16 мар 06, 16:18    [2456596]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
Yo.!!
Guest
gardenman


Кстати тот же select max(id) from .. может выполняться по-разному. По тем же причинам. И я предпочитаю иметь в этих случаях стабильный план запроса и не полагаться на волю случая.


чем дальше в лес тем гуще партизаны ... теперь у нас план влияет на физическое расположение записей :)
16 мар 06, 16:19    [2456600]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
ggv
Member

Откуда:
Сообщений: 1810
дык эта, речь вроде о том, что у db2 есть и static sql, и dynamic sql
То есть есть выбор в данном случае.
А крик стоит - нам выбар не надааа!!!!!!!!!
Не нет, так нет, никто же вас не заставляет имплементить static sql.
16 мар 06, 18:06    [2457271]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
Yo.!!
Guest
ggv
дык эта, речь вроде о том, что у db2 есть и static sql, и dynamic sql
То есть есть выбор в данном случае.
А крик стоит - нам выбар не надааа!!!!!!!!!
Не нет, так нет, никто же вас не заставляет имплементить static sql.


такой выбор и в оракле есть, точнее был, выкинули такой выбор нафиг за ненадобностью. еще в девятке можно было включить rule optimizer который план не менял, но с появлением cost based всем стало ясно какой это sux. дальше любой нормальный ораклоид знает, что новичков нада бить за необоснованые хинты, бить и тыкать носом в документацию, там доходчего расписано в каких случаях следует использовать хинты и к каким последствиям это приводит (хинт нужен только если оптимизатор не справляется со своей задачей, чем выше версия оракла тем меньше ситуаций когда оптимизатор лажается).
если оптимизатор db2 лажается и не в кассу меняет оптимальные планы на неоптимальные это баг оптимизатора/собирателя статистики, а не фича static sql.

так всетаки вопрос: есть запрос оптимальный план которого зависит от @c1, какой план скомпилирует static sql не зная какие значения будут в реальных запросах ? первый попавшийся ? это фича ?
16 мар 06, 18:30    [2457370]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
Dooma
Guest
Yo.!!
такой выбор и в оракле есть, точнее был, выкинули такой выбор нафиг за ненадобностью. еще в девятке можно было включить rule optimizer который план не менял, но с появлением cost based всем стало ясно какой это sux. дальше любой нормальный ораклоид знает, что новичков нада бить за необоснованые хинты, бить и тыкать носом в документацию, там доходчего расписано в каких случаях следует использовать хинты и к каким последствиям это приводит (хинт нужен только если оптимизатор не справляется со своей задачей, чем выше версия оракла тем меньше ситуаций когда оптимизатор лажается)
Ну надо же...,
помнится в старых спорах вы гнули пальцы, и говорили как круто, что в Оракле хинтов больше, чем в MSSQL. На что вам отвечали, что в MSSQL и без хинтов лучше с планом справляется.
Или я ошибаюсь?
Или это были не вы?
Сейчас пороюсь в старых спорах...
16 мар 06, 18:58    [2457466]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
ggv
Member

Откуда:
Сообщений: 1810
Yo - ты как всегда великолепен в бредовом угаре.
смешались в кучу "rule optimizer", static sql, все это объявляется сосущим, и ни к чему негодным.
Ну тебе не надо - не используй.
Ну убогий твой оракл, всего ничего как на cost based optimizer перешел, совсем новая разработка, не отлаженная :)
Так тебя больше устраивает?
Ты же по-флеймить, а не узнать.
Дафай, толкай про консистентные отчеты, про эскалацию, бухти :)
Да, static sql не забудь записать как страшный баг у IBM :)
Я далек от мысли советовать тебе самому попробовать, знаю, все равно не попробуешь. Так шта дафай мы дружно заткнемся обсирать то, в чем некомпетентны, а?
16 мар 06, 21:22    [2457836]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Что-то у ggv сегодня весеннее обострение
:о))


--
Антон
Per rectum ad astrum
16 мар 06, 21:31    [2457852]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Как я понимаю, изначально в DB2 был Embedded SQL, а CLI (сильно смахивающий на ODBC; практически то же самое, но с дополнениями) появился позже (про JDBC и SQLJ я молчу).

Embedded SQL был и есть статический и динамический.
CLI всегда был динамический, а теперь его можно "превратить" в статический (причём программа и знать не будет). Утилита db2cap "Binds a capture file to generate one or more static packages. A capture file is generated during a static profiling session of a CLI/ODBC/JDBC application, and contains SQL statements that were captured during the application run. This utility processes the capture file so that it can be used by the CLI/ODBC/JDBC driver to execute static SQL for the application." Никогда не пользовался.

Теперь забудем про CLI и будем пользоваться только языком C как для прикладных программ, так и для хранимых процедур. (IBM утверждала, что это большое удобство, что вам не надо знать два процедурных языка. Вы можете делать SP на C, Cobol, Fortran, Java... В этом списке был REXX, но, увы, теперь SP на REXX не поддерживаются, а ведь, по моему нескромному мнению, в удобствах (хотя не в производительности) REXX давал SQL PL сто очков вперёд).

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

Динамический пример:
  
  strcpy(print, "SELECT * FROM building");
  EXEC SQL PREPARE printBuilding FROM :print;
  EXEC SQL DECLARE bldCursor CURSOR FOR printBuilding; 
  EXEC SQL OPEN bldCursor; 
  EXEC SQL FETCH bldCursor INTO :id, :address, :city, :floors, :employees;

Статический пример:
  EXEC SQL DECLARE c1 CURSOR FOR
    SELECT colname, typename, length, scale
      FROM syscat.columns
      WHERE tabschema = :schemaName AND tabname = :tableName;
  EXEC SQL OPEN c1;
  EXEC SQL FETCH c1 INTO :columnName, :dataType, :dataLength, :dataScale;

Далее, препроцессор для каждого SQC-файла генерируется два файла:
* один с расширением C
* второй с расширением BND

В BND-файлах лежит информация из EXEC SQL. Вы видите из примера выше, что известно выражение выборки в "статическом" примере, но неизвестно в "динамическом" - оно определяется в runtime. Эти файлы "привязывают" (биндят) к базе. В базе образуются пакеты. С пакетами связаны планы статических SQL, они тоже хранятся в базе. Первоначально, чтобы сменить эти планы (например, после большого изменения статистики), необходимо было пометить пакеты, как invalid. Планы возникали при привязке либо первом обращении к инвалидному пакету; значениями параметров DB2 не интересовалась.

Параметр BIND'а REOPT появился относительно недавно (вроде бы даже только в v8):
REOPT Specifies whether to have DB2 determine an access path at run time using values for host variables, parameter markers, and special registers. Valid values are:
* NONE The access path for a given SQL statement containing host variables, parameter markers, or special registers will not be optimized using real values. The default estimates for the these BIND variables is used, and the plan is cached and will be used subsequently. This is the default value.
* ONCE The access path for a given SQL statement will be optimized using the real values of the host variables, parameter markers, or special registers when the query is first executed. This plan is cached and used subsequently.
* ALWAYS The access path for a given SQL statement will always be compiled and reoptimized using the values of the host variables, parameter markers, or special registers that are known each time the query is executed.


Файл C дальше компилируется C-компилятором, объектные файлы линкуются. Получается executable или shared library/DLL, в зависимости от того, какого типа приложение. Пользователям это приложение поставляется со всеми сгенерированными BND-файлами.
17 мар 06, 00:10    [2458123]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
gardenman

Кстати тот же select max(id) from .. может выполняться по-разному. По тем же причинам. И я предпочитаю иметь в этих случаях стабильный план запроса и не полагаться на волю случая. Да что говорить - чем больше соединений в запросе, тем больше вариантов планов доступа. А собирать статистику, чтобы оптимизатор ее правильно интерпретировал - это большое искусство. Поэтому я предпочитаю знать что у меня в сервере происходит. DB2 дает мне эту возможность а другие СУБД - нет.

По-моему, это совершенно неправильно. Начну с того, Oracle действительно даёт возможность более-менее стабилизировать план при помощи хинтов и Stored Outlines. Тогда как если вы добьетесь в DB2 пусть стабильного благодаря static, но плохого плана, что вы будете делать - неужто статистикой играть?

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

Я помню высказывания типа "Если Oracle генерирует плохой план, используйте хинты. Если DB2 генерирует плохой план, обращайтесь в support IBM насчёт обнаружения ошибки в оптимизаторе".

Действительность несколько хуже, почему я с восторгом услышал про LEO. Но в принципе я обычно придерживаюсь примерно такого подхода: не моя забота рыться в планах.
17 мар 06, 00:25    [2458142]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
автор
Действительность несколько хуже, почему я с восторгом услышал про LEO. Но в принципе я обычно придерживаюсь примерно такого подхода: не моя забота рыться в планах.


Виктор, я ведь тебе уже говорил, что "желательный" план доступа закладывается уже на этапе проектирования базы данных. Конечно если проектировать так: накидаю-ка я табличек, понасабираю статистики, понаделаю запросов с десятком джойнов - все равно оптимайзер за меня всю работу сделает. Результат такого подхода - большая круглая ж...
Я ведь прекрасно знаю, что если где-то нужно быстро получать агрегаты - то это значит вы будете смотреть в сторону MQT. Если вы подразумеваете использование MQT - следовательно вы уже примерно знаете каким должен быть запрос и сколько времени он будет отрабатывать, а также каков тип MQT как он повлияет на вставку/удаление/изменение.

Короче говоря будьте честнее. Не наделяйте оптимизатор СУБД свойствами ИИ.
17 мар 06, 10:06    [2458666]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
Yo.!!
Guest
2Victor Metelitsa

а что будет если у db2 удалить индекс, он пометит все пакеты с планами как инвалидные (те планы которые использовали индекс) или запросы с такими планами будут вываливатся с ошибкой ?
17 мар 06, 10:19    [2458730]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Я уже писал об этом - смотри выше.
17 мар 06, 10:38    [2458838]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
gardenman
Виктор, я ведь тебе уже говорил, что "желательный" план доступа закладывается уже на этапе проектирования базы данных. Конечно если проектировать так: накидаю-ка я табличек, понасабираю статистики, понаделаю запросов с десятком джойнов - все равно оптимайзер за меня всю работу сделает. Результат такого подхода - большая круглая ж...
Вы идеалист, я смотрю. Впрочем, возможно, что так уж получилось, что ваши программы писались под статический круг задач. У меня сплошь и рядом примеры, когда клиенты приспосабливают мои программы для решения еще и своих задач, которые не предусматривались в оригинальной спецификации.

Вот пример: в банке таблица аккаунтов, у каждого аккаунта есть код продукта (кредитная карта, автомоб. заём, магазинный кредит и пр.) Ты проектируешь и залаживаешь индексный доступ по коду продукта (там, где надо выбрать только один продукт). Предполагаешь (а что тебе еще остаётся делать?), что распределение примерно одинаковое. А что в реальной жизни? Коньюктура рынка меняется, происходит перекос то в сторону одного продукта, то в сторону другого. В какой-то момент индексный доступ становится невыгодным для одного из продуктов - его много стало и кол-во i/o (index range scan + table probe) больше, чем при (full table scan). А что у тебя в программе творится со статическим планом, заложенным при проектировании - планомерное ухудшение производительности.

Извини, что всё так разжевал, но я хотел, что бы ты меня точно понял. Твоя неприязнь оптимизатора может объяснятся золотым наблюдением Виктора
Victor Metelitsa
Я помню высказывания типа "Если Oracle генерирует плохой план, используйте хинты. Если DB2 генерирует плохой план, обращайтесь в support IBM насчёт обнаружения ошибки в оптимизаторе".
То бишь понадеешься на него, а потом в один прекрасный момент он тебя как обломит, и звони потом в суппорт, жалуйся на судьбу свою несчасную :-[
17 мар 06, 18:13    [2461861]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
То бишь понадеешься на него, а потом в один прекрасный момент он тебя как обломит, и звони потом в суппорт, жалуйся на судьбу свою несчасную :-[
Или юзай опцию REOPT во время BIND :-)))
17 мар 06, 18:50    [2462003]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
gardenman
То бишь понадеешься на него, а потом в один прекрасный момент он тебя как 
обломит, и звони потом в суппорт, жалуйся на судьбу свою несчасную :-[
Или юзай опцию REOPT во время BIND :-)))

Ага, вижу, что немного изменил твоё отношение - значит день прожит не зря.
17 мар 06, 19:08    [2462062]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
gardenman
1) В DB2 многие вещи решаются всего лишь одним единственным запросом. В MSSQL вам придется писать для этого процедуру.


зы.. ничего личного

попробовал я как-то в ДБ2 в триггере узнать какое из блобных полей поменялось. Оказалось надо пять триггеров делать.

А в другой раз с таблицей в 34 блобных поля я понял айбэму есть куда еще расти
16 май 06, 01:44    [2667161]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Lepsik
gardenman
1) В DB2 многие вещи решаются всего лишь одним единственным запросом. В MSSQL вам придется писать для этого процедуру.


зы.. ничего личного

попробовал я как-то в ДБ2 в триггере узнать какое из блобных полей поменялось. Оказалось надо пять триггеров делать.

А в другой раз с таблицей в 34 блобных поля я понял айбэму есть куда еще расти

У все свои недостатки - вон у MSSQL2000 вообще с блобами никак работать нельзя - ни в триггерах, ни в хранимках ... только клиенту тупо отдать и взять и ничего же - SQL.RU крутится себе ;)
16 май 06, 06:13    [2667234]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
ChA
Member

Откуда: Москва
Сообщений: 11376
ASCRUS
у MSSQL2000 вообще с блобами никак работать нельзя - ни в триггерах, ни в хранимках
Вы не совсем правы. Нельзя объявлять переменные типа блобов - это да, но ничто не мешает работать с их содержимым, хранящимся в таблице. И, кстати, благодарить за такой подход надо Sybase.
ASCRUS
только клиенту тупо отдать и взять и ничего же - SQL.RU крутится себе
Сомневаюсь, что для хранения сообщений на SQL.RU используется блоб.
16 май 06, 13:29    [2669010]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
ChA
ASCRUS
у MSSQL2000 вообще с блобами никак работать нельзя - ни в триггерах, ни в хранимках
Вы не совсем правы. Нельзя объявлять переменные типа блобов - это да, но ничто не мешает работать с их содержимым, хранящимся в таблице. И, кстати, благодарить за такой подход надо Sybase.
ASCRUS
только клиенту тупо отдать и взять и ничего же - SQL.RU крутится себе
Сомневаюсь, что для хранения сообщений на SQL.RU используется блоб.

Так а как с ними внутри хранимки работать ? Максимум - выдрать только часть, которая по длине войдет в varchar. Sybase мы спасибо говорить не будем, он никакого отношения к Ваткому и ASA не имеет, кроме торговой марки, у нас поля и переменные до 2 гб обрабатываются аналогично другим типам, без каких либо ограничений ;) Ну а насчет хранения сообщений SQL.RU - а где же их еще хранить то, неужели в varchar(8000) ?
16 май 06, 15:40    [2669949]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
ChA
Member

Откуда: Москва
Сообщений: 11376
ASCRUS
Максимум - выдрать только часть, которая по длине войдет в varchar.
Можно "выдрать", можно "тыдрать", бишь, заменить или удалить часть блоба или целиком. IMHO, это не совсем соответствует утверждению
ASCRUS
у MSSQL2000 вообще с блобами никак работать нельзя
, не так ли ?
ASCRUS
Sybase мы спасибо говорить не будем, он никакого отношения к Ваткому и ASA не имеет, кроме торговой марки, у нас поля и переменные до 2 гб обрабатываются аналогично другим типам, без каких либо ограничений
Можете не говорить, но такой способ работы с блобами был унаследован от своего предка, коим был Sybase. Рад за Sybase, что он сделал шаг вперед раньше, чем MS SQL, который сделал то же самое только в версии 2005. Не считаю это большим достижением, так как РСУБД предназначены, IMHO, не для обработки текста или графики условно неограниченного размера.
ASCRUS
Ну а насчет хранения сообщений SQL.RU - а где же их еще хранить то, неужели в varchar(8000) ?
Не имею ни малейшего понятия, Вы, как модератор, могли бы напрямую обратиться к judge с этим вопросом. Если форумы реализованы на MSSQL, то нет уверенности, что хранить все сообщения именно в блобе является оптимальным вариантом, не так уж много сообщений, размер которых превышает пресловутые 8000 символов. Впрочем, может быть и в блобе...
16 май 06, 17:30    [2670659]     Ответить | Цитировать Сообщить модератору
 Re: DB2 Express-C против - MS SQL Server 2000 -???  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
ChA
Можете не говорить, но такой способ работы с блобами был унаследован от своего предка, коим был Sybase. Рад за Sybase, что он сделал шаг вперед раньше, чем MS SQL, который сделал то же самое только в версии 2005. Не считаю это большим достижением, так как РСУБД предназначены, IMHO, не для обработки текста или графики условно неограниченного размера.

Рано радуетесь, что то я не припоминаю, чтобы в ASE хоть что то можно было сделать с блобом, хотя я конечно в родной СУБД от Sybase не специалист и не знаю, что они в 15-ой версии сделали. Ну а насчет обработки мне кажется Вы не правы - как только дело начинает касаться реализации логики в пределах БД, XML, вебсервисов и т.д. то очень даже нужно уметь работать с типами больших размеров на языке хранимых процедур. Ну а если еще и динамический SQL правильно реализован, без каких либо ограничений на права доступа и оптимизацию, то собрать и выполнить любой скрипт без ограничения размера (вернее с ограничением до 2 гб) прямо внутри ХП вообще иногда получается очень даже полезным.
16 май 06, 18:18    [2670932]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить