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

Откуда: Обнинск
Сообщений: 4802
shuklin

А сравнивать таблицы Cerebrum (без "мешка") против таблиц РБД действительно смешно.

Сравнивать Cerebrum с РБД вообще смешно. Cerebrumу сравниваться с Дореляционной ОМД еще куда нишло. Про сравнение с РБД и речи нет. На это могут претендовать лидеры среди ООСУБД типа Версанта. И пока им РБД не проиграет, зачем ей сравниваться со всякими поделиями от ОО, которым до Версанта как до Луны? Попробйте записаться на Открытый чемпионат Франции по теннису и сиграть там с кем нибудь из первой десятки. А с РБД типа сравниваться можно? А ведь это почти одно и то же.
1 фев 06, 14:10    [2309274]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
ggv
Member

Откуда:
Сообщений: 1810
vadiminfo - вы не правы, по теннису это слишком просто.
По боксу!
1 фев 06, 15:00    [2309590]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
shuklin
В РБД таблицы находятся чуть ли не на уровне физической реализации...
Что за "чуть ли не"? Находится или не находится? Интересненький способ высказать любую ерунду, прибавить "чуть ли не" и не придерешься, вроде бы понарошку сказано. Ох, Шуклин, ох, ловкач!
1 фев 06, 15:41    [2309890]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Во какой настырный... Ужо было и про физический уровень, и там дальше про "объект = строка!, и где то еще было, что отноешие тоже в строке, а ему хучь кол на голове теши...... Всё же IT такая отрасль, где наука вроде бы и есть, но, к сожалению, нет физической реальности нет, которая бы при нарушении неких принципов (типа "а давайте в перменной хранить переменную) ощутимо, физически давала бы по башке :).
1 фев 06, 16:28    [2310218]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
U-gene
Всё же IT такая отрасль, где наука вроде бы и есть, но, к сожалению, нет физической реальности нет, которая бы при нарушении неких принципов (типа "а давайте в перменной хранить переменную) ощутимо, физически давала бы по башке :).

Самое интересное - что при нарушении неких принципов в ИТ реальности можно вместо по башке получить очень заметное аддед валуе. Виртуальная реальность, однако. http://www.shuklin.com/ai/ht/ru/ai04001f.aspx
1 фев 06, 16:58    [2310418]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Критикан

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


Первый грубый результат. Версия vnpi_20051116_beta_1.zip. При создании 200000 объектов было затрачено 0:02:13 на атлоне 1.8 итого в среднем создание 1500 C# объектов / секунду. Объем RAM не критичен (на машине 512, но Cerebrum не выходит за предел 100М - ограничение заданное в ядре в виде константы). Уже видно, что сборщик мусора работает хуже чем мог бы. Буду думать как ускорить. И надо что то с оболочками делать ... Разумеется на C++ было бы гораздо быстрее благодаря отсутствию .NET - но это будет не так интересно как C#.
1 фев 06, 18:05    [2310800]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Э
Guest
shuklin
Уже видно, что сборщик мусора работает хуже чем мог бы. Буду думать как ускорить. И надо что то с оболочками делать ... Разумеется на C++ было бы гораздо быстрее благодаря отсутствию .NET - но это будет не так интересно как C#.


Извините, вроде где-то было, что вы не на C# свой Cerebrum пишите. Там было еще что-то про быстрый поиск объектов с помощью таблицы указателей.
Вопрос: Cerebrum написан на C#? Куда-то по ссылкам ходить не предлагать, достаточно "Да" или "Нет".
1 фев 06, 18:15    [2310843]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Вопросик - а эти обьекты вставлялись в пределах одной транзакции или коммитились после каждой вставки ? Просто разное время можно получить - у меня к примеру ASA9 в среднем по одной транзакции на запись идет 925 записей в сек (то есть в среднем миллион записей вставляется 18 мин), а если в рамках одной транзакции, то 11111 записей в сек (то есть вставка миллиона записей в цикле хранимки и последующим COMMIT занимает порядка 90 сек).
1 фев 06, 18:18    [2310860]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
pavelvp
Member

Откуда:
Сообщений: 673
shuklin
объектов было затрачено 0:02:13 на атлоне 1.8 итого в среднем создание 1500 C# объектов / секунду.
Это всё в оперативке, или как?
1 фев 06, 18:48    [2311021]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Э
Извините, вроде где-то было, что вы не на C# свой Cerebrum пишите. Там было еще что-то про быстрый поиск объектов с помощью таблицы указателей.
Вопрос: Cerebrum написан на C#? Куда-то по ссылкам ходить не предлагать, достаточно "Да" или "Нет".

Cerebrum написан на языке C, MC++ и C# для применения в среде .NET
1 фев 06, 19:21    [2311173]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
ASCRUS
Вопросик - а эти обьекты вставлялись в пределах одной транзакции или коммитились после каждой вставки ? Просто разное время можно получить - у меня к примеру ASA9 в среднем по одной транзакции на запись идет 925 записей в сек (то есть в среднем миллион записей вставляется 18 мин), а если в рамках одной транзакции, то 11111 записей в сек (то есть вставка миллиона записей в цикле хранимки и последующим COMMIT занимает порядка 90 сек).


Тут есть один момент. Всеже моя СУБД недоделана во многом. Так в пределах транзакции у меня скорость работы сейчас тоже больше чем вне ее пределов. Этот тест я гонял с отключенными транзакциями. Включать транзакции в текущем состоянии на вставке 200000 записей приведет к фатальным последсвиям. А порциями по 1000 объектов БД дает те же результаты. Как раз следующую версию я разрабатываю с учетом этой неприятности. Но в будущей версии скорость в пределах транзакции и вне ее должна быть или одинаковой или в транзакции чуть хуже - но это все пока гадание на кофейной гуще. Есть опубликованная версия - ее и тестирую. А что будет в следующей, я и сам не знаю. Очень много времени забирает создание оболочек. А на самом деле я оптимизацией еще не занимался вовсе, и под профайлером это дело ни разу не гонял. Так что еще все в переди и разочарования и победы ))
1 фев 06, 19:31    [2311211]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
pavelvp
shuklin
объектов было затрачено 0:02:13 на атлоне 1.8 итого в среднем создание 1500 C# объектов / секунду.
Это всё в оперативке, или как?


Нет. При старте с тарнзакциями текущая версия Cerebrum переходит в оперативку, и гдето на 2000-5000 объектов вываливается в своп, в результате скорость падает до неприемлемых показателей.
1 фев 06, 19:42    [2311249]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Чернышев Андрей Леонидович
Guest
Не понял, shuklin, что значит "это если резать объект" ? Какой из двух объектов (в терминах классической ОМД) в нашем примере нужно "резать" ? Или это какой-то объект в терминах Cerebrum нужно "резать" ?
И лучше бы было остановиться на каком-то одном способе (я уже говорил, что "методологический полиморфизм" - это обычно плохо, но может быть Вам удастся доказать, что это, наоборот, - хорошо).

Про полезность "частого нарушения целостности" в каких-то специфических задачах мне трудно спорить - Вам виднее. Что делать в обычных приложениях, где такие (двунаправленные по своей сути) связи, мягко говоря, преобладают (я, к своему стыду, не смог придумать ни одного примера "однонаправленной связи", такого, чтобы "избыточная двунаправленность" была бы еще и вредна) ? Получается, что пока Cerebrum либо нальзя использовать для "традиционных" задач, либо нужно реализовывать связи, как в РМД. Правильно ?
Ага, вот дальше Вы написали, что как раз наоборот ! В РМД был бы внешний ключ в Договоре. А Вы говорите, что скорее всего сделаете "коллекцию" в Партнере. Хорошо, и как тогда определить Партнера, "имея" конкретный Договор ?
Вот про М:М все встало на свои места - связь явно не поддерживается (как, впрочем и 1:1 и 1:М), а делается третий объект (или, все-таки, класс, если это приблизительно ООМД ?), "как в РМД", и, конечно, этот объект (который на самом деле - связь между сущностями) никак не отличается от других объектов (которые представляют сущности). Две коллекции пока отпадают (даже без характеристик связи), так как целостность не поддерживается.
1 фев 06, 20:10    [2311313]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Чернышев Андрей Леонидович
Guest
Особого риска нет, Павел Воронцов.
Я же сказал "делают", а не "возвращают". Я понимаю, что Вам не интересно что там делает СУБД (оптимизатор). Я мне это интересно. Могу напомнить пример, который уже "разбирали" в одной из тем. Система продажи билетов (например, железнодорожных) "продает" билет быстро, за ожидаемое в "цивилизованном мире" время, например, 5 секунд. Удалим некий индекс. Билет стал продаваться за 10 минут. Я утверждаю, что система перестала работать в принципе, а Вы, видимо, скажете, что она работает (просто медленнее). Видите какие у нас прямо противоположные точки зрения (конечно, если я угадал Вашу точку зрения).
А теперь удалим еще и отношение из БД, и билет вообще перестанет продаваться. И некоторые участники "спора", надеюсь, поймут, что программы в "Р"СУБД не отделены от данных, как они утверждали.

Ответа на два вопроса будет два. Я никогда не говорил, что один. Я только говорил, что в моем примере один "вопрос", и четко показал, что я (пользователь) хотел получить. Генератор запросов и отчетов любого объектного навигатора именно это и предъявит пользователю. Это же очевидно.
1 фев 06, 20:34    [2311362]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Чернышев Андрей Леонидович
Guest
Нет, нет, U-gene, не начну "крутить".
1 фев 06, 20:39    [2311373]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Чернышев Андрей Леонидович
Guest
Я Вас понял, pavelvp. Вы заслужили, а я не заслужил. Я и не спорю. Раз не приглашают, значит не заслужил. Это же очевидно. По-прежнему готов рассказать Вам на семинаре все что знаю (а Вы не знаете) в области БД.
1 фев 06, 20:42    [2311383]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Чернышев Андрей Леонидович
Guest
Я действительно ОШИБСЯ, а не описАлся. То есть цитату из Дейта я привел абсолютно точную, именно про ORDER BY. Никакой GROUP BY, а именно эта операция группирования использовалась в запросе, когда я написал что это не реляционная операция, у Дейта нет, а есть именно SUMMARIZE. Я говорил до этого, что не считаю "вертикальные" вычисления (все разновидности операций агрегирования) "модельными вычислениями" РМД, так как такие операции традиционно использовались и в других "моделях". Я это еще раз повторил, но СОВЕРШЕННО НЕ УМЕСТНО применил "как известно", ведь специалисты по "реляционной теории" считают ее "реляционной". А цитату, хотя и правильную, из Дейта, привел не к месту (мы же не про навигацию в РМД говорим), ПЕРЕПУТАВ операрации группирования и сортировки. Козел.
1 фев 06, 21:21    [2311434]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Чернышев Андрей Леонидович
Guest
Где "сколько же там все-таки отношений", с127 ? Вы решили, все-таки порассуждать о сути результата запроса ? Тогда читайте 2255042, 2255811 и т.д. И спрашивайте что не понятно - я отвечу. Или хотите научиться программировать на SQL ? Ваш последний результат давно получил Павел Воронцов. [Но отказался от него в "пользу" двух отношений (двух результатов), которые правда вычисляются одинаково.] С точки зрения реляционного замыкания он настолько же бессмысленен, насколько Ваш первый результат бессмысленен с практической точки зрения.
1 фев 06, 21:34    [2311447]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Чернышев Андрей Леонидович
Guest
Уважаемый CesaTheGuest. Куда я Вас "ткнул" ? Перечитайте 2299534 и 2303160, и скажите куда я Вас "ткнул" ?
Как я могу обратиться на MUMPS к данным "Р"СУБД, минуя "оптимизатор" ? Вот "так же" и Вы "можете обратиться" к данным ОСУБД на декларативном языке (например, к данным Cache на SQL). Здесь уже было обсуждение препятствует ли каким-либо образом ОМД декларативному программированию. Не препятствует. А РМД именно препятствует идентификации, навигации и разрушает семантику.
1 фев 06, 21:53    [2311466]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Чернышев Андрей Леонидович
Guest
А я знаю, что "засады нет", U-gene. Вы просто {2.3.5.1.4} упорядочили, получив {1,2,3,4,5}. Все нормально. Еще раз можно "лабораторку" провести. Результат будет таким же.
Я не против. У Вас тексты конкретные, потому что "математика", а меня не конкретные, потому что нет никаких базовых концепций теории баз данных, и нет самой теории баз данных.
1 фев 06, 22:06    [2311480]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Чернышев Андрей Леонидович

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

А заодно не отделены от РСУБД кассиры, потому что не продали билеты. А дверь не отделена от стены и поэтому прилагательное.

Чернышев Андрей Леонидович

Я говорил до этого, что не считаю "вертикальные" вычисления (все разновидности операций агрегирования) "модельными вычислениями" РМД, так как такие операции традиционно использовались и в других "моделях".

А я все думал у кого надо спарашивать что можно считать реляционным. Наконец то нашеля законодатель - главный поборник реляционности - ЧАЛ.

Чернышев Андрей Леонидович

Я Вас понял, pavelvp. Вы заслужили, а я не заслужил. Я и не спорю. Раз не приглашают, значит не заслужил. Это же очевидно. По-прежнему готов рассказать Вам на семинаре все что знаю (а Вы не знаете) в области БД.

Но после того как pavelvp узнает, то что знает ЧАЛ, но чего он не знал, его тоже могут не пригласить. Вот в чем трабла. Потому что с такими "знаниями" тока на балабановскую спичечную фабрику и могут пока еще пригласить. В остальные места надо навязываться самому со своими семинарами.
1 фев 06, 22:09    [2311484]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Чернышев Андрей Леонидович
Guest
Ну почему же не подействует, ggv. Подействует. Просмотрел сообщения после 2304163. Возразил один с127, намекнув, в очередной раз, что я - клоун.
Не знаю кто из вас, господа ggv и c127, "представляет общественность"...
Да и обсуждению "технических особенностей" Cerebrum не хотелось бы мешать.
1 фев 06, 22:19    [2311497]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
c127
Guest
Чернышев Андрей Леонидович
Нет, нет, U-gene, не начну "крутить".

"Не переживайте, с127, я никуда не "спрыгну"." сказал ЧАЛ 4 окт 05, 22:54, а через 2 недели 20 окт 05 в 16:50 спрыгнул самым позорным образом: "Поскольку я ясно объяснил почему РМД не пора на пенсию, считаю, что эта тема для меня исчерпана.
А поскольку я никогда ничего не рекламировал, и не пропагандировал, а никакие новые знания никому на sql.ru не нужны, то для меня исчерпана не только эта тема, а sql.ru.
"
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=203404&pg=15#1920645
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=203404&pg=22#1989323


Чернышев Андрей Леонидович
С точки зрения реляционного замыкания он настолько же бессмысленен, насколько Ваш первый результат бессмысленен с практической точки зрения.

А что такое точка зрения реляционного замыкания?

Практический смысл этого результата я объяснил на примере его использования в пработающем приложении. Могу выложить исходник DataWindow, только это бесполезно, Вы все равно не разберетесь, а остальные и так понимают как его можно использовать, особенно те, кто работал в PowerBuilder. Поэтому тут говорить нечего, он имеет практический смысл. Утверждать что он практически бессмыссленный это просто глупость.


Чернышев Андрей Леонидович
А я знаю, что "засады нет", U-gene. Вы просто {2.3.5.1.4} упорядочили, получив {1,2,3,4,5}. Все нормально. Еще раз можно "лабораторку" провести. Результат будет таким же.

ЧАЛ, ну как Вам не стыдно. Объясняют вам, объясняют, раз десять уже наверное повторили а Вы все понять не можете совершенно элементарную вещь, которую учили даже не в институте, ее учили в седьмом классе средней школы. Множество {1,2,3,4,5} НЕ ЯВЛЯЕТСЯ УПОРЯДОЧЕННОЙ ВЕРСИЕЙ МНОЖЕСТВА {2,3,5,1,4}. Они ВООБЩЕ НИЧЕМ не отличаются. Об этом говорит Дейт в той цитате, которую Вы много раз скоприровали в топике "Re: РМД пора на пенсию?", но так и не поняли:
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=203404&pg=16#1930358
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=203404&pg=16#1930964

Дейт же Вам в этой цитате по-русски объяснил: "... не существует такого понятия, как "первый кортеж", "пятый кортеж" или "97-ой кортеж" отношения, кроме того, не существует такого понятия, как "следующий кортеж"; иными словами, в отношениях не определена позиционная адресация и нет понятия "следования"". Отношение это множество, а кортеж это элемент множества, если Вы вдруг не знаете. А Вы несете чушь о том, что "Вы просто {2.3.5.1.4} упорядочили, получив {1,2,3,4,5}" и при этом еще утверждаете, что Вы понимаете Дейта и РМД, а остальные присутсвующие этого не понимают.
2 фев 06, 02:09    [2311698]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2406
Блог
Чернышев Андрей Леонидович
Я же сказал "делают", а не "возвращают". Я понимаю, что Вам не интересно что там делает СУБД (оптимизатор). Я мне это интересно.
О! Я ждал, когда Вы таки заговорите об оптимизаторе! Давайте действительно посмотрим как СУБД будет выполнять эти два запроса. Вы, вероятно, считаете, что всякий раз для подсчёта суммы веса людей система будет сперва выбирать всех подходящих? Отнюдь. Чтобы продемонстрировать это, я попробую смоделировать некоторую гипотетическую ситуацию. Давайте предположим, что в таблице man порядка ста тысяч записей, более половины из них имеют вес бОльший 100 (это информация о борцах сумо) и в базе есть индекс по полю weight таблицы man. Тогда в случае выборки списка СУБД скорей всего предпочтёт полное сканирование таблицы, а в случае подсчёта суммарного веса - сканирование индекса и только индекса, блоки данных таблицы не будут затронуты вовсе. Так что Ваше заявление о том, что оба запроса будут делать "одно и то же" мягко говоря не соответствует действительности.
Чернышев Андрей Леонидович
Могу напомнить пример, который уже "разбирали" в одной из тем. Система продажи билетов (например, железнодорожных) "продает" билет быстро, за ожидаемое в "цивилизованном мире" время, например, 5 секунд. Удалим некий индекс. Билет стал продаваться за 10 минут. Я утверждаю, что система перестала работать в принципе, а Вы, видимо, скажете, что она работает (просто медленнее). Видите какие у нас прямо противоположные точки зрения (конечно, если я угадал Вашу точку зрения).
Увы, Ваши телепатические способности Вас на этот раз подвели. Я тоже скажу, что система перестала работать, поскольку не отвечает требованиям заказчика.
Чернышев Андрей Леонидович
А теперь удалим еще и отношение из БД, и билет вообще перестанет продаваться. И некоторые участники "спора", надеюсь, поймут, что программы в "Р"СУБД не отделены от данных, как они утверждали.
Ну да. Ещё можно перерубить провод топором и поджечь сервер, облив его предварительно бензином. Тоже помогает понять, насколько мы, грешные, к железу привязаны.
Чернышев Андрей Леонидович
Ответа на два вопроса будет два. Я никогда не говорил, что один. Я только говорил, что в моем примере один "вопрос", и четко показал, что я (пользователь) хотел получить. Генератор запросов и отчетов любого объектного навигатора именно это и предъявит пользователю. Это же очевидно.
То есть Вы тоже утверждаете, что Ваш ответ годится только для отчётов? Зачем же Вы меня в этом упрекали?

Всё же ещё раз второй мой вопрос. Внимательно пожалуйста, сосредоточьтесь и попробуйте ответить:
-- Что вернёт Ваша система в ответ на такой Ваш "один вопрос". Попытайтесь описать что оно такое будет пожалуйста. Меня интересует не то, что увидит конечный пользователь, а как оно представлено внутри. Вы же утверждали яростно, что люой ответ должен соответствовать схеме БД. Вот и давайте сюда эту схему. С суммарным весом.
2 фев 06, 07:14    [2311781]     Ответить | Цитировать Сообщить модератору
 Re: SQL, есть ли выход из СКорЛупы?  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2406
Блог
Чернышев Андрей Леонидович
Козел.
Ну зачем Вы так в самом деле! Со всеми случается.
2 фев 06, 07:39    [2311799]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 20 21 22 23 24 [25] 26 27 28 29 .. 39   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить