Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 12 13 14 15 16 [17] 18 19 20 21 .. 29   вперед  Ctrl
 Re: Каше vs. Фокс....  [new]
мод
Guest
MX -- ALEX
В прЫнципе M для сложных задач
Будем усложнять пример до уровня практического применения

Дело в том что концепции лучше видны на простых примерах. Поэтому я и попросил показать способ реализации простой картотеки. Думаю всем было бы интересно. Ну не хотите как хотите :(
6 мар 06, 17:42    [2422531]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
ну я
ASCRUS
ну я
ASCRUS
Тяжелый случай. Но я не буду вмешиваться, можете фантазировать дальше о "недостатках SQL и РСУБД". Пожалуй пора идти в 51-ый, по моему там больше здравого смысла.

Мне тоже надоело. Ладно, я тоже скажу - у мампсов тоже есть фичи которые при определенном стечении обстоятельств могут считаться недостатками. Но живем же...

Хорошо, напоследок еще раз задам вопрос, вдруг повезет и Вы ответите: "В чем недостатки предложенного мною решения ?"

Специфика реализации.

Дык до этого дорасти надо :)
(я про СУБД)
6 мар 06, 17:49    [2422581]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Еще один отличный ответ:
* до этого дорасти надо
6 мар 06, 17:51    [2422594]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
ну я
ASCRUS
Хорошо, напоследок еще раз задам вопрос, вдруг повезет и Вы ответите: "В чем недостатки предложенного мною решения ?"

Специфика реализации.

То есть идея автомобилей плоха и неэффективна тем, что принципы управления и ПДД одинаковы, а специфика реализации разная ? И еще вопрос - код, который я напишу на Cache будет без переделок работать на других M-системах или специфика реализации нам на хвосты наступит ? ;)
6 мар 06, 17:54    [2422621]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
ASCRUS
ну я
ASCRUS
Хорошо, напоследок еще раз задам вопрос, вдруг повезет и Вы ответите: "В чем недостатки предложенного мною решения ?"

Специфика реализации.

То есть идея автомобилей плоха и неэффективна тем, что принципы управления и ПДД одинаковы, а специфика реализации разная ? И еще вопрос - код, который я напишу на Cache будет без переделок работать на других M-системах или специфика реализации нам на хвосты наступит ? ;)

Опа... Опять же смотря о каких авто вести речь. Если человек обучен на категорию B, то от него и от другого автомобиля падпадающего под категорию B ожидается что один на другом поедет. Без переделок автомобиля и пересдачи на под-категорию или под-под-категорию.
Для мампсов есть определение так называемого уровня переносимости. Это требование к реализациям трактовать определенные синтаксические конструкции определенным образом. Если программа написана в этих рамках то она переносима на уровне исходников. Одновременно с тем стандарт определяет, что реализации в определенных (указанных им) случаях вольны трактовать некоторые конструкции по-своему.
Если понимать Ваши слова буквально, то есть "программы которые я напишу на Cache", то в ближайшем будущем специфика реализации Вам не скоро понадобится. Большинству программистов оно не нужно.
Вот есть, к примеру,
http://karataev.nm.ru/cache/altnc.html
Это оболочка как Нортон но написана на мампсе. Специфика реализаций вынесена в отдельные рутинки, основной код переносим.
6 мар 06, 18:14    [2422764]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Ну пожалуйста - по аналогии я возьму триггера как вынесенную специфику реализации (то есть язык ХП), и где основной код будет полностью переносим на уровне DDL и DML операторов. Специфику можно будет генерировать через тот же PD - в чем тогда разница спрашивается ?
6 мар 06, 18:22    [2422809]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
ASCRUS
Ну пожалуйста - по аналогии я возьму триггера как вынесенную специфику реализации (то есть язык ХП), и где основной код будет полностью переносим на уровне DDL и DML операторов. Специфику можно будет генерировать через тот же PD - в чем тогда разница спрашивается ?

Допустим. И где тогда будет разумная граница переносимости?
6 мар 06, 18:27    [2422845]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
ну я
ASCRUS
Ну пожалуйста - по аналогии я возьму триггера как вынесенную специфику реализации (то есть язык ХП), и где основной код будет полностью переносим на уровне DDL и DML операторов. Специфику можно будет генерировать через тот же PD - в чем тогда разница спрашивается ?

Допустим. И где тогда будет разумная граница переносимости?

Гм, а зачем нужна переносимость ? Где разумная переносимость движков автомобилей разных производителей ? Однако мы ездим и вроде как никто недовольства не высказывает. Здесь тоже самое - абсолютно не вижу смысла в разумной переносимости, есть понятие поддержки стандарта - позволяющее специалистам, работающим с одним РСУБД, достаточно быстро переходить на другой, где стандарт общий, остается узнать подробности и ньюансы.
6 мар 06, 18:29    [2422863]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
Так кто же так в институте учится ? Мне тоже только про SQL и РМД лекции читали и под Oracle учили программировать. Образование пока лучше не становится. Что касается МД - не знаю про МД, которые разрабатываются в лабораториях и пока не разработались. Разработчики qword назвали модель фреймово-реляционной. Как называется модель Fileman я точно не знаю. В Oracle не РМД, а модель, разработанная в корпорации Oracle, ее название я не знаю, хотя использую Oracle почти 10 лет. В Cache обычно используют модели, похожие на объектные или ER:
^сущность(ид.сущности)=свойства сущности
Хотя под узлом идентификатора могут быть произвольные структуры. Так что моделей разных много и их поддержка в MUMPS вполне хухры-мухры, т.е. это не сложно.
6 мар 06, 20:03    [2423212]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
А что за "ЧАЛ", если не секрет, на которого похож мой стиль ? Подозреваю, что какой-то враг народа. Нет, я во враги не хочу. Подскажите, плиз, что нужно говорить, чтобы не стать врагом народа.
6 мар 06, 20:10    [2423227]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
okdoky
Member

Откуда:
Сообщений: 349
токарь
okdoky
В отличие от SQL-СУБД, целостность поддерживается автоматически. Почти старый пример:
автомобиль:(расположение:(площадь:(вокзал:(направление:Казанское))))
Реально, здесь пять объектов связаны отношениями:
автомобиль-расположение
расположение-площадь
площадь-вокзал
вокзал-направление
Вокзалу, который здесь фигурирует, мы можем задать конкретное имя:
вокзал:(направление:Казанское)=вокзал:Казанский;
В результате изменения произойдут как в отношении площадь-вокзал, так и в отношении вокзал-направление.
Все это напоминает Prolog. Там тоже учитывались взаимосвязи, фактически такой же контроль целостности. Здесь "вокзал" играет роль атрибута в двух таблицах? Или отношения, это по вашему уже не таблицы? При изменении происходит переиндексация? Какой объем данных осилит система, чтобы выполнить запрос в пределах 5 сек?

>Здесь "вокзал" играет роль атрибута в двух таблицах?
Да "вокзал" это атрибут.
>Или отношения, это по вашему уже не таблицы?
Данные отношения соответствуют таблицам. Если объекту не задано имя, система генерирует идентификатор. Если привести к табличному виду, эти отношения выглядят так:
автомобиль  расположение
1               1

расположение  площадь
1                1

площадь  вокзал
1            1

вокзал  направление
1         Казанское
После операции
вокзал:(направление:Казанское)=вокзал:Казанский;
Последнее отношение будет выглядеть по-другому
вокзал         направление
Казанский         Казанское
>При изменении происходит переиндексация?
Переиндексация происходит мгновенно и конечно только для изменяемых значений.
>Какой объем данных осилит система, чтобы выполнить запрос в пределах 5 сек?
Скорость выборки зависит не от объема БД, а от количества выбираемых объектов. На этот вопрос я уже ответил в топике https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=241343&pg=2. Сложные запросы, >40 значений в WHERE, Zigzag выпоняет быстрее Access в два раза ИМХО :)
6 мар 06, 23:00    [2423560]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
okdoky
Member

Откуда:
Сообщений: 349
Вдогонку, после операции
вокзал:(направление:Казанское)=вокзал:Казанский;
третье отношение также изменится
площадь  вокзал
1         Казанский
6 мар 06, 23:31    [2423631]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
MX -- ALEX
c127
Забыл сказать

MX -- ALEX

то есть:
перебирать в цикле все ветви дерева "T"
и если встретится что ищем
напечатать ветвь (z) значение (@z) и остановить пробежку (quit)
если не останавливать напечатает все ветви содержащие "Tiger"
по скорости прокрутка миллиона ветвей в CACHE 5.1 занимает
примерно секунду

Пробег по миллиону записей в оракле 8 на пентиуме 500МГц м IDE диском и 128 МБ ОЗУ (может 256, не помню, все равно он ее всю не занимал) в 2000 году тоже занимал примерно секунду. Никаких индексов, никакой оптимизации, тупо поставили оракл, заполнили таблицу и протестировали. Перебор миллиона записей при стандартном моделировании древовидной структуры это полный аналог прохода по дереву с миллионом вершин.

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

примерно те же скорости по нахождению записи
что и в CACHE 5.1

Примерно что? Примерно 1 в секунду или примерно 200 в секунду?

ну я
Процессы, выполняя подсчет числа синих, еще ничего не модифицировали, значит таблица никем не заблокирована и никому нет препятствий сделать select count(*). После этого каждый выполняет вставку нового синего объекта. СУБД этому никак не препятствует.
Примерная последовательность каждого из процессов
начинаем транзакцию
begin transaction
каждый делает подсчет
select count(*) from colorobj where color = 2
получаем что можно, выполняем вставку с собственным новым id вместо 3
insert into colorobj(id,color) values(3,2)
никто не мешает, делаем коммит.
Получили 3 новых синих объекта.

Исходите из неверных посылок, оператор select на некоторых уровнях изоляции тоже блокирует таблицу.
select count(*) from colorobj where color = 2
блокирует подмножество записей с color = 2, оператор
insert into colorobj(id,color) values(3,2)
будет ждать пока первая транзакция закончится. Еще раз: на некоторых уровнях изоляции.

ну я

Да нет проблем (насчет почитать). Каким образом мне поможет изоляция транзакций, если процессы сначала одновременно делают select count(*), а потом одновременно insert? Ни один из подручных серверов не воспрепятствовал каждому процессу сделать select count(*), а потом insert с новым идентификатором. Синхронизация и изоляция? А они являются частью sql?

Да, это стандарт.

Вы все-таки попробуйте почитать, или если задаете вопросы, то хотя бы слушайте что Вам отвечают.
7 мар 06, 01:08    [2423732]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
ну я
Товарищ ASCRUS уточнил, каким именно дивалектом пользовался и дал дырявое решение, товарищ Павел Воронцов живо заинтересовался как решить задачку в мампсах и пока молчит как это же сделать в sql, а Вы, товарищ mir, привели фрагмент из декларации ограничений на основе подзапросов и тут же оговорились что оказывается было бы мечтой если бы были программы которые стандарт поддерживали, потом выяснилось, что задача решается изоляцией транзакций.

Если задачка давно решенная, изученная, классическая, то почему она ставит в тупик товарищей, которые не один год помогают другим на этом форуме и вызывает столь многочисленные и разносторонние телодвижения?
Правильное решение Вам дали, мне было влом повторяться. Своим ответом Вы лишь показали какие проблемы Вас волнуют, объяснять прописные истины нет никакого желания и времени. Подход М к блокированию (программист обязан заботиться о блокировании там, где это необходимо) обладает очевидным недостатком - программист может а) Не знать, что именно этот ресурс надо блокировать б) забыть это сделать.
7 мар 06, 08:50    [2423992]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
И есть еще в) может неправильно блокировать данные, так как в зависимости от операции и уровня изоляции блокировки могут существенно различаться - например для борьбы с фантомами будет совершенно мало наложить блокировки на существующие записи, даже если эти блокировки будут эксклюзивные.
7 мар 06, 09:01    [2424005]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
okdoky
В отличие от SQL-СУБД, целостность поддерживается автоматически.
А поподробнее? Что вы понимаете здесь под целостностью и под ее автоматической поддержкой? Вас уже об этом спрашивали, но ответа все нет.
7 мар 06, 09:10    [2424020]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
ораклоидальный мампсист
А что за "ЧАЛ", если не секрет, на которого похож мой стиль ? Подозреваю, что какой-то враг народа. Нет, я во враги не хочу. Подскажите, плиз, что нужно говорить, чтобы не стать врагом народа.

ЧАЛ
это жертва SQL-террора
замученый партизан
Герой SQL/MUMPS войны
Андрей Леонидович Чкалов
-----------------------------
а говорить надо
SQL наше Светлое Будущее !!
-----------------------------
но лучше молчать прикинуться ветошью
спрятаться в углу и не отсвечивать
7 мар 06, 11:23    [2424602]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
"но лучше молчать прикинуться ветошью спрятаться в углу и не отсвечивать"

Лучше сказал классик :

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

...

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

Так что вот-с. :) Что бы не возникало всяких "иерархических деревьев" (с) которые ещё и растут ), вопросов про согласованость (которые изучаются уже лет 30 и весьма неплохо проработаны ), всяческих крахов РМД и объектов противостоящих субъекту в какой-то там (забыл какой) деятельности, нужно посмотреть по-подробнее чего собираемся ниспровергать :)
7 мар 06, 11:36    [2424681]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
c127
MX -- ALEX
c127
Забыл сказать

MX -- ALEX

то есть:
перебирать в цикле все ветви дерева "T"
и если встретится что ищем
напечатать ветвь (z) значение (@z) и остановить пробежку (quit)
если не останавливать напечатает все ветви содержащие "Tiger"
по скорости прокрутка миллиона ветвей в CACHE 5.1 занимает
примерно секунду

Пробег по миллиону записей в оракле 8 на пентиуме 500МГц м IDE диском и 128 МБ ОЗУ (может 256, не помню, все равно он ее всю не занимал) в 2000 году тоже занимал примерно секунду. Никаких индексов, никакой оптимизации, тупо поставили оракл, заполнили таблицу и протестировали. Перебор миллиона записей при стандартном моделировании древовидной структуры это полный аналог прохода по дереву с миллионом вершин.

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

примерно те же скорости по нахождению записи
что и в CACHE 5.1

Примерно что? Примерно 1 в секунду или примерно 200 в секунду?

миллион в секунду
7 мар 06, 11:36    [2424685]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
c127
ну я
Процессы, выполняя подсчет числа синих, еще ничего не модифицировали, значит таблица никем не заблокирована и никому нет препятствий сделать select count(*). После этого каждый выполняет вставку нового синего объекта. СУБД этому никак не препятствует.
Примерная последовательность каждого из процессов
начинаем транзакцию
begin transaction
каждый делает подсчет
select count(*) from colorobj where color = 2
получаем что можно, выполняем вставку с собственным новым id вместо 3
insert into colorobj(id,color) values(3,2)
никто не мешает, делаем коммит.
Получили 3 новых синих объекта.

Исходите из неверных посылок, оператор select на некоторых уровнях изоляции тоже блокирует таблицу.
select count(*) from colorobj where color = 2
блокирует подмножество записей с color = 2, оператор
insert into colorobj(id,color) values(3,2)
будет ждать пока первая транзакция закончится. Еще раз: на некоторых уровнях изоляции.

Какое именно множество записей блокирует оператор
select count(*) from colorobj where color = 2
если таблица пуста?
7 мар 06, 11:47    [2424742]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
мод
Guest
[quot Andreww[/quot]
отлично !
7 мар 06, 12:15    [2424920]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
c127
А после индексации, тоже без настроек, все по умолчанию, в секунду стало выполняться примерно 200 запросов по нахождению записи в таблице с 1млн. записей.

По-моему ошибка - 200 даже для такой железяки маловать.
Для сравнения попробовал у себя, только таблица полмилиона. За 5 сек выполнилось 100 000 запросов.
В любом случае время поиска 1 сек на в млн записей - неприемлемо много.

ну я
Какое именно множество записей блокирует оператор
select count(*) from colorobj where color = 2
если таблица пуста?

Ну например блокируется вставка записей where color = 2
7 мар 06, 12:18    [2424943]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ораклоидальный мампсист

Так кто же так в институте учится ?

Ну кроме Вас с ЧАЛом, наверное, все нормальные студенты.


ораклоидальный мампсист

Мне тоже только про SQL и РМД лекции читали и под Oracle учили программировать.

Шото у них не получилось.

ораклоидальный мампсист

Образование пока лучше не становится.

Да уж, Вам с ЧАЛом скорей всего уже ниче не поможет.


ораклоидальный мампсист

Что касается МД - не знаю про МД, которые разрабатываются в лабораториях и пока не разработались.

А которые разработались, но не нашли применения на практике хоть знаете?
Или хотя бы те что нашли. Про РМД, то хоть в курсе?

ораклоидальный мампсист

В Oracle не РМД, а модель, разработанная в корпорации Oracle, ее название я не знаю, хотя использую Oracle почти 10 лет.

Могу себе представить эту 10-летнюю работу. В Оракле нет РМД? Вы уверены?
Справку Оракла читали? Литературу про Оракл?

ораклоидальный мампсист

В Oracle не РМД, а модель, разработанная в корпорации Oracle, ее название я не знаю, хотя использую Oracle почти 10 лет.

Могу себе представить эту 10-летнюю работу. В Оракле нет РМД? Вы уверены?
Справку Оракла читали? Литературу про Оракл? Может Вы думаете что там ООМД?

ораклоидальный мампсист

Так что моделей разных много и их поддержка в MUMPS вполне хухры-мухры, т.е. это не сложно.

Т.е плоская? типа файлы там тока есть и хорошо спроектированные приложения? От кого-то (не буду говорить от кого, хотя это ЧАЛ) это уже слышали.

ораклоидальный мампсист

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

Вам тада лучше ничего не говорить.
ЧАЛ это такой чел со взглядами 30-40-летней давности, када были у нас доступны тока самые притивные системы для разработки БД. Но он верит шо они передовые, не в курсах ничего современного, но грит уверенно про глобальные вещи, использует термины не поназначению. Не понимает шо ему говорят и повторяет одно и то же. Типа пропаганда такая грубая его отсталых взглядов.
7 мар 06, 12:51    [2425138]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
ну я
Какое именно множество записей блокирует оператор
select count(*) from colorobj where color = 2
если таблица пуста?

Ну например блокируется вставка записей where color = 2[/quot]
Не поленился, проверил. Неверно.
7 мар 06, 12:52    [2425143]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
ну я
Не поленился, проверил. Неверно.

Вам же написали - при некоторый уровнях изоляции. Поставьте SET TRANSACTION ISOLATION LEVEL SERIALIZABLE - и будет всё заблокировано.
Но при вставке условия не проверяются(тут я был не прав), т.е. в таблицу вообще ничего нельзя будет вставить(во всяком случае для MS SQL)

Вот описание уровней изоляции

READ COMMITTED

Specifies that shared locks are held while the data is being read to avoid dirty reads, but the data can be changed before the end of the transaction, resulting in nonrepeatable reads or phantom data. This option is the SQL Server default.

READ UNCOMMITTED

Implements dirty read, or isolation level 0 locking, which means that no shared locks are issued and no exclusive locks are honored. When this option is set, it is possible to read uncommitted or dirty data; values in the data can be changed and rows can appear or disappear in the data set before the end of the transaction. This option has the same effect as setting NOLOCK on all tables in all SELECT statements in a transaction. This is the least restrictive of the four isolation levels.

REPEATABLE READ

Locks are placed on all data that is used in a query, preventing other users from updating the data, but new phantom rows can be inserted into the data set by another user and are included in later reads in the current transaction. Because concurrency is lower than the default isolation level, use this option only when necessary.

SERIALIZABLE

Places a range lock on the data set, preventing other users from updating or inserting rows into the data set until the transaction is complete. This is the most restrictive of the four isolation levels. Because concurrency is lower, use this option only when necessary. This option has the same effect as setting HOLDLOCK on all tables in all SELECT statements in a transaction.
7 мар 06, 14:34    [2425811]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 12 13 14 15 16 [17] 18 19 20 21 .. 29   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить