Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
 Re: Высоконагруженные проекты и запросы  [new]
ЛП
Guest
2 сосед-акцесник
Чуется мне, что через какое-то время, совершив соотвествующую петлю, завершится это тем, что в современных терминах могло бы быть названо монолитным решением.
Будет эта какая-нибудь экзадата шрих энного поколения или диби-два-в-ионосфере - поживем увидим.

мс акссес ебай эдишн
:)
10 янв 10, 04:04    [8161189]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
сосед-акцессник
Guest
ЛП
...мс акссес ебай эдишн
:)

толково.
:)
10 янв 10, 04:17    [8161195]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Психиатр
Guest
Правда интересно разговаривать сам с собой? Клинический случай - заявляю авторитетно
10 янв 10, 04:24    [8161197]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
сосед-акцессник
Guest
Психиатр
Правда интересно разговаривать сам с собой? Клинический случай - заявляю авторитетно

Ну да. Вот так и живу. Ведь разговаривать мне больше и не с кем.
https://www.youtube.com/watch?v=ENApxvijIio&feature=related
10 янв 10, 05:11    [8161213]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Павел-П
Guest
Как я понимаю в высоконагруженных проектах встречаются и проблемы с БД.
Например: deadlock-и, блокировки одних запросов другими и т.д.

1. Такие вещи гораздо легче решаются когда доступ к БД осуществляется через слой хранимых процедур. Другое дело, что на разработку/поддержку этого слоя приходится тратить уйму времени.
2. Решать же подобные проблемы при доступе к БД напрямую из приложения не очень легко. Каждый пишет что хочет и где хочет. Определить какие действия приложения вызвали deadlock, блокировку требует больших усилий.
10 янв 10, 14:25    [8161715]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
сосед-акцессник
Guest
Павел-П
Как я понимаю в высоконагруженных проектах встречаются и проблемы с БД.
Например: deadlock-и, блокировки одних запросов другими и т.д.

1. Такие вещи гораздо легче решаются когда доступ к БД осуществляется через слой хранимых процедур. Другое дело, что на разработку/поддержку этого слоя приходится тратить уйму времени.
2. Решать же подобные проблемы при доступе к БД напрямую из приложения не очень легко. Каждый пишет что хочет и где хочет. Определить какие действия приложения вызвали deadlock, блокировку требует больших усилий.


И вновь прошу прощения.
как акцессник вам говорю - вы демонизируете роль "хранимых процедур".

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

К нагруженности системы это прямого (вообще никакого) отношения не имеет.
Как и к возможности реализации такого именно как вы сказали - слоя как части ядра системы управления набором (классом) заранее известных прикладных задач - с помощью кода, находящегося технически вне СУБД. В том числе, в виде набора библиотек/сервисов написанных и на java, исполняемого (в том числе) на серверах приложений.

Вопрос управляемости кода, содержащегося в таком слое более-менее вменяемо решается и когда он целиком реализован в СУБД в виде хранимых процедур и когда он целиком реализован вне СУБД.

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

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

PS
Сегодня обнаружил, что практически та же по содержанию тема одномоментно обсуждается в
форуме "Разработка информационных систем".
Занятно.
11 янв 10, 00:32    [8163091]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
DPH3
Guest

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

Э, а как это слой хранимых процедур облегчает решение проблем с дедлоками? Каким способом?


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

Э, команды, в который все настолько плохо - очень редко делают высоконагруженные системы. А еще реже - доводят до конца. И хранимые процедуры не спасут, тут проблема в головах :)
11 янв 10, 00:40    [8163104]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Павел-П
Guest
DPH3,

Я не являюсь сторонником ни первого, ни второго варианта.

1. Э, а как это слой хранимых процедур облегчает решение проблем с дедлоками? Каким способом?

Да очень просто. Помогает быстрее найти причину и устранить. Предположим вы поддерживаете неизвестное вам приложение и получаете информацию о том, что у вас происходит deadlock. В случае с хранимыми процедурами вы четко видите на уровне базы данных, что вызывались такие-то процедуры и ...
В противном случае Вы просто увидите несколько запросов, сгенерированных LINQ(или чем-нибудь еще) и далее еще будете тратить огромное количество времени для того, чтобы выяснить из какого места приложения пришли эти запросы и т.д.
Попробуйте сами для себя составить алгоритм решения проблемы в первом и втором случае. И увидите, что реально помогает.

2. Э, команды, в который все настолько плохо - очень редко делают высоконагруженные системы. А еще реже - доводят до конца. И хранимые процедуры не спасут, тут проблема в головах :)

Для того, чтобы возник deadlock достаточно наличия и хороших команд. Нужно лишь в транзакции нарушить последовательность обхода таблиц и немного нагрузить систему. Вот он и появился.
11 янв 10, 01:20    [8163145]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
DPH3
Guest
Павел-П
DPH3,
Я не являюсь сторонником ни первого, ни второго варианта.

А какого?



Да очень просто. Помогает быстрее найти причину и устранить. Предположим вы поддерживаете неизвестное вам приложение и получаете информацию о том, что у вас происходит deadlock...

Ну да. После этого смотрю в логи application layer, вижу exception и стек вызовов и сразу понимаю, в рамках какой бизнес-операции, для каких объектов, в какой строчке кода я получил проблему (а если система написана хоть чуть-чуть с мозгами - то и кучу дополнительной отладочной информации). И зачем мне тут хранимки?
Linq2sql и прочие ORMы лучше вообще не рассматривать, у них вполне конкретная сфера применения, к нагруженным системам отношения не имеющая.


Для того, чтобы возник deadlock достаточно наличия и хороших команд.

Я, вообще, комментировал фразу "Каждый пишет что хочет и где хочет. Определить какие действия приложения вызвали deadlock, блокировку требует больших усилий". Указанное однозначно говорит об отвратительном подходе к разработке, близком к полному непрофессионализму.


Нужно лишь в транзакции нарушить последовательность обхода таблиц и немного нагрузить систему. Вот он и появился.

Обычно deadlock - это проблема в проектировании, связанная с неправильно осознанной бизнес-логикой. Последовательность обхода таблиц - это так, технические симптомы. Т.е. дедлоки - это ошибка проектирования, а не кодирования :) Впрочем, к хранимым процедурам это отношения не имеет, точно так же можно вызвать не в том порядке хранимки.
11 янв 10, 01:47    [8163165]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Yo.!
Guest
сосед-акцессник

Вопрос управляемости кода, содержащегося в таком слое более-менее вменяемо решается и когда он целиком реализован в СУБД в виде хранимых процедур и когда он целиком реализован вне СУБД.

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

ЗЫ. искренне порадовался за бесценных pl/sql программеров, которых уже почти нет и потому у них почти не стоит. я ваш пассаж верно понял ?
11 янв 10, 01:58    [8163170]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Павел-П
Guest
DPH3,

Прикол deadlock-ов и блокировок именно в том, что здесь участие принимают две сессии.
Для deadlock-а в application trace file вы увидите только что какой-то кусок функциональности был выбран жертвой deadlock-а и был убит. О втором куске функционала вы не узнаете ничего (разве что номер сессии). Только граф deadlock-а вам поможет. А в нем вы увидите информацию на уровне движка БД, т.е. sql запросы. Вот и догадывайтесь откуда взялся второй запрос из application layer.
11 янв 10, 02:29    [8163187]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
DPH3
Guest
Yo.!

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

Да любой :) Тесты на весь DL, как обязательная часть тестирования версии никем не отменялись.
А если DBA меняет DDL вне рамок процедуры подготовки версии (с документированием, тестированием, инструкцией по развертыванию и т.п.), то это означает отсутствие процесса разработки в компании (или его несоблюдение отдельным DBA). Если результат таких патчей привел к каким-либо проблемам на продакшне - то минимум одно увольнение необходимо (DBA или управленца - зависит от компании).

А вообще, контроль целостности кода и контроль зависимостей в современных языках с статической типизацией и средствами контроля и поиска возможных ошибок (я про всяческие findbug) на порядок совершеннее такого даже в лучших sql-like языках. Другое дело, что автоматической связи его с реальной структурой БД я не видел (кстати, сделать - не очень сложно), эти проблемы решаются административными методами. Впрочем, все проблемы с соблюдением интерфейсов между модулями решаются административными методами, так что порядок все равно нужен, систем, состоящих только из БД уже не встречается.
11 янв 10, 02:31    [8163191]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Павел-П
Guest
DPH3,

"Я не являюсь сторонником ни первого, ни второго варианта.

А какого?"

Любой разработчик БД (который отвечает за БД) (+ администратор БД) в данном случае будет ратовать за наличие слоя хранимых процедур. Это и понятно, ведь это позволяет контролировать то что происходит в БД на уровне БД. И вы четко знаете, что доступ к БД будет осуществляться на уровне выставленных интерфейсов и никак подругому.
Расматривайте хранимые процедуры просто как интерфейс между БД и следующим уровнем (приложением). При этом хранимые процедуры никогда не уступят в производительности запросам, генерируемым из приложения. На то они и хранимые процедуры.

Другое дело, что данный подход требует больших трудозатрат. Ведь слой хранимых процедур надо создать и поддерживать. А это не просто. Вот и приходится людям искать компромис.
11 янв 10, 02:41    [8163201]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Павел-П
Guest
DPH3,

Если бы все проблемы в жизни решались только административными мерами - то все приложения работали без ошибок и как надо. Написал бумажку "Приложения должны работать правильно" - и все. :-)
11 янв 10, 02:49    [8163207]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
DPH3
Guest
Павел-П
DPH3,
Если бы все проблемы в жизни решались только административными мерами - то все приложения работали без ошибок и как надо.
:-)

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

Кстати, тут уже указывали, что в среднем уровень развитости методологии разработки для БД ниже, нежели для application layer. Чисто исторически, увы.
11 янв 10, 03:02    [8163210]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
ЛП
Guest
Yo.!
интересно, что за язык вне субд сможет выдать аналог %rowtype или отследить какие куски кода перестали работать

чудо
просто чудо
это ж блин невзъебически сложная задача, отследить какие куски кода перестали работать
ни джаве, ни шарпу, никому с таким не сдюжить.
да и вообще никакому языку вне субд
11 янв 10, 03:20    [8163223]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
сосед-акцессник
Guest
Yo.!

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

ЗЫ. искренне порадовался за бесценных pl/sql программеров, которых уже почти нет и потому у них почти не стоит. я ваш пассаж верно понял ?

1) я недостаточно образован в pl\sql, для того, чтобы сообразить, в каких обстоятельствах может иметь значение %rowtype.
Отвечу вам так:
добавление поля администратором никакой фактически написанный код не заметит - ни использующий %rowtype, ни обошедшийся без него. Если только не делается технических ошибок вида
Select * Into userDefined_no_rowtype_RecodType From youTable
(что не во всех обстоятельствах даже может быть за ошибку принято)

А вот удаление (или переименование) поля заметит любой код ( как использующий %rowtype, так и нет), фактически обращяющийся к этому коду. Нет разницы

Select * into rowTypedVariable From Table

IF rowTypedVariable.DeletedField IS NULL THEN
  DoManyCrazyWork;
END IF;

или

Select DeletedField Into ValueForDeletedField From Table
IF ValueForDeletedField THEN
  DoManyCrazyWork;
END IF;
для развала pl/sql-кода в случае удаления поля.
Т.е., с точки зрения необразованного акцессника - %rowtype - сам по себе - почти целиком мимо кассы в качестве страховочного механизма.

Что касается компиляции хранимого в субд серверного кода как инструмента, удостоверяющего, что "система поднимется" - да, такую роль компиляция серверного кода играет.
(Я так понимаю, что случай динамического исполнения pl/sql-кода мы не рассматриваем)

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

(правильная работа системы в любом случае не обещана. )

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

А в том, где проходят "границы системы" и как она развивается.
Хаотического развития одинаково успешно можно достичь при любом подходе.

В обсуждаемом случае (ebay) границы системы точно расположены вне субд, т.к. база данных носит осколочный характер и поддержка ее целостности вынесена за пределы средств используемой субд.
Безусловно, это увелививает уровень сложности всей системы в целом.
Самым же суещственным является то, что после выноса кода хранимых процедур ( там, где они играли роль костяка системы, остова, задающего способ обращения с системой - прикладного интерфейса) наружу, роль такого кода не меняется.
Он как был частью "ядра системы", так и остался. Изменилась не логика, а "распределение" системы и способ обращения с/к ней прикладного кода.

Особенности физиологии программистов pl/sql - вам, вероятно, должны быть виднее.
11 янв 10, 03:24    [8163227]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
ЛП
Guest
2 Павел-П
Любой разработчик БД (который отвечает за БД) (+ администратор БД) в данном случае будет ратовать за наличие слоя хранимых процедур.

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

Это и понятно, ведь это позволяет контролировать то что происходит в БД на уровне БД.

Вот это самое "контролировать то что происходит в БД на уровне БД" - имеет какую-то абсолютную ценность?
Почему бы не контролировать то, что происходит в БД, на уровне <некоторомдругом>?

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

И вы четко знаете, что доступ к БД будет осуществляться на уровне выставленных интерфейсов и никак подругому.

И вы чётко знаете, что доступ к БД будет осуществляться например через апп-сервер, и никак по другому.

Расматривайте хранимые процедуры просто как интерфейс между БД и следующим уровнем (приложением).

Рассматривайте например апп-сервер просто как интерфейс между БД и следующим уровнем (приложением).

При этом хранимые процедуры никогда не уступят в производительности запросам, генерируемым из приложения. На то они и хранимые процедуры.

Утверждение неверно.
11 янв 10, 05:31    [8163280]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Павел-П
Guest
ЛП,

Хотелось бы немного аргументов. Слова "утверждение не верно" как-то уж звучат как истина в первой инстанции.
11 янв 10, 10:01    [8163647]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
Павел-П
Хотелось бы немного аргументов. Слова "утверждение не верно" как-то уж звучат как истина в первой инстанции.

аргументов дофига. например, есть набор данных, который надо клиенту видеть в отсортированном виде. есть несколько вариантов

- отсортировать на сервере. но если объем данных большой, то сортировка может быть долгой, и также будет велик объем данных пересылаемых на клиента.

- сортировать мелкими кусками, с фильтрацией. Оптимально, но если клиент делает такие сортировки часто, он "затрахает" сервер

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

то же самое с процедурами. есть разные обработки, одни выгоднее делать на сервере, другие выгоднее на клиенте.

Павел-П
При этом хранимые процедуры никогда не уступят в производительности запросам, генерируемым из приложения

для Interbase/Firebird это справедливо, если сравнивать только скорость выполнения не учитывая то что я сказал выше.
В других серверах Ваше предположение (!) может быть как истинно, так и ложно.
11 янв 10, 10:17    [8163732]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
пгуые123
Guest
Павел-П
ЛП,

Хотелось бы немного аргументов. Слова "утверждение не верно" как-то уж звучат как истина в первой инстанции.
Если в ХП хранится план запроса то со временем без перекомпиляции ХП он может стать неоптимальным
11 янв 10, 10:56    [8163952]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

st_st wrote:
> Сильно ли тормозят хранимые процедуры, по сравнению с обычными запросами
> из web-приложения?

Я бы сказал, что они наоборот, сильно быстрее летают.

Почему ebay отказался от процедур и сложных запросов
> в пользу простых запросов внутри скриптов и обработки данных на
> веб-серверах?

Не знаю. Как минимум для размышлений над этим вопросом требуется
знать СУБД, применяемую там. Хорошо бы ещё и пруфлинк дабы предотвратить
неправильную интерпретацию информации аффтарам.

Получается базы жутко тормозят и гораздо быстрее
> перекинуть данные на web-сервер и обработать, чем предоставить это субд?

Нет, это бредовое заявление. Данные при любом варианте выполнения запроса
никуда не передаются для обработки, обрабатываются запросом только
внутри СУБД, а приложению передаются уже результаты.

Posted via ActualForum NNTP Server 1.4

11 янв 10, 11:08    [8164040]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
ЛП
Guest
Павел-П
ЛП,

Хотелось бы немного аргументов. Слова "утверждение не верно" как-то уж звучат как истина в первой инстанции.

Это Ваше утверждение звучит как истина в первой инстанции.
Моё - истина в последней :)

План выполнения ХП фиксирован. Можно даже предположить, что он является даже оптимальным.
Только вот сегодня он оптимален, а завтра уже нет. Потому что изменились данные, с которыми этой ХП приходится работать.
А если не повезёт, то план выполнения станет неактуальным уже сегодня, потому что изменятся входные параметры процедуры.
И если с устареванием планов выполнения еще можно бороться периодическими перекомпиляциями хранимых процедур, то что делать с зависимостью оптимального плана от входных параметров - в общем случае непонятно.

Так что Ваше "хранимые процедуры никогда не уступят в производительности" с полпинка окажется неверным уже даже на примитивной процедурине типа "select * from таблица where индексированноеполе = параметрхранимки"
И чем дальше в лес, тем толще партизаны.
11 янв 10, 11:16    [8164104]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
ЛП
Павел-П
ЛП,

Хотелось бы немного аргументов. Слова "утверждение не верно" как-то уж звучат как истина в первой инстанции.

Это Ваше утверждение звучит как истина в первой инстанции.
Моё - истина в последней :)

План выполнения ХП фиксирован. Можно даже предположить, что он является даже оптимальным.
Только вот сегодня он оптимален, а завтра уже нет. Потому что изменились данные, с которыми этой ХП приходится работать.
А если не повезёт, то план выполнения станет неактуальным уже сегодня, потому что изменятся входные параметры процедуры.
И если с устареванием планов выполнения еще можно бороться периодическими перекомпиляциями хранимых процедур, то что делать с зависимостью оптимального плана от входных параметров - в общем случае непонятно.

Так что Ваше "хранимые процедуры никогда не уступят в производительности" с полпинка окажется неверным уже даже на примитивной процедурине типа "select * from таблица where индексированноеполе = параметрхранимки"
И чем дальше в лес, тем толще партизаны.

И про какую же базу данных мы сейчас говорим?
11 янв 10, 11:21    [8164140]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
ЛП
Guest
Alexander Ryndin
И про какую же базу данных мы сейчас говорим?

А про какую базу говорил Павел-П, категорично утверждая своё "никогда"?
Если про any, то для опровержения достаточно exists
:)
11 янв 10, 11:30    [8164226]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить