Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 17   вперед  Ctrl
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Нужно рассматривать триггеры в рамках единицы работы... а то как бы чего не вышло...))
26 окт 04, 10:22    [1060294]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
gardenman
Нужно рассматривать триггеры в рамках единицы работы... а то как бы чего не вышло...))

Не очень понял - чего именно может выйти ? Как спроектируете логику триггеров, так они работать и будут :) Однако думаю все могут согласиться, чем больше у разработчика функциональных возможностей, тем больше у него развязаны руки более правильно спроектировать ту или иную логику работы. Соотвествующе чем меньше возможностей, тем больше решения иногда напоминают садо-мазо с тройным сальто через собственную голову и риском потом об этом пожалеть. Естественно в таких случаях лучше искать другие пути решения задачи, чем пытаться навязать продукту сделать то, что он не умеет, не предназначен или делает это не сильно хорошо. Это легко прослеживается при переходе специалистов с одной платформы на другую (и без разницы какую именно - с Access на Delphi, с MSSQL на Oracle, с Delphi на PowerBuilder и т.д.) - частенько они пытаются навязать привычную для них логику изучаемому продукту, для которого она оказывется противопоказанной. Отсюда все и беды и рассуждения, что вот типа MSSQL плох, а Оракл хорош, потому что в Оракле это есть, а там нет и наоборот соотвествующе :)
26 окт 04, 10:35    [1060342]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
вопрос - для чего нужны триггера AFTER? - ответ - основное назначение - изменять производные таблицы. Если делать update миллиона записей, то может либо лог кончиться, либо нарваться на ограничение количества блокировок. Массированные апдейты нужно в любом случае делать пакетами. Быстрее будет и надежнее.
26 окт 04, 10:47    [1060382]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
пардон, не производные, а зависимые...)
26 окт 04, 10:52    [1060398]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
gardenman
Если делать update миллиона записей, то может либо лог кончиться, либо нарваться на ограничение количества блокировок.

Странно. Я как-то делал update двадцати, что ли, миллионов - и ни на что подобное не нарвался ;-)
26 окт 04, 11:09    [1060476]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Если делать update миллиона записей, то может либо лог кончиться, либо нарваться на ограничение количества блокировок.

А вот это от реализации сервера и зависит. Где то можно нарваться на ограничения, а где то нет :)
26 окт 04, 11:16    [1060513]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
ASCRUS
Соотвествующе чем меньше возможностей, тем больше решения иногда напоминают садо-мазо с тройным сальто через собственную голову и риском потом об этом пожалеть.

Трудно с этим не согласиться.

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

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

Так что, к сожалению, простого выхода здесь нет. Приходится помнить, что можешь ошибиться и в том, и в другом случае.
26 окт 04, 11:18    [1060521]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
ASCRUS
автор
Если делать update миллиона записей, то может либо лог кончиться, либо нарваться на ограничение количества блокировок.

А вот это от реализации сервера и зависит. Где то можно нарваться на ограничения, а где то нет :)


Если Update происходит в рамках одной транзакции - запросто - на любом серваке. Если по какой-то причине блокировка на уровне строки или страницы не трансформировалась в блокировку на уровне таблицы - то прийти в итоге к ROLLBACK - элементарно.Особенно когда имеются триггеры. Ведь тогда наверняка блокировки вешаются не на одну таблицу. Эмулировать такое поведение - раз плюнуть. Ну, а нехватка лога - ребята, неужели у вас ни у кого не было log out of space? Не верю... Также не поверю что никогда в жизни при получении декартова произведения в криво написанном запросе вы в tempdb не получали out of space.
26 окт 04, 11:28    [1060570]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
ASCRUS наверно намекал на то, что в ASA и MSSQL лог может расти автоматически. Но ведь все равно диск когда-нить кончится.
26 окт 04, 11:30    [1060575]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
gardenman
Если Update происходит в рамках одной транзакции - запросто - на любом серваке. Если по какой-то причине блокировка на уровне строки или страницы не трансформировалась в блокировку на уровне таблицы

(голосом Вероники Маврикиевны) Не все йогурты одинаково полезны.

Лично мне придется очень долго ждать "трансформации" блокировки строки в блокировку таблицы - думаю, помру раньше. А блокировок на уровне страницы вообще не существует.
26 окт 04, 11:35    [1060604]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
softwarer
gardenman
Если Update происходит в рамках одной транзакции - запросто - на любом серваке. Если по какой-то причине блокировка на уровне строки или страницы не трансформировалась в блокировку на уровне таблицы

(голосом Вероники Маврикиевны) Не все йогурты одинаково полезны.

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


В DB2 тоже не существует, а вот в Sybase ASE - есть.
26 окт 04, 11:43    [1060649]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
gardenman
В DB2 тоже не существует, а вот в Sybase ASE - есть.

Именно поэтому мне и не понравились слова "на любом серваке".
26 окт 04, 12:06    [1060770]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
softwarer
gardenman
В DB2 тоже не существует, а вот в Sybase ASE - есть.

Именно поэтому мне и не понравились слова "на любом серваке".


А разве есть серваки, где блокировки на уровне строки отсутствуют?
26 окт 04, 12:09    [1060793]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
softwarer
у людей, привыкших работать в какой-то области, оказываются зашорены глаза. Они привыкли делать что-то криво (например, по историческим причинам), и прямое решение уже не приходит в голову.

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

Угу, именно поэтому я взял себе за правило хорошего тона при освоении другого продукта сначала изучать его базовые основы, не сравнивая с тем, что я уже знаю и на чем работал, и только после того, как я увидел его основные черты, тогда начинать сравнение с тем, что я уже хорошо знаю и на найденных различиях строить свое мнение о нем и выявлять наиболее удачные принципы работы с ним. Метод себя хорошо зарекомендовал - например годик назад изучая PowerBuilder, я честно прочитал по нему базовые книги, не обращая внимание на то, что с точки зрения той же Java или Delphi он напоминал неуклюжий утюг и не пытаясь сразу по ходу изучения все автоматизировать, налепить своих классов, подстраивающих его в привычную форму работы (хотя руки и чесались). Сейчас как результат - как оказалось в PB, если смотреть под другим углом, просто прекрасная концепция разделения функций интерфейса через ООП и функций работы с бизнес-логикой и визуальными отображениями через DataWindow. Любые вещи малым кол-вом кода реализуются просто на ура по сравнению с той же Delphi, возможности интрепретируемого языка DataWindow Expression для построения форм, гридов, графиков и отчетов просто шикарные и позволяют делать не только клиентские приложения, но и целые платформы с автоматическим построением визуальных представлений по обьектам БД. Думаю говорить не стоит, что было бы, если бы я попытался на нем программировать в привычной колее - такой результат частенько отслеживается гневными воплями на многих дельфийских форумах народа, которому приходилось встречаться с PowerBuilder :) То же самое можно полностью сказать о любой СУБД, можно между собой сравнить MSSQL и ASE именно как СУБД, но даже ASA с ними сравнивать уже не корректно, так как у нее уже совершенно другая архитектура и соотвествующе другие возможности и другие правила удачного использования. Я в таком случае предпочитаю производить сравнение в ценовом эквиваленте - затраты на закупку СУБД, разработку, сопровождение и стоимость владения, естественно при условии соблюдения выбранной СУБД всех условий по постановке задачи.

автор
ASCRUS наверно намекал на то, что в ASA и MSSQL лог может расти автоматически. Но ведь все равно диск когда-нить кончится.

А что - миллион записей так уж много весит в эквиваленте дискового пространства ?

автор
Если Update происходит в рамках одной транзакции - запросто - на любом серваке. Если по какой-то причине блокировка на уровне строки или страницы не трансформировалась в блокировку на уровне таблицы - то прийти в итоге к ROLLBACK - элементарно.Особенно когда имеются триггеры. Ведь тогда наверняка блокировки вешаются не на одну таблицу. Эмулировать такое поведение - раз плюнуть. Ну, а нехватка лога - ребята, неужели у вас ни у кого не было log out of space? Не верю... Также не поверю что никогда в жизни при получении декартова произведения в криво написанном запросе вы в tempdb не получали out of space.

Нет у нас понятия блокировки на уровне страницы и эксколации блокировок. Если ASA что то такое и делает, то никак и никем это не заметно. Это только в MSSQL сделали огромный механизм борьбы с блокировками, который по моему больше мешает, чем помогает. Может быть им вместо него нужно было бы по другому реализовать саму архитектуру блокировок ? И не было у меня проблем с нехваткой лога, на ASA не крутяться террабайтные БД, это СУБД для SMB решений (рабочих групп), сотня гигов - это уже нонсенс для такого решения, а вроде как уже давно на серверах винты не по 10 гб стоят :) И так же у нас нет tempdb, у ASA все динамично, в том числе и временные файлы, которые создаются и удаляются автоматически во время запуска и остановки сервера, что и как хранить временно - это чисто проблемы ASA, что и правильно для СУБД, которая развивается на концепциях интеллектуальной СУБД с нулевым администрированием. Причем это не означает, что она настолько умна, что сама все сделает. Это означает, что для девелопера в ее возможностях есть необходимый запас функционала, позволяющий в момент разработки БД предусмотреть различные ситуации и прописать модели поведения - от оптимизации запросов до разруливания конфликтов репликаций или системных ошибок.
26 окт 04, 12:12    [1060815]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
gardenman
А разве есть серваки, где блокировки на уровне строки отсутствуют?

Есть серваки, где блокировки на уровне строки не занимают места. И есть серваки, где механизм эскалации блокировок отсутствует в принципе.

Собственно, само наличие механизма эскалации означает архитектурную проблему, для решения которой пришлось ввести костыль.
26 окт 04, 12:22    [1060861]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
softwarer
gardenman
А разве есть серваки, где блокировки на уровне строки отсутствуют?

Есть серваки, где блокировки на уровне строки не занимают места. И есть серваки, где механизм эскалации блокировок отсутствует в принципе.

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


Ага, я представляю себе сервак, в котором отсутствуют сразу все эти компоненты - логи, роллбак-сегменты, блокировки...) эт кажется mysql т.к. там транзакции в принципе отсутствовали.. правда не знаю как сейчас.
26 окт 04, 12:46    [1060976]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
>Соединение по первичному ключу Inserted и Deleted всегда даст понятие, что на что изменилось. Из чего следует вывод, что данная конкепция отрицает изменение первичного ключа и поощряет использование ИК вместо ЕК (с чем я полностью согласен).

Точнее данная конкепция не предполагает изменение первичного ключа. Однако, это концепция реализации, а вопрос изменения первичного ключа - вопрос модели данных БД. Т.е. у нас реализация накладывает дополнительные ограничение на модель данных? Причем на существенный вопрос идентификации.
А если NEW и OLD используются для изменения значений в той же табле, Вы по прежнему будете Inserted и Deleted использовать? Делать ручками какие-то запросы.
И про агрегатные таблы - для таких в некотрых случаях лучше подходят материализованные представления.
26 окт 04, 13:24    [1061251]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
vadiminfo
Точнее данная конкепция не предполагает изменение первичного ключа. Однако, это концепция реализации, а вопрос изменения первичного ключа - вопрос модели данных БД. Т.е. у нас реализация накладывает дополнительные ограничение на модель данных? Причем на существенный вопрос идентификации.

Думаю не стоит развивать спор на тему ЕК vs ИК. Даже на форуме MSSQL он стал напоминать лестницу. Могу сказать только одно - в моих базах данных первичные ключи не изменяются и никаких проблем в связи с этим я ни разу не наблюдал.

vadiminfo
А если NEW и OLD используются для изменения значений в той же табле, Вы по прежнему будете Inserted и Deleted использовать? Делать ручками какие-то запросы.

Есть такое понятие - каскадные триггеры. Если Вы в AFTER FOR EACH STATEMENT триггере напишите UPDATE "СноваЭтаТаблица", то на этот UPDATE будут заново вызваны все триггеры и для них уже будут свои Inserted и Deleted. И естественно у каждой СУБД будут свои механизмы управления каскадностью.

vadiminfo

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

Ключевая фраза - "в некоторых". Думаю ораклисты сильно много по этому поводу спорить не будут. Панацей от всех бед ни в одной СУБД нет, у каждой существуют свои решения, обладающие неоспоримым рядом достоинств и досадным кол-вом недостатков.
26 окт 04, 13:37    [1061324]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
ASCRUS
Думаю не стоит развивать спор на тему ЕК vs ИК. Даже на форуме MSSQL он стал напоминать лестницу. Могу сказать только одно - в моих базах данных первичные ключи не изменяются и никаких проблем в связи с этим я ни разу не наблюдал.

Развивать, безусловно, незачем - просто стоит отметить факт как недостаток подхода.

Вопрос в том, что время от времени приходится работать с уже реализованными кем-то базами, и как они спроектированы и реализованы - мягко говоря, как повезет. Так, полгода назад мне пришлось чуть работать с базой, в которой редкий первичный ключ состоял менее чем из четырех полей. Рекордом было, по-моему, двенадцать.
26 окт 04, 14:25    [1061591]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
softwarer
Развивать, безусловно, незачем - просто стоит отметить факт как недостаток подхода.

а мне представляется что как раз продуманная стройная концепция, без излишеств (моё личное мнение)

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

искренне не понимаю - какие проблемы добавить поле с identity? и это всего-то цена недостатка подхода?
26 окт 04, 15:38    [1061964]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
SergSuper

искренне не понимаю - какие проблемы добавить поле с identity? и это всего-то цена недостатка подхода?


:) А вот действительно - хороший повод для отдельного топика в проктировании - хорошо это или плохо, когда у одной таблицы несколько потенциальных ключей.
26 окт 04, 15:46    [1062005]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
SergSuper
softwarer
Развивать, безусловно, незачем - просто стоит отметить факт как недостаток подхода.

а мне представляется что как раз продуманная стройная концепция, без излишеств (моё личное мнение)

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

SergSuper
искренне не понимаю - какие проблемы добавить поле с identity? и это всего-то цена недостатка подхода?

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

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

Другой вопрос - что этим достигается. Скажем, если для row-level триггеров сохранятся псевдозаписи :old и :new, а для statement-level триггеров добавлятся псевдотаблицы :inserted, :updated и :deleted - лично я буду только за.
26 окт 04, 15:49    [1062022]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
gardenman
А вот действительно - хороший повод для отдельного топика в проктировании - хорошо это или плохо, когда у одной таблицы несколько потенциальных ключей.

"Потенциальный ключ" - несколько странный термин.

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

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

P.S. Уточню, чтобы не было непониманий - когда меня учили теории БД, давали следующие определения:

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

primary key - произвольно выбранный ключ из числа уникальных

unique constraint - поле/комбинация полей, соответствующих ограничению уникальности, но не являющихся ключом (допускающее комбинацию "все равны null").
26 окт 04, 16:00    [1062059]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Я тут кстати ради интереса на ASA взял табличку с 1,5 миллионов записей, накатал на нее триггер AFTER UPDATE FOR EACH STATEMENT, который в родительской табличке с 4,5 миллионов записей выполнял пересчет суммирующего поля:
CREATE TRIGGER "test1" AFTER UPDATE
ORDER 1 ON "DBA"."usl_fis"
REFERENCING OLD AS Deleted NEW AS Inserted
FOR EACH STATEMENT
BEGIN
  UPDATE usl_efls e
  SET TotalValue = TotalValue - d.Value + i.Value
  FROM usl_efls e
    INNER JOIN (
      SELECT id_usl_efls, Sum(IsNull(Summ_Nach, 0)) AS Value
      FROM Inserted
      GROUP BY id_usl_efls
    ) AS i ON i.id_usl_efls = e.id
    INNER JOIN (
      SELECT id_usl_efls, Sum(IsNull(Summ_Nach, 0)) AS Value
      FROM Deleted
      GROUP BY id_usl_efls
    ) AS d ON d.id_usl_efls = e.id;
END;
потом написал:
UPDATE usl_fis
SET Sum_Nach = Sum_Nach + 100
WHERE Sum_Nach IS NOT NULL; // не моя база

COMMIT;
и оттарабанив 3 минуты на моей машине с загрузом процессора где процентов на 30 в среднем запрос был выполнен успешно вместе с триггером. Нехватки пространства для лога (он вообще для этой тестовой БД установлен с опцией сброса после завершения транзакции), нехватки места под временные файлы, затыкания блокировок или еще какой гадости замечено не было, причем памяти серверу было отведено на винде всего 400 метров, что в принципе под 11 гиговую БД и эти широкие таблички даже маловато будет.

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

Полностью согласен с этим. В ASA например FOREIGN KEY можно вешать не только на первичный, но и любой unique constraint. В данном случае первичный ключ обязательно нужен для оператора
INSERT INTO Table ... ON EXISTING SKIP|UPDATE|ERROR 
который насколько я понимаю является аналогом Оракловского MERGE.

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

А вот тут у нас как раз UNIQUE CONSTRAINT не могут делаться на NULL поля (возможно как раз из за возможности FOREIGN KEY по ним). Для обеспечения уникальности по NULL полям нужно делать UNIQUE INDEX.
26 окт 04, 16:11    [1062114]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
2 ASCRUS:
если бы в процессе апдейта пришлось корректировать кучу индексов, то ситуация была бы явно иной.
26 окт 04, 16:43    [1062290]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 17   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить