Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 11 [12] 13 14 15   вперед  Ctrl
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
mayton
Member

Откуда: loopback
Сообщений: 53024
Симонов Денис
Leonid Kudryavtsev,

всё меняется когда нужен LEFT JOIN и вот тут то совместимость Оракловых (+) пропадает.

Денис. А вы можете привести пример запроса на Non-Oracle системе
в котором нет совместимости с Oracle?
7 окт 14, 14:15    [16671187]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
mayton,

наоборот сколько угодно, а так да все основные фичи из других СУБД Оракл поддерживает.

Ну разве пример может быть любой запрос в котором стоит условие table1.str_field is null. Причём по условию задачи пустая строка и null разные вещи.

P.S. Как мне кажется тут спор был не о том лучше или хуже Оракл, а о том что не следует пихать Оракл в каждую бочку в качестве затычки.
7 окт 14, 14:25    [16671245]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
mayton
Member

Откуда: loopback
Сообщений: 53024
Симонов Денис, минутку.

Меня интересовал вопрос LEFT JOIN и Ораклового (+).
7 окт 14, 14:27    [16671263]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67475
Блог
Dimitry Sibiryakov
и уходить с него на нативный не желает как раз из-за совместимости с другими СУБД.

Из-за чего-чего?
7 окт 14, 14:55    [16671485]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67475
Блог
Симонов Денис
Ну разве пример может быть любой запрос в котором стоит условие table1.str_field is null. Причём по условию задачи пустая строка и null разные вещи.

Я много лет прошу всех встречных привести мне реальный разумный пример такой задачи. Если коротко, ни разу не услышал ничего вменяемого.
7 окт 14, 14:57    [16671496]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9894
mayton
Вобщем и хотя Оракл поддерживает синтаксис JOIN - его знающие Oracle девелоперы не используют 99.9% я гарантирую это...

Ну не факт.

1. Есть ситуации LEFT JOIN, которые в ANSI синтаксисе можно написать, а через (+) нельзя. Ну или _очень_сильно_ извращаясь, а в Ansi синтаксисе все понятно, просто и даже работает.
2. Для начинающих людей ANSI синтаксис значительно понятнее. В свое время, когда нужно было делать отчеты для пром. системы - всех учил именно ANSI синтаксису.
+

Разумеется получался "говнокод". НО:
2.1 Отчеты быстро разрабатывались парой _студентов_. Что было _критично_. Отчетов было за сотню. Т.ч. тратить на них много времени было нельзя.
2.2. Даже несмотря на говнокод, Oracle их обрабатывал вполне успешно )))
2.3. Отчеты которые "вставали колом" или по результату кодирования оказывалось перевязано слишком много таблиц - просто передавались более компетентным разработчикам, которые оперативно и быстро (1-2 часа) упрощали запросы (часто просто методом выкидывания не нужных таблиц).

Как показывает последующий опыт работы: проблема обычно состоит не в говнокоде или синтаксисе (Oracle или ANSI), а в задании. Если отчет изначально, по постановке, строится full table scan'ом и/или "отчет на десять тысяч страниц медленно формируется", тут никакой синтаксис не поможет. Если же отчет изначально строится исходя из структуры БД и сразу же выборка ограничена индексами - то хоть десять раз одну и ту же таблицу сам-на-себя свяжи, Oracle перемолотить ))). Ну будет вместо 0,1 сек. запрос выполняться за 0,2 сек - с точки зрения бизнеса пережить можно ))). А вот срыв сроков внедрения на пару лет из-за того, что необходимых отчетов в системе нет - бизнес уже не переживет

IMHO & AFAIK

3. Т.ч. на мой взгляд, ANSI синтаксис в Oracle необходим. И иногда приходится им пользоваться.
7 окт 14, 14:59    [16671516]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Dimitry Sibiryakov
Member

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

mayton
А вы можете привести пример запроса на Non-Oracle системе в котором нет
совместимости с Oracle?

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

Posted via ActualForum NNTP Server 1.5

7 окт 14, 15:03    [16671535]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9894
softwarer
Я много лет прошу всех встречных привести мне реальный разумный пример такой задачи. Если коротко, ни разу не услышал ничего вменяемого.

AFAIK Такое может встретиться, если кто-то решил в структуре БД на строковых полях повторить троичную булевую логику )))
1. Строка символов - данные
2. Пустая строка символов - просто данные пустые
3. null - что-то другое (например: "данные просто еще не введены", их требуется ввести).

Такую структуру БД, разумеется, портировать на Oracle будет проблематично.
7 окт 14, 15:03    [16671539]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9894
Dimitry Sibiryakov
Чуть выше сообщения по ссылке была ещё одна ссылка на список случаев применения
стандартного синтаксиса в которых Оракул в лучшем случае падает, а в худшем - выдаёт
неправильный результат.

Понятие "стандартный" и "падает" вещь относительная.

Можно найти 100500 случаев, в которых Oracle выполнить "стандартный" запрос. А остальные БД не выполнят. Например "встанут колом" ))). И никакой "стандарт" и "стандартный синтаксис" тут не поможет.

IMHO & AFAIK
+

Значительно интереснее, что в случае данного падения ответил саппорт. Если, конечно, к нему обращались. И была ли проблема решена по результату.
7 окт 14, 15:08    [16671577]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
mayton
Member

Откуда: loopback
Сообщений: 53024
Leonid Kudryavtsev
3. Т.ч. на мой взгляд, ANSI синтаксис в Oracle необходим. И иногда приходится им пользоваться.

Есть где-то пруф. Если найду то приаттачу. От Оракловой документации. Вобщем
смысл его в том что ни одна из современных СУБД не может претендовать на
полностью поддержвающую ANSI-[NN] версию диалекта SQL.
7 окт 14, 15:09    [16671582]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
mayton
Member

Откуда: loopback
Сообщений: 53024
Leonid Kudryavtsev
Понятие "стандартный" и "падает" вещь относительная.

Можно найти 100500 случаев, в которых Oracle выполнить "стандартный" запрос. А остальные БД не выполнят. Например "встанут колом" ))). И никакой "стандарт" и "стандартный синтаксис" тут не поможет.

IMHO & AFAIK

Несколько мыслей. Есть чистая теория. Т.н. реляционная алгеба. Она определяет операцию реляционного
деления. Одну таблицу делим на другую и получаем отношение. Есть также у нее свой смысл и своё
теоретическое обоснование как умножение и деление кватернионов и октав в алгебре векторов.
Но она (операция деления) не имеет своей имплементации в стандартах SQL. В SQL-ях
нет операции DIVIDE, DIVISION e.t.c.

Что это? Нарушение AnsiSQL принципов РА? Или просто адаптация стандарта под аппаратную базу?

Я не знаю.
7 окт 14, 15:15    [16671623]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67475
Блог
Leonid Kudryavtsev
1. Есть ситуации LEFT JOIN, которые в ANSI синтаксисе можно написать, а через (+) нельзя.

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

Leonid Kudryavtsev
Для начинающих людей ANSI синтаксис значительно понятнее.

Лично я затруднюсь ответить на вопрос начинающего "какие условия писать в join, какие в where и почему именно так?"

Leonid Kudryavtsev
3. Т.ч. на мой взгляд, ANSI синтаксис в Oracle необходим

За всё время, что я работаю в IT, я убедился, что всевозможные переключатели серии "как больше нравится" мало помогают и много вредят. Даже если предположить, что у ANSI синтаксиса есть какие-то преимущества, то количество сил, которое вбухали в его поддержку - это то количество сил, которого не хватило сделать что-либо реально нужное вместо повторения существующего, и уже в этом он навредил куда больше, чем принёс пользы.

Leonid Kudryavtsev
AFAIK Такое может встретиться, если

Я прошу не абстрактные слова, а реальный пример бизнес-задачи из жизни. Самое смешное, что я сам такой пример знаю. Один. Редкий, но реальный. Но и его мне никто никогда не называл. Всегда спрашиваю, скажем: ну вот у врача поле "диагноз", опиши задачу, для которой надо различать "диагноз равен пустой строке" и "диагноз равен нуллу", и в ответ слышу.... ну ооооочень натянутые соображения типа "если немыслимо извернуться, то может кому-то когда-то и потребуется".
7 окт 14, 15:16    [16671632]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Dimitry Sibiryakov
Member

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

Leonid Kudryavtsev
Можно найти 100500 случаев, в которых Oracle выполнить
"стандартный" запрос. А остальные БД не выполнят. Например "встанут колом" ))).

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

Posted via ActualForum NNTP Server 1.5

7 окт 14, 15:19    [16671662]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30265
Leonid Kudryavtsev,

пример: Фамилия, Имя, Отчество. Не у всех есть отчество (null), но оно может быть просто не введено (пустая строка). Понять, что отчество "не введено" при '' = null невозможно.
7 окт 14, 15:20    [16671667]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
mayton
Member

Откуда: loopback
Сообщений: 53024
Leonid Kudryavtsev
softwarer
Я много лет прошу всех встречных привести мне реальный разумный пример такой задачи. Если коротко, ни разу не услышал ничего вменяемого.

AFAIK Такое может встретиться, если кто-то решил в структуре БД на строковых полях повторить троичную булевую логику )))
1. Строка символов - данные
2. Пустая строка символов - просто данные пустые
3. null - что-то другое (например: "данные просто еще не введены", их требуется ввести).
е
Такую структуру БД, разумеется, портировать на Oracle будет проблематично.

Я предполагаю что это подлая и банальная оптимизация ресурсов. Возможно создатели
Dbms Oracle сильно экономили место в DbBlocks и решили что если не хранить в таблице
пустую строку "" и заменить ее на NULL то будет сущесвтенный выигрыш. Это правда.
NULL, в Oracle дейтсвительно схлопывают пространство и не выделяют места. Этим
часто пользуются при планирование места. Можно на уровне архитектуры приложения
заложить NULL как справочное значение или foreign с относительной частотой 99%
по анализатору.

А что такое пустая строка символов "" с точки зрения оператора Forms-апликухи?
Дефект? Ошибка? Разгильдяйство? Что такое пустая строка с точки зрения
Принтабельности? Как ее эту чёртову пустую строку шлёпнуть на принтер?
Да никак. Нет ее.

Здесь прослеживается аналогия с BCD арифметикой. Oracle повторяет
операции человека-бухгалтера или финансиста который делает расчёты
карандашём на бумаге. Практика решила как правильно. Не int. Не long int.
Не дабл не флоат. А именно BCD является фундаментальным типом
финансовых вычислений. И это пришло из практики.
7 окт 14, 15:22    [16671683]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Dimitry Sibiryakov
Member

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

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

Ok, как пишется в нативном синтаксисе FULL OUTER JOIN?

Posted via ActualForum NNTP Server 1.5

7 окт 14, 15:27    [16671715]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67475
Блог
mayton
Я предполагаю что это подлая и банальная оптимизация ресурсов. Возможно создатели
Dbms Oracle сильно экономили место

Я предполагаю (в смысле, практически уверен), что всё куда проще. Просто выбранный формат хранения приводит к тому, что и пустая строка, и нулл хранятся абсолютно одинаково (как ноль байт). Был бы, скажем, как в MSSQL, вектор "ненулловых полей" - и пустая строка отличалась бы, а его нет - и их действительно физически не различишь. А специально делать различие тогда, спасибо большое, не стали, а нынешние идиоты сломать пока не решаются (за что им спасибо ещё больше).
7 окт 14, 15:30    [16671734]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Yo.!
Guest
kdv
Leonid Kudryavtsev,

пример: Фамилия, Имя, Отчество. Не у всех есть отчество (null), но оно может быть просто не введено (пустая строка). Понять, что отчество "не введено" при '' = null невозможно.

а потом эти данные экспортируются в соседнюю систему и начинается гадание на кофейной гуще, что бы могло означать нулл, а что пустая строка. может пустая строка введено, но отсутсвует, а нулл - забыли ввести ? а может наоборот. а может просто дурной дизайн субд, которая устраивает геморой на пустом месте.
7 окт 14, 15:31    [16671748]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
Dimitry Sibiryakov
Ok, как пишется в нативном синтаксисе FULL OUTER JOIN?

Известно как t1.a(+)=t2.a(+).
Другое дело, что исторически это забанено.
7 окт 14, 15:31    [16671749]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67475
Блог
Dimitry Sibiryakov
softwarer
в итоге каждый раз оказывается, что "нельзя" следует читать как "я не умею
и вообще не подумал".

Ok, как пишется в нативном синтаксисе FULL OUTER JOIN?

Дим, твоё неумение читать (ну или умение нагло передёргивать) просто поражает. И прежде чем писать следующую реплику, подумай над тем, что у меня уже есть ответ на неё
7 окт 14, 15:32    [16671757]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67475
Блог
Сергей Арсеньев
Dimitry Sibiryakov
Ok, как пишется в нативном синтаксисе FULL OUTER JOIN?

Известно как t1.a(+)=t2.a(+).
Другое дело, что исторически это забанено.

Не совсем. Например, в Oracle Warehouse Builder такой синтаксис отлично работает.
7 окт 14, 15:33    [16671765]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
А еще в Oracle можно так:
with t1 as (select 1 a from dual)
,t2 as (select 2 a from dual)
select * from t1 full outer join t2 on (t1.a=t2.a(+))

Надеюсь так никто не пишет.
7 окт 14, 15:45    [16671870]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9894
softwarer
Leonid Kudryavtsev
1. Есть ситуации LEFT JOIN, которые в ANSI синтаксисе можно написать, а через (+) нельзя.

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

AFAIK Ситуация, когда по outer join нужно связать одну таблицу с несколькими. В Ansi Join это прописывается элементарно, если тупо заменить на (+) получаем ORA-01417. Ситуация редкая, но пару раз мне такие запросы делать пришлось. Без достаточно извращенных подзапросов или временный таблиц мне было и не написать. Если я правильно помню, даже с подзапросами было не все гладко, вроде Oracle их раскрывать пытался и все работало не совсем предсказуемым образом.

Но ANSI синтаксис, в любом случае, намного понятнее. Лично мне и тем, кого я знаю. Кроме того, в Ansi синтаксисе значительно сложнее сделать ошибку. При сложном запросе (скажем 10-15 таблиц) пропустить какое либо условие достаточно просто, а найти ошибку крайне сложно. В ANSI синтаксисе и сложнее пропустить условие связи (т.к. все описываются в отдельных секциях), и проще такую ошибку отловить, и текст запроса IMHO намного более структурированный и понятный.
+

Лично мне, вообще реалиционная алгебра и "SELECT" не нравятся. Т.к. отучают думать о структуре БД. Данные у нас есть - а теперь их найдите. А то, что данные лежат совершенно не в том виде - как бы всем пофиг, об этом никто не подумал.

Раньше, например в сетевых БД или даже в реалиционных (DBase, FoxPro), программист и все причастные должны были неизбежно думать о структуре БД, что было и не плохо. Если раньше работали, явно пользуясь структурой БД (например в DBase, FoxPro указывая связь таблиц через SET RELATION TO...), то теперь... Навалили все в таблицы... понаписали запросов... а там full table scan и hash join один на другом сидит и погоняет.

Если для отчетов это наверное и не плохо. То в большинстве случаев для ввода данных и OLTP систем, как мне кажется, "select" это просто какое-то извращение ((( на предыдущих средствах (явное указание структуры базы), было и проще и эффективнее. Сейчас, половина битвы за эффективность - это борьба С оптимизатором.

Если же возвращаясь к outer join. То, опять таки, например в DBase, FoxPro и/или старых сетевых базах данных, такой проблемы ВООБЩЕ не было. Есть отношение между таблицами, данные или найдены или не найдены. ВСЕ.

Вроде, в DBase, весь outer join сводился просто к настройкам отображения. Показывать или нет "пустые" строки.
7 окт 14, 15:51    [16671915]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9894
Yo.!
kdv
Leonid Kudryavtsev,

пример: Фамилия, Имя, Отчество. Не у всех есть отчество (null), но оно может быть просто не введено (пустая строка). Понять, что отчество "не введено" при '' = null невозможно.

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

Полностью поддерживаю

Особенно интересно, как в таком дизайне делать интерфейс пользователя. Когда есть поле для ввода, а дальше гадайте, что Вы перед собой видите "просто пустую строчку" или null

Крайне доставляло в Web-системе двойные пробелы в БД. На экране (html) они схлопывались, а в БД оставались повторы. Пользователи долго не могли понять, почему они делают просто copy/past, а данные система найти не может )))

Аналогично пустые пробелы в конце строк

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

p.s. Один из коллег, говорил, что ходить по граблям т.к. это устаревшая технология разработки. Он предлагал ходить по обручам от бочек. Говорил, что это доставляет больше удовольствий )))
7 окт 14, 16:00    [16671966]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9894
mayton
...Несколько мыслей. Есть чистая теория. Т.н. реляционная алгеба. Она определяет операцию реляционного
деления. Одну таблицу делим на другую и получаем отношение. Есть также у нее свой смысл и своё
теоретическое обоснование как умножение и деление кватернионов и октав в алгебре векторов.
Но она (операция деления) не имеет своей имплементации в стандартах SQL. В SQL-ях
нет операции DIVIDE, DIVISION e.t.c.

Что это? Нарушение AnsiSQL принципов РА? Или просто адаптация стандарта под аппаратную базу?

Я не знаю.

Ну ты и загнул.... )))

+

- Взять бы этого Канта, да за такие доказательства года на три в Соловки! - совершенно неожиданно бухнул Иван Николаевич.

Предложение отправить Канта в Соловки не только не поразило иностранца, но даже привело в восторг.

- Именно, именно, - закричал он, и левый зеленый глаз его, обращенный к Берлиозу, засверкал, - ему там самое место! Ведь говорил я ему тогда за завтраком: "Вы, профессор, воля ваша, что-то нескладное придумали! Оно, может, и умно, но больно непонятно. Над вами потешаться будут".
7 окт 14, 16:06    [16672011]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 11 [12] 13 14 15   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить