Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8   вперед  Ctrl      все
 Re: О временных таблицах замолвите слово...  [new]
Dik76
Member

Откуда: Казань
Сообщений: 1517
dimitr
Dik76
Если это будет в FB 2.0, то просто интересно :)


Не надо делать из FB2 всеобщего счастья. Что будет - то будет, остальное - потом. Мне до пенсии еще далеко ;-)
Да мне собственно TT и не нужны, мне ХП хватает
28 дек 04, 12:29    [1214427]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
andy st
Member

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

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

идея та.
но сложности ни какой не наблюдается. серверу один раз сказали размер окна для разделения диапазонов, а остальное делает он сам. в т.ч. и выделение нового при превышении существующего.
работает неплохо, и сразу видно, с какой базы ноги у записей растут.
28 дек 04, 12:34    [1214460]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
andy st
работает неплохо, и сразу видно, с какой базы ноги у записей растут.

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

Можете на примере - может быть, я неправильно Вас понял?
28 дек 04, 14:04    [1214988]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
когда говорят что реплякация работает хорошо по с ключом по диапазонам - это значит врут. Врут и не краснеют. Работа с диапазонами записей никогда не была удобна. Составной ключ - так или иначе все к нему приходят или начинают эмулировать. Именно отсутствие секвенсов приводит к этому геморрою.
28 дек 04, 14:19    [1215058]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
andy st
Member

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

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

несколько серверов...
несколько рабочих мест...
один публикатор, остальные подписчики, репликация транзакциями.
результат действий оператора пишется в таблицу событий (запись = поля описания события + поля с identity). рабочее место может прицепиться к любому из серверов.
для каждого сервера задан свой диапазон identity для этой таблицы.
т.е. на подписчике 1 - 999999, на втором сервере 1000000 - 1999999 и т.п.
(т.е. так определяются "откуда растут ноги у записей").
никаких заморчек со стороны клиента - просто insert в таблицу на нужном сервера - запись придет ко всем с identity из дапазона сервера.
на сервере - при создании репликации 1 раз был указан размер диапазона и % его заполнения для выделения нового диапазона.
собственно ВСЕ.
по поводу надолго отрезан - прецедентов пока не было. но диапазон выбирался из расчета работы диапазона примерно года на 3-4. за такое время линию связи уж точно восстановят. ;)
28 дек 04, 14:25    [1215088]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
andy st
Member

Откуда:
Сообщений: 899
gardenman
когда говорят что реплякация работает хорошо по с ключом по диапазонам - это значит врут. Врут и не краснеют. Работа с диапазонами записей никогда не была удобна. Составной ключ - так или иначе все к нему приходят или начинают эмулировать. Именно отсутствие секвенсов приводит к этому геморрою.

если у кого-то она работает хорошо, а у кого-то плохо, то стоит задуматься:либо первые врут, либо у вторых кривые руки или кривой софт.
первое (я вру) исключается ввиду того, что я наблюдаю работающую без вмешательства систему.
на счет второго выбирайте сами ;)
28 дек 04, 14:34    [1215137]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
ChA
Member

Откуда: Москва
Сообщений: 11381
softwarer
пока не пойдет вопрос переполнения :)
Хммм... Переполнение при 264 ? Теоретически - да, а если реально смотреть на жизнь ?
softwarer
А прокомментируете то, что я уже упоминал - если я правильно понимаю, такие манипуляции на триггерах связаны с необходимостью второй раз update-ить ту же запись (и соответственно с дополнительной нагрузкой)
Нет, контекст потерял :) По поводу обновления, не нужно оно на практике, так как запоминать первоначальное значение timestamp при вставке бессмысленно. Суть timestamp не в том, чтобы дать уникальный идентификатор в пределах БД, а в указании последовательности операций модификации данных, что и может применяться при некоторых видах репликации.
softwarer
Вы другими словами сказали то же самое - вводить искусственную таблицу с identity
Здесь не могу с Вами согласится, не таблица это искуственная, а решение, при котором разные таблицы пользуют один SEQUENCE. Смысл в чем ? Если это разные сущности, то зачем они разделяют одну и ту же последовательность ? Пусть каждая имеет свою. Если же сущность одна, но с подтипами(подкатегориями), то она должна иметь свою таблицу, чтобы подчиненные таблицы могли использовать ссылочное ограничение. На примере Ю и Ф лиц: если по бизнес-логике в БД может существовать таблица, в которой определенное поле может ссылатся на обе таблицы, то сделать ссылочное ограничение на обе таблицы одновременно все равно нельзя, так зачем огород в виде разделяемой последовательности городить ? Чтобы отлавливать кодом эту ссылочную целостность ? Конечно, можно идти и таким путем, но, IMHO, это потеря "прозрачности", связи подобного рода между данными должны быть прописаны явно, а не хранится где-то в дебрях кода.
softwarer
Вы просто подгоняете требования к тому, что есть в MSSQL
Никак нет, насколько помню для каких-то видов репликации, кажется MERGE, именно это и нужно, но так как не использую, то не готов защищать эту точку зрения.

P.S. Не пытаюсь защитить MS SQL или противопоставить его Oracle, все что хотелось бы сказать: одни и те же задачи можно решать разными способами, и сравнение в однозначное превосходство одного из них далеко не всегда оправдано.
28 дек 04, 14:47    [1215206]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
есть консолидированная база, где у каждого филиала - свой диапазон.
Попробуйте-ка баланс представить в разрезе филиалов, или баланс по нескольким. А если таких отчетов несколько? И потом с этим мудохаться все время пока живет система? В гробу я видел такое проектирование...(((
28 дек 04, 14:47    [1215210]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
а добавление нового филиала? выделение нового диапазона?... и не лень вам?
28 дек 04, 14:50    [1215224]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
вообще, когда 1 поле содержит информацию по 2 понятиям (код филиала, + код документа), дорогие мои, это пахнет нарушением 1НФ!
28 дек 04, 14:54    [1215247]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
andy st
один публикатор, остальные подписчики,

Честно говоря, уже неинтересно :)

andy st
для каждого сервера задан свой диапазон identity для этой таблицы.
т.е. на подписчике 1 - 999999, на втором сервере 1000000 - 1999999 и т.п.
(т.е. так определяются "откуда растут ноги у записей").

И? Как только автоматически выделится следующий диапазон - откуда Вы узнаете, какому серверу он принадлежит? Или будете помнить, что "первый миллион - первый сервер, второй - второй, третий миллион - снова второй, четвертый миллион - первый, пятый миллион - третий..." И так, я полагаю, помнить по каждой таблице? У меня их, знаете ли, реплицировалось порядка тысячи двухсот; память кончится.

andy st

по поводу надолго отрезан - прецедентов пока не было. но диапазон выбирался из расчета работы диапазона примерно года на 3-4. за такое время линию связи уж точно восстановят. ;)

Хм. Знаете, возможности сервера на таких объемах как-то неловко обсуждать :) Полагаю, с миллионом записей за три-четыре года и парадокс справится без особых проблем.

А вот через четыре года - давайте Вы нам расскажете, так ли удобно определять, "откуда ноги растут".
28 дек 04, 14:57    [1215263]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
andy st
Member

Откуда:
Сообщений: 899
gardenman
есть консолидированная база, где у каждого филиала - свой диапазон.
Попробуйте-ка баланс представить в разрезе филиалов, или баланс по нескольким. А если таких отчетов несколько? И потом с этим мудохаться все время пока живет система? В гробу я видел такое проектирование...(((

конкретно в чем проблема.
баланс составится в разрезе и филиалов и отделов филиалов. диапазоны тут причем?
28 дек 04, 14:59    [1215267]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
andy st
Member

Откуда:
Сообщений: 899
gardenman
а добавление нового филиала? выделение нового диапазона?... и не лень вам?

дык публикатор сам и даст ему диапазон. мое участие - только добавить подписчика. а уж без этого ну никак нового филиала не добавить... ;)
28 дек 04, 15:01    [1215277]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
andy st
Member

Откуда:
Сообщений: 899
gardenman
вообще, когда 1 поле содержит информацию по 2 понятиям (код филиала, + код документа), дорогие мои, это пахнет нарушением 1НФ!

и что дальше?
пойдем спорить по поводу целесообразности того, надо ли всегда придерживаться 1НФ или нет?
28 дек 04, 15:03    [1215289]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
ага, и еще нужно будет подправить десяток-другой отчетов, или написать функцию, которая бы делала из id-поля номер филиала, и сделать чтобы это все работало быстро.... У меня как-то заниматься этими глупостями нет особого желания.
28 дек 04, 15:03    [1215291]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
andy st
Member

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

И? Как только автоматически выделится следующий диапазон - откуда Вы узнаете, какому серверу он принадлежит? Или будете помнить, что "первый миллион - первый сервер, второй - второй, третий миллион - снова второй, четвертый миллион - первый, пятый миллион - третий..." И так, я полагаю, помнить по каждой таблице? У меня их, знаете ли, реплицировалось порядка тысячи двухсот; память кончится.

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

Хм. Знаете, возможности сервера на таких объемах как-то неловко обсуждать :) Полагаю, с миллионом записей за три-четыре года и парадокс справится без особых проблем.

;) давайте еще пиписьками померяемся.
я же не сказал, какие размеры остальных таблиц, а уже такие предположения стоятся... обалдеть, фантазеры...
28 дек 04, 15:13    [1215333]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
andy st
Member

Откуда:
Сообщений: 899
gardenman
ага, и еще нужно будет подправить десяток-другой отчетов, или написать функцию, которая бы делала из id-поля номер филиала, и сделать чтобы это все работало быстро.... У меня как-то заниматься этими глупостями нет особого желания.

зачем делать из id номер филиала?
сами себе проблему придумали, сами отказываемся ее решать... просто зашибись...
28 дек 04, 15:15    [1215340]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
ChA
softwarer
пока не пойдет вопрос переполнения :)
Хммм... Переполнение при 264 ? Теоретически - да, а если реально смотреть на жизнь ?

Там не зря стоит смайлик. Но если учесть, что у меня ожидаемый прирост базы порядка 2^32 записей в год - для "пересчета по каждому чиху" число не кажется таким уж фантастическим.

ChA
По поводу обновления, не нужно оно на практике, так как запоминать первоначальное значение timestamp при вставке бессмысленно. Суть timestamp не в том, чтобы дать уникальный идентификатор в пределах БД, а в указании последовательности операций модификации данных, что и может применяться при некоторых видах репликации.

Стоп. Я понимаю этот вариант, но говорю о другом. С моей точки зрения, крайней удобно делать id записи "подходящим для репликации". Подобный timestamp - если его можно накрутить до нужного старта - подошел бы для этого (для небольших/прогнозируемых баз). Без этого же - это просто данные, которые вряд ли могут понадобиться иначе чем в целях администрирования.

ChA
Смысл в чем ? Если это разные сущности, то зачем они разделяют одну и ту же последовательность ? Пусть каждая имеет свою.

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

ChA
На примере Ю и Ф лиц: если по бизнес-логике в БД может существовать таблица, в которой определенное поле может ссылатся на обе таблицы, то сделать ссылочное ограничение на обе таблицы одновременно все равно нельзя, так зачем огород в виде разделяемой последовательности городить ?

Огород в виде разделяемой последовательности позволяет не делать поля наподобие "тип записи, на которую ссылается данное поле". Пример звучал здесь же совсем недавно - CONTRACTORS JOIN PHPERSONS дает всех контрагентов-физиков, CONTRACTORS JOIN ORGS дает всех контрагентов-юриков.

Лично мне такой подход не нравится. Но он существует, достаточно часто упоминается и, собственно, при многочисленных категориях адресатов становится менее невыгодным, чем другие варианты.

ChA

softwarer
Вы просто подгоняете требования к тому, что есть в MSSQL
Никак нет, насколько помню для каких-то видов репликации, кажется MERGE, именно это и нужно, но так как не использую, то не готов защищать эту точку зрения.

Сказать по правде, я не знаю, что такое MERGE репликация, но почти уверен, что это термин откуда-то из MSSQL. Во всяком случае, адекватная репликация спокойно делается при куда более слабых требованиях.

ChA

P.S. Не пытаюсь защитить MS SQL или противопоставить его Oracle, все что хотелось бы сказать: одни и те же задачи можно решать разными способами, и сравнение в однозначное превосходство одного из них далеко не всегда оправдано.

Можно решать разными способами. Если Вы посмотрите подборку моих писем - я не склонен кричать "лучше всегда и везде". Собственно, когда мне говорят "а вот здесь не лучше" - я даже чаще верю на слово, нежели лезу проверять.

Что касается секвенсоров - они с одной стороны не имеют явных собственных недостатков, а с другой позволяют "одним движением" решить задачи, каждую из которых можно решать большими или меньшими усилиями "другими методами". То есть: да, можно раздать диапазоны. И на небольших базах это сработает. Да, можно не забыть при создании каждого поля добавлять "not for replication" - хотя это уже плохое, неудобное требование. Можно сделать GUID и плевать на его большой размер. Но вопрос: зачем? То, что позволяет одной строкой обойтись без всего этого, по-моему, таки "лучше".
28 дек 04, 15:18    [1215360]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
andy st
а я помнить и не буду. мне это надо, чтобы в реальном времени разруливать проблемы, не более.

Допустим - хотя уже весьма сомнительно. Итак, для скольких таблиц и скольких серверов Вы обещаете помнить текущие диапазоны?

andy st
;) давайте еще пиписьками померяемся.

Зачем? Вы сначала сказали - у Вас работает, а потом оказывается, что работает в совершенно нерепрезентативных условиях. То есть - я совершенно уверен, что MSSQL способен на куда большее.

Соответственно, Ваше утверждение становится примерно таким: MSSQL крут, поскольку приемлимо решает копеечную задачу. Лично у меня о нем лучшее мнение.
28 дек 04, 15:21    [1215372]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
ChA
Member

Откуда: Москва
Сообщений: 11381
softwarer
Там не зря стоит смайлик. Но если учесть, что у меня ожидаемый прирост базы порядка 2^32 записей в год - для "пересчета по каждому чиху" число не кажется таким уж фантастическим.
Смайлик может иметь совершенно разный смысл, который не всегда понятен из контекста, от "уничтожающего" сарказма до извинительной улыбки ;) Да, пожалуй на 232лет может и не хватить :)
softwarer
Смысл в том, что последовательности могут применяться не только для суррогатных ключей, но и для нумерации документов. И бухгалтер вполне может сказать - и говорит на практике - "хочу, чтобы все типы накладных имели сквозную нумерацию".
Не надо говорить о том, кто и чего захочет и к этому приплетать метод решения гипотетических проблем. Схема БД строится не исходя из пожеланий левой ноги бухгалтера, а из анализа сущностей предметной области и связей между ними. Если нужна сквозная нумерация документов, то это значит, что эти документы представляют собой одну и ту же сущность, но с подтипами, а значит у них должна быть master-таблица. Можно захотеть сделать сквозную нумерациую и через все документы, если таковы исходные требования, но это значит, что все документы воспринимаются как экземпляры одной и той же сущности, или класса, если угодно. В таковом случае, в master-таблице будут "жить" те свойства документов, которые присутствуют и имеют один и тот же смысл для всех документов.
Вопрос в правильном подходе к проектированию БД, а не "склеивании" разнородных сущностей путем использования последовательностей. Полагаю, что это тоже очевидно :)
softwarer
Лично мне такой подход не нравится.
И совершенно правильно не нравится, так как в некотором смысле это тоже нарушение 1НФ, когда в значении идентификатора "незримо" присутствует тип записи. Возможно, страдаю идеализмом, но, IMHO, проектирование БД определяется не "выгодностью" того или иного конкретного решения, а большим или меньшим соответствием реляционной модели данных.
автор
Что касается секвенсоров - они с одной стороны не имеют явных собственных недостатков, а с другой позволяют "одним движением" решить задачи, каждую из которых можно решать большими или меньшими усилиями "другими методами".
И снова соглашусь с Вами, больше методов, хороших и разных :) Но только они должны быть оправданы спецификой задач, а не потому, что проектирование сделано из рук вон...
28 дек 04, 16:19    [1215712]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
andy st
Member

Откуда:
Сообщений: 899
softwarer
andy st
а я помнить и не буду. мне это надо, чтобы в реальном времени разруливать проблемы, не более.

Допустим - хотя уже весьма сомнительно. Итак, для скольких таблиц и скольких серверов Вы обещаете помнить текущие диапазоны?

есть такая фича в mssql, как
dbcc checkident (tablename)
, которая освобождает от этой обязанности.
;)
softwarer
andy st
;) давайте еще пиписьками померяемся.

Зачем? Вы сначала сказали - у Вас работает, а потом оказывается, что работает в совершенно нерепрезентативных условиях. То есть - я совершенно уверен, что MSSQL способен на куда большее.

я прекрасно знаю, что mssql способен на горазо большее - крутятся задачки и
посерьезнее (с точки зрения логики, объемов данных, кол-ва пользователей).
но в описанном мной примере того, что сделано хватает за глаза.
softwarer

Соответственно, Ваше утверждение становится примерно таким: MSSQL крут, поскольку приемлимо решает копеечную задачу. Лично у меня о нем лучшее мнение.

ну епрст... а чем определяется "копеечность" задачи?
для меня, например, на первом месте идет логика системы, а не ее размеры (в некоторых случаях юзаем многогигабайтовые базы с видеорядом, на крайняк я в базу могу десяток-другой iso-шек залить для объема).
количество таблиц тоже не всегда показатель (сделать сотню join совершенно не в напряг). если у вас на первом месте объемы - стоит еще поработать.... через годик-два посмотрим...
29 дек 04, 06:08    [1216787]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Yo!!
Guest
слушайте тут соседи рассказали о странных тормозах mssql и каких-то системных блокировках ... решили вместе поискать что это могло бы быть
и нашли:

http://www.sql-server-performance.com/temp_tables.asp

SQL Server Temp Table Performance Tuning Tips

Generally speaking, temp tables should be avoided, if possible. They are created in the tempdb database and create additional overhead for SQL Server, slowing overall performance. As an alternative to temp tables, consider the following alternatives:

* Rewrite your code so that the action you need completed can be done using a standard query or stored procedure, without using a temp table.


а ведь меня почти залечили, что #tmp удобней :)
13 апр 05, 17:16    [1465796]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Александр Гoлдун
Member

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

Yo!! пишет:

> слушайте тут соседи рассказали о странных тормозах mssql и каких-то
> системных блокировках ... решили вместе поискать что это могло бы быть
> и нашли:
(пропущено)
> а ведь меня почти залечили, что #tmp удобней :)

Это проблемы MSSQL, а не временных таблиц вообще.

Posted via ActualForum NNTP Server 1.1

13 апр 05, 17:23    [1465812]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Yo!!
Guest
>Это проблемы MSSQL, а не временных таблиц вообще.

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

а у ASA/ASE таких проблем нет ?
13 апр 05, 17:38    [1465886]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Александр Гoлдун
Member

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

Yo!! пишет:
>>Это проблемы MSSQL, а не временных таблиц вообще.
>
> не ну понятно что проблемы сиквела, причем я не понимаю зачем что-то
> курочить в системных таблицах если видеть надо в предимость одной сесии.
>
> а у ASA/ASE таких проблем нет ?

На счет ASE не в курсе. А вот в ASA временные таблицы - очень мощный и
удобный инструмент, проблем по скорости не встречал и уж тем более
рекомендаций неиспользования.

Posted via ActualForum NNTP Server 1.1

13 апр 05, 18:02    [1466019]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить