Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 16 17 18 19 20 21 22 [23] 24 25   вперед  Ctrl
 Re: Конец SQL?  [new]
servit
Member

Откуда: г. Кишинёв, Республика Молдова
Сообщений: 3148
Блог
okidoki
Интересен именно тренд. Здесь http://www.google.com/trends/explore#q=sql%2C%20C%2C%20Java%2C%20JavaScript%2C%20PHP&cmpt=q можно почувствовать тенденции. Популярность и интерес к SQL не растет, в отличие от языка C (возможно последнему помогли планшетники и смартфоны). Но, то что SQL обошел даже PHP, весьма показательно.
А что делает витамин C и гепатит C в результатах?
Если вместо PHP поставить M, результат очень даже неплохой: конфеты M&M’s пользуются популярностью.
4 фев 13, 12:51    [13871748]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
okidoki
Member

Откуда:
Сообщений: 36
servit
okidoki
Интересен именно тренд. Здесь http://www.google.com/trends/explore#q=sql%2C%20C%2C%20Java%2C%20JavaScript%2C%20PHP&cmpt=q можно почувствовать тенденции. Популярность и интерес к SQL не растет, в отличие от языка C (возможно последнему помогли планшетники и смартфоны). Но, то что SQL обошел даже PHP, весьма показательно.
А что делает витамин C и гепатит C в результатах?
Если вместо PHP поставить M, результат очень даже неплохой: конфеты M&M’s пользуются популярностью.
Согласен :). Ну тогда http://www.google.com/trends/explore#q=sql%2C%20Java%2C%20JavaScript%2C%20PHP%2C%20C%23&cmpt=q. Все-равно растет только C#
4 фев 13, 13:00    [13871820]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
mayton
Member

Откуда: loopback
Сообщений: 52929
skyANA
okidoki
Один из вариантов, использовать разделители вместо слов. В этом новые NoSQL-языки выигрывают.

SQL SELECT Statement:
SELECT user_id, status FROM users

MongoDB find() Statement:
db.users.find({}, { user_id: 1, status: 1 })

Посчитаем количество слов и разделителей?

Это настоящий вброс. Здесь оба реквеста нельзя
рассматривать без контекста их использования.
4 фев 13, 13:03    [13871842]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
okidoki
locky
Друг мой, если для вас основной боттлнек заключается в недостаточно скорости токенизации (и, как следствие вариант решения - сокращение длины токенов) - то у меня для вас есть плохая новость - вы выбрали себе совершенно не ту профессию
Очевидно у нас разные профессии :) Вы ближе к пользователям (да, похоже и недоуч). Разработчики СУБД компиляции и интерпретации уделяют наиважнейшее значение. Почитайте Oracle Database 11g: The Top Features for DBAs and Developers.


Ээээээ..... и как, простите, на качестве "компиляции и интерпретации" сказывается средняя длина токена в исходной языке?

предположим, я уменьшил длину токена вдвое - во сколько раз быстрее стало выполнение стейтментов?

Рассмотрите пример для сферической машины выполнения в вакууме - и для конкретно т-скл
4 фев 13, 13:08    [13871881]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
okidoki
Member

Откуда:
Сообщений: 36
mayton
skyANA
пропущено...

SQL SELECT Statement:
SELECT user_id, status FROM users

MongoDB find() Statement:
db.users.find({}, { user_id: 1, status: 1 })

Посчитаем количество слов и разделителей?

Это настоящий вброс. Здесь оба реквеста нельзя
рассматривать без контекста их использования.
Тут интересен даже не контекст, а сложность самого запроса (опять же с вложенностями и джоинами). Но человек уже понимает язык MongoDB.

Кстати, мне совершенно не нравятся в нем конструкции типа A:{$gt:1} вместо A>1. С ним еще надо разбираться (чтобы найти кучу недостатков)
4 фев 13, 13:37    [13872142]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
okidoki
mayton
пропущено...

Это настоящий вброс. Здесь оба реквеста нельзя
рассматривать без контекста их использования.
Тут интересен даже не контекст, а сложность самого запроса (опять же с вложенностями и джоинами). Но человек уже понимает язык MongoDB.

Кстати, мне совершенно не нравятся в нем конструкции типа A:{$gt:1} вместо A>1. С ним еще надо разбираться (чтобы найти кучу недостатков)
Так и что там со сложностью JOIN?
Давайте на реальном примере - как будете в MongoDB делать JOIN 2 таблиц с размером по 100 млн. строк?
Каждая таблица на диске занимает по 10 Гб.
Подскажу - в реляционной СУБД это будет HASH-JOIN.
4 фев 13, 14:35    [13872610]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
mayton
Member

Откуда: loopback
Сообщений: 52929
Alexander Ryndin
okidoki
пропущено...
Тут интересен даже не контекст, а сложность самого запроса (опять же с вложенностями и джоинами). Но человек уже понимает язык MongoDB.

Кстати, мне совершенно не нравятся в нем конструкции типа A:{$gt:1} вместо A>1. С ним еще надо разбираться (чтобы найти кучу недостатков)
Так и что там со сложностью JOIN?
Давайте на реальном примере - как будете в MongoDB делать JOIN 2 таблиц с размером по 100 млн. строк?
Каждая таблица на диске занимает по 10 Гб.
Подскажу - в реляционной СУБД это будет HASH-JOIN.

В Oracle если мне не изменяет память Hash-join эффективен когда одну
из таблиц (справочник с небольшим числом строк) можно прогрузить
в оперативку. А по второй пройтись full scan. Нот в вашем варианте
обе таблицы - 10 Гб. Могут возникнуть сложности с выделением памяти.
4 фев 13, 14:46    [13872689]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
mayton
Alexander Ryndin
пропущено...
Так и что там со сложностью JOIN?
Давайте на реальном примере - как будете в MongoDB делать JOIN 2 таблиц с размером по 100 млн. строк?
Каждая таблица на диске занимает по 10 Гб.
Подскажу - в реляционной СУБД это будет HASH-JOIN.

В Oracle если мне не изменяет память Hash-join эффективен когда одну
из таблиц (справочник с небольшим числом строк) можно прогрузить
в оперативку. А по второй пройтись full scan. Нот в вашем варианте
обе таблицы - 10 Гб. Могут возникнуть сложности с выделением памяти.
Ок.
1) Тогда оставляем эту же задачу, но говорим, что в случае с реляционкой задача решается HASH-JOIN+Partitioning
2) Ставим вторую задачу - что будет делать MongoDB, если одна таблица 100 млн. строк, вторая 10 млн. строк. Размер первой таблицы 10 Гб, второй таблицы 1 Гб. В реляционке здесь достаточно обычного HASH-JOIN
4 фев 13, 14:52    [13872744]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
mayton
Member

Откуда: loopback
Сообщений: 52929
Почитал что здесь пишут.

http://stackoverflow.com/questions/4067197/mongodb-and-joins
http://docs.mongodb.org/manual/applications/database-references/

Разумеется нет ни слова про планы исполнения запросов.
Предлагаю решения по использованию внешних _id, DBRefs.
Зачем нужны DBRefs - пока не понял.
4 фев 13, 15:45    [13873122]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Alexander Ryndin
okidoki
пропущено...
Тут интересен даже не контекст, а сложность самого запроса (опять же с вложенностями и джоинами). Но человек уже понимает язык MongoDB.

Кстати, мне совершенно не нравятся в нем конструкции типа A:{$gt:1} вместо A>1. С ним еще надо разбираться (чтобы найти кучу недостатков)
Так и что там со сложностью JOIN?
Давайте на реальном примере - как будете в MongoDB делать JOIN 2 таблиц с размером по 100 млн. строк?
Каждая таблица на диске занимает по 10 Гб.
Подскажу - в реляционной СУБД это будет HASH-JOIN.

совершенно не факт, кстати
может быть и MERGE
4 фев 13, 16:04    [13873243]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
locky
Alexander Ryndin
пропущено...
Так и что там со сложностью JOIN?
Давайте на реальном примере - как будете в MongoDB делать JOIN 2 таблиц с размером по 100 млн. строк?
Каждая таблица на диске занимает по 10 Гб.
Подскажу - в реляционной СУБД это будет HASH-JOIN.

совершенно не факт, кстати
может быть и MERGE
Возможно. Но вопрос не в этом. Вопрос в том, как это в Mongo? Кто там будет решать MERGE, NL, HASH использовать? Алгоритм с HASH-JOIN придется самому писать, насколько я понимаю. Короче, смущает вопрос непроработанности Join.
4 фев 13, 16:07    [13873270]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Alexander Ryndin
locky
пропущено...

совершенно не факт, кстати
может быть и MERGE
Возможно. Но вопрос не в этом. Вопрос в том, как это в Mongo? Кто там будет решать MERGE, NL, HASH использовать? Алгоритм с HASH-JOIN придется самому писать, насколько я понимаю. Короче, смущает вопрос непроработанности Join.

ну да, такая себе Икея - вот тебе набор примитивов, можешь собрать себе почти всё что угодно.
в нормальных субд, кстати, всегда есть возможность явно указать серверу тип и порядок соединения
4 фев 13, 16:09    [13873286]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Alexander Ryndin
Короче, смущает вопрос непроработанности Join.


А разве Вас не убедило:

okidoki
Получается БД, это множество коллекций (лучше несвязанных). А коллекции в NoSQL (на JSON), это - такие денормализованные таблицы.


На то они, скорей всего, и денормализованные и "лучше несвязные", чтобы можно было вполне обойтись "непроработанными Join" или вообще без Join. А так бы нормализовали и тот пример с Раковым с днями рождениями, страховыми, увольнениями давно бы привели. Это вам не просто HASH-JOIN, тут на уровне логики смущения.

Попробуйте довольствоваться другим:
"Ну хорошо, вместо аргументов еще можно использовать статистику, тенденцию в популярности."
Там Сишарп типа растет, а Вы тут смущаетесь "недоработанностью Join"
4 фев 13, 18:36    [13874261]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
locky
Alexander Ryndin
пропущено...
Возможно. Но вопрос не в этом. Вопрос в том, как это в Mongo? Кто там будет решать MERGE, NL, HASH использовать? Алгоритм с HASH-JOIN придется самому писать, насколько я понимаю. Короче, смущает вопрос непроработанности Join.

ну да, такая себе Икея - вот тебе набор примитивов, можешь собрать себе почти всё что угодно.
в нормальных субд, кстати, всегда есть возможность явно указать серверу тип и порядок соединения
Напоминает старый андекдот на новый лад:
+
Картинка с другого сайта.
4 фев 13, 18:45    [13874281]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
Барсук-копатель
Member [заблокирован]

Откуда: Московский парк
Сообщений: 94884
Оказывается, SQL-based СУБД тормозят из-за использования естественных языковых конструкций в запросах. Мир sql-разработчиков потрясён. Воцарился хаос в их рядах. С содроганием и ужасом ждём дальнейших перлов от noSQL-девелОперов.
4 фев 13, 19:29    [13874386]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
okidoki
Member

Откуда:
Сообщений: 36
vadiminfo
На то они, скорей всего, и денормализованные и "лучше несвязные", чтобы можно было вполне обойтись "непроработанными Join" или вообще без Join. А так бы нормализовали и тот пример с Раковым с днями рождениями, страховыми, увольнениями давно бы привели. Это вам не просто HASH-JOIN, тут на уровне логики смущения.

Попробуйте довольствоваться другим:
"Ну хорошо, вместо аргументов еще можно использовать статистику, тенденцию в популярности."
Там Сишарп типа растет, а Вы тут смущаетесь "недоработанностью Join"
Ну вот и ВадимИнфо начал разбираться в НоСКЛ. Но спрашивать у НоСКЛ-ов "соедините (через ДЖОИН) мне разные коллекции по 1-10 ГБ", это тоже самое, что спрашивать у СКЛ-ов объедините (денормализуйте) мне те же таблицы в 1-10ГБ". У НоСКЛ во 2-м случае не будет той чудовищной потери в памяти, как СКЛ. Конечно такую денормализацию (объединение коллекций) админ должен делать автономно, но зато потом получаем эффект в скорости запроса, ну и в отсутствии транзакций. Скорость надеюсь понятна за счет чего? СКЛ-переход K1->T1->V1=join=>K1->T2->V2 заменяется на K1->T->V2. То есть переходы от K1 идут сразу ко всем записям T и уже от них к нужным атрибутам V2.
4 фев 13, 19:38    [13874409]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
okidoki
Member

Откуда:
Сообщений: 36
locky
Ээээээ..... и как, простите, на качестве "компиляции и интерпретации" сказывается средняя длина токена в исходной языке?

предположим, я уменьшил длину токена вдвое - во сколько раз быстрее стало выполнение стейтментов?

Рассмотрите пример для сферической машины выполнения в вакууме - и для конкретно т-скл
Вы знаете как работает Си или Ассемблер? Ну не могу я заниматься обучением. Просто нет времени. Просто для справок. Перекачка блока в 256 байтов внутри ОП (опер. памяти) превосходит чтение такого же блока из ВП (внеш. памяти) всего в 2-3 раза в среднем, с учетом управления этой ОП (выделение своб. памяти, сборка мусора и тд). А если обращений к ОП в 10ки раз больше при выполнении каких-то рекурсивных и пр. операций, тогда где мы проигрываем? Найдите мне опровержение или подтверждение в Интернете. Очень интересно самому.
4 фев 13, 20:03    [13874472]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
okidoki
locky
Ээээээ..... и как, простите, на качестве "компиляции и интерпретации" сказывается средняя длина токена в исходной языке?

предположим, я уменьшил длину токена вдвое - во сколько раз быстрее стало выполнение стейтментов?

Рассмотрите пример для сферической машины выполнения в вакууме - и для конкретно т-скл
Вы знаете как работает Си или Ассемблер? Ну не могу я заниматься обучением. Просто нет времени. Просто для справок. Перекачка блока в 256 байтов внутри ОП (опер. памяти) превосходит чтение такого же блока из ВП (внеш. памяти) всего в 2-3 раза в среднем, с учетом управления этой ОП (выделение своб. памяти, сборка мусора и тд). А если обращений к ОП в 10ки раз больше при выполнении каких-то рекурсивных и пр. операций, тогда где мы проигрываем? Найдите мне опровержение или подтверждение в Интернете. Очень интересно самому.


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

насчет всего прочего (типа - "скорость дисковых операций всего в 2-3 раза медленнее, чем скорость ОЗУ") - я даже не могу ничего написать. Тупо не могу проржаться.

зы сборка мусора у него, ишь ты! в СУБД, ага. И буфера он выделяет "по требованию".
4 фев 13, 20:11    [13874499]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
mayton
Member

Откуда: loopback
Сообщений: 52929
Надо всех людей переименовать. Чтоб имена были короче блеать. А то в индекс ложатсься и сикуентал рид
получается долгий. Хехе... хехе.
4 фев 13, 20:18    [13874520]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30244
locky,

он про внутреннюю и внешнюю память относительно процессора. Но, в любом случае человек не понимает, что парсинг SQL-запроса это микроскопическое время в отношении остальных задач - проверки существования всех используемых объектов, построения плана, и т.д., и даже (о боже) передачи этого запроса по сети от клиента серверу.
4 фев 13, 22:02    [13874778]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
okidoki
Ну вот и ВадимИнфо начал разбираться в НоСКЛ.

типа okidoki похоже верит, что если сказать что кто-то в чем-то начал разбираться, то это означает, что сказавший то разобрался. И так можно всех обхитрить начет своего уровня.
Но я разобрался не в НоСКЛ, а в том что скрывается за пропагандой денормализации в ходе пиара Манги как конца SQL: какие-то напряги с соединениями. И задавал вопросы, в которых напрямую слова соединения не было, но была бы МД с "деромализацией".
Но ответа не получил. Причем и другие спрашивали.

okidoki
Но спрашивать у НоСКЛ-ов "соедините (через ДЖОИН) мне разные коллекции по 1-10 ГБ",
это тоже самое, что спрашивать у СКЛ-ов объедините (денормализуйте) мне те же таблицы в 1-10ГБ".
У НоСКЛ во 2-м случае не будет той чудовищной потери в памяти, как СКЛ. Конечно такую денормализацию (объединение коллекций) админ должен делать автономно, но зато потом получаем эффект в скорости запроса, ну и в отсутствии транзакций. Скорость надеюсь понятна за счет чего? СКЛ-переход K1->T1->V1=join=>K1->T2->V2 заменяется на K1->T->V2. То есть переходы от K1 идут сразу ко всем записям T и уже от них к нужным атрибутам V2.

Вы прямо скажите: В Маге траблы с соединениями, потому приходится искать всякие оправдания денормализации. А потом уж придумывайте всякие там отмазы про админов, что Вы там получаете. На СКЛ налабать денормализвануую МД много ума не надо, если че.
4 фев 13, 22:06    [13874793]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
okidoki
vadiminfo
На то они, скорей всего, и денормализованные и "лучше несвязные", чтобы можно было вполне обойтись "непроработанными Join" или вообще без Join. А так бы нормализовали и тот пример с Раковым с днями рождениями, страховыми, увольнениями давно бы привели. Это вам не просто HASH-JOIN, тут на уровне логики смущения.

Попробуйте довольствоваться другим:
"Ну хорошо, вместо аргументов еще можно использовать статистику, тенденцию в популярности."
Там Сишарп типа растет, а Вы тут смущаетесь "недоработанностью Join"
Ну вот и ВадимИнфо начал разбираться в НоСКЛ. Но спрашивать у НоСКЛ-ов "соедините (через ДЖОИН) мне разные коллекции по 1-10 ГБ", это тоже самое, что спрашивать у СКЛ-ов объедините (денормализуйте) мне те же таблицы в 1-10ГБ". У НоСКЛ во 2-м случае не будет той чудовищной потери в памяти, как СКЛ. Конечно такую денормализацию (объединение коллекций) админ должен делать автономно, но зато потом получаем эффект в скорости запроса, ну и в отсутствии транзакций. Скорость надеюсь понятна за счет чего? СКЛ-переход K1->T1->V1=join=>K1->T2->V2 заменяется на K1->T->V2. То есть переходы от K1 идут сразу ко всем записям T и уже от них к нужным атрибутам V2.
ну хорошо, давайте попробуем с объемами поменьше, с денормализацией, без транзакций
Задачу Эйнштейна сможете продемонстрировать как решить?
4 фев 13, 23:20    [13875003]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
-2-
Member

Откуда:
Сообщений: 15330
okidoki
это тоже самое, что спрашивать у СКЛ-ов объедините (денормализуйте) мне те же таблицы в 1-10ГБ".
денормализовать не проблема. тут проблема больше в целостности для OLTP, чем в нежелании полчать быстрее результат некоторых отчетов. Да и то, что для реляционной структуры ненормально, для MOLAP вполне может оказаться каноническая модель. Другой вопрос, готов ли платить бизнес за денормализацию, чтобы вместо получаса, получать уже вчерашний отчет, хоть и за секунду.

okidoki
У НоСКЛ во 2-м случае не будет той чудовищной потери в памяти, как СКЛ.
какой памяти? то, что ты называешь денормализацией, в РСУБД называют индексом. Адрес что объекта, что строки в рсубд весит исходя из объемов, на которые нужно ссылаться. Если же ты хранишь множество копий объекта в других объектах, то помимо проблем с объемами - проблемы с обеспечением целостности, которые неприемлемы для многих классов задач.

okidoki
То есть переходы от K1 идут сразу ко всем записям T и уже от них к нужным атрибутам V2.
проход по связанному списку объектов ничем не отличается от прохода по индексу.

okidoki
но зато потом получаем эффект в скорости запроса, ну и в отсутствии транзакций
за счет чего скорость? Что в лоб, что по лбу - проход по индексу или фулскан для выборки объекта/строки по атрибутам. и переход по ссылке/адресу строки на связанные объекты/строки. Ну есть в оракле помимо rowid еще ref на объекты. Только за полтора десятка лет с его появления никому ref/deref так ни разу и не понадобился.

okidoki
ну и в отсутствии транзакций
а это зачем называть базой данных? Даже файловые системы поддерживают транзакции, но их не называют СУБД, поскольку предназначены для только узкого круга специальных задач - работа с файлами.
5 фев 13, 03:00    [13875361]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
mayton
skyANA
пропущено...

SQL SELECT Statement:
SELECT user_id, status FROM users

MongoDB find() Statement:
db.users.find({}, { user_id: 1, status: 1 })

Посчитаем количество слов и разделителей?

Это настоящий вброс. Здесь оба реквеста нельзя
рассматривать без контекста их использования.
И в чём же заключается вброс?

Вот Вам контекст: SQL to MongoDB Mapping Chart. Поищите в нём следущее:
Select
The following table presents the various SQL statements related to reading records from tables and the corresponding MongoDB statements.
5 фев 13, 19:37    [13880224]     Ответить | Цитировать Сообщить модератору
 Re: Конец SQL?  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
mayton
skyANA
пропущено...

SQL SELECT Statement:
SELECT user_id, status FROM users

MongoDB find() Statement:
db.users.find({}, { user_id: 1, status: 1 })

Посчитаем количество слов и разделителей?

Это настоящий вброс. Здесь оба реквеста нельзя
рассматривать без контекста их использования.
И в чём же заключается вброс?

Вот Вам контекст: SQL to MongoDB Mapping Chart. Поищите в нём следущее:
Select
The following table presents the various SQL statements related to reading records from tables and the corresponding MongoDB statements.
5 фев 13, 19:45    [13880252]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 16 17 18 19 20 21 22 [23] 24 25   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить