powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Почему только русские СУБД
25 сообщений из 141, страница 4 из 6
Почему только русские СУБД
    #34123377
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А ведь точно, я под СВМ и сам делал. А вот под примусом вроде не получалось
Ну тогда слава советским многомашинным комплексам!
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34123901
okdoky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
c127
Сложные иерархические СУБД как раз сейчас обсуждаются в соседнем топике. Вместо того, чтобы болтать языком решили бы с помощью более сложного иерархического ХМЛ-я задачи с авиабилетами или со студентами-преподавателиями, глядишь кто-нибудь и заинтересовался бы зигзагом. А так вряд ли что-нибудь получится с продвижением устаревшей технологии на рынок, несмотря на титанические усилия продвигающих. Это вы XML обзываете устаревшей технологией? А что тогда говорить про таблицы, которые вы так усердно защищаете? Первоначальные реализации SQL работали с обыкновенными последовательными файлами (на тех же ЕС 1020). При этом использовались обыкновенные механизмы выборки, те самые SELECT. Я смотрю на XQuery, Zigzag и SQL только как на языковые инструменты. Сравнивать их реализации (и прежде всего быстродействие) здесь на форуме бессмысленно. Я уже когда-то пытался. Тоже можно сказать и про приложения, разработанные на основе этих языков. Поэтому я давно уже не демонстрирую и не продвигаю то, что мы разработали на основе Zigzag. Оно больше подходит для тех, кто работает с мобильными устройствами...

Надеюсь, вы и сами догадываетесь, что языки, ориентированные на обработку XML, удобнее для работы с иерархическими данными? Сомнения в быстродействии? Попробую вам объяснить это чисто логически. Надеюсь это не будет похоже на треп. Вы уже знаете как обычно представляется дерево в реляционной модели? Для:
Код: plaintext
1.
2.
3.
4.
5.
          1
         / \
        2   3
      /   \
     4     5
    / \
Обычный способ представления дерева неопределенной глубины в РМ задается таблицами, с примерной структурой:
Узел Предок Свойство

Представьте как будет решаться задача перехода от узла 1 к узлам 4, 5 и ниже. Вы не сможете обойтись без того, чтобы не сделать операцию выборки промежуточных вершин 2, 3. В современных реализациях XML в «поле зрения» будут находится сразу все вершины подчиненные 1 и это выполняется за одно обращение к внешнему устройству.... Если вас интересуют другие задачи, чисто табличные, по-моему я уже демонстрировал. Впрочем, могу продемонстрировать, если будет время, еще, как на XQuery, так и Zigzag.
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34124014
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторПредставьте как будет решаться задача перехода от узла 1 к узлам 4, 5 и ниже. Вы не сможете обойтись без того, чтобы не сделать операцию выборки промежуточных вершин 2, 3. В современных реализациях XML в «поле зрения» будут находится сразу все вершины подчиненные 1 и это выполняется за одно обращение к внешнему устройству....
Это только при условии что таблица будет с примерной структурой:
Узел Предок Свойство
. А есть еще много вариантов.
Да и моделировать объекты обычно приходится гораздо более сложной структуры чем дерево.

Неважно устаревшая технология XML или нет, но использовать её как хранилище данных глупо. Для передачи информации, хранения каких-то настроек - да, замечательно. Но не нужно использовать там, для чего оно не предусмотрено
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34124036
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторНадеюсь, вы и сами догадываетесь, что языки, ориентированные на обработку XML, удобнее для работы с иерархическими данными?

само хранение данных в виде иерархии является неэффективным.
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34124391
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1024 авторНадеюсь, вы и сами догадываетесь, что языки, ориентированные на обработку XML, удобнее для работы с иерархическими данными?

само хранение данных в виде иерархии является неэффективным.

Прана-прана, таблицы в деревьями - изживать как класс!
Запросы типа connect by prior - ф топку!
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34124806
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1024 авторНадеюсь, вы и сами догадываетесь, что языки, ориентированные на обработку XML, удобнее для работы с иерархическими данными?

само хранение данных в виде иерархии является неэффективным.
Хотелось бы познакомиться с продолжением мысли. Или с предпосылками. Опустим XML. О иерархическом хранении данных, если можно.
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34124907
okdoky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuperЭто только при условии что таблица будет с примерной структурой:
Узел Предок Свойство
. А есть еще много вариантов. Треп. Пример эффективного представления неограниченного в глубь дерева на основе таблиц?
SergSuperДа и моделировать объекты обычно приходится гораздо более сложной структуры чем дерево. Иерархическая модель может рассматриваться как множество таблиц, имеющих иерархическую зависимость. Каждый уровень иерархии по сути это таблица. Я не говорю об иерархии типов, как у Oracle, которое принципиально ничего не меняет. Я говорю об иерархии данных. Самый наглядный пример:
Код: plaintext
1.
2.
3.
      животные(признак1)
      /                 \
млекопитающие(признак2)  птицы(признак3)
    /         \              /     \
Здесь фактически три таблицы. Например, таблица «животные» имеет две записи «млекопитающие» и «птицы», с определенными значениями в полях признак1. Одновременно, эти же записи (или их идентификаторы) определяют новые таблицы с другими признаками.
SergSuperНеважно устаревшая технология XML или нет, но использовать её как хранилище данных глупо. Для передачи информации, хранения каких-то настроек - да, замечательно. Но не нужно использовать там, для чего оно не предусмотреноДля внутреннего представления даже в XML-СУБД совсем необязательно должен использоваться XML. Также как в РСУБД, внутреннее представление отнюдь не таблица.
1024само хранение данных в виде иерархии является неэффективным.Упссс. А как хранятся данные в архивах? Что такое по вашему B-tree индексация, применяемая в РСУБД? Сможете представить вашу файловую систему в виде таблиц?
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34124946
Dmitriy Ivanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ня> Хотелось бы познакомиться с продолжением мысли. Или с
ня> предпосылками. Опустим XML. О иерархическом хранении данных, если
ня> можно.

Согласен, хранить существенные объемы в XML - глупо, ибо это текстовое
представление по определению. Ни о какой эффективности и речи быть не может.
ИМХО, идея XML как универсального средства сильно раздута производителями,
которым требуется чем-нибудь привлечь клиента к новым версиям.

Для задач с существенным уровнем иерархии данных, скорее, следует обратить
внимание на объектные базы данных, например, такие как ObjectStore или
AllegroCache. Эффективность их зиждется на том, что подавляющее большинство
запросов осуществляют доступ к объекту (читай, записи) в по адресу (читай,
идентификатору или первичному ключу), а не по набору условий WHERE. К тому
же, в них присутствуют хорошая интеграция с каким-нибудь
объектно-ориентированным языком программирования.



Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34124957
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okdoky Треп. Пример эффективного представления неограниченного в глубь дерева на основе таблиц?Есть много вариантов
Вот например простейший
okdoky
Иерархическая модель может рассматриваться как множество таблиц, имеющих иерархическую зависимость. Каждый уровень иерархии по сути это таблица. Я не говорю об иерархии типов, как у Oracle, которое принципиально ничего не меняет. Я говорю об иерархии данных
...
А вот изобразите-ка гениалогическое дерево. Но только что б там были оба предка(мать и отец), а не только по отец.

okdoky Что такое по вашему B-tree индексация, применяемая в РСУБД? Можно спорить как хранятся файлы, но уж индекс то данными никак не является.
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34125167
43210
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SergSuper
А вот изобразите-ка гениалогическое дерево. Но только что б там были оба предка(мать и отец), а не только по отец.Если база объектная, то два указателя на два родительских объекта, больших делов и по коллекции детишек в каждом родителе.
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34125365
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SergSuper
А вот изобразите-ка гениалогическое дерево. Но только что б там были оба предка(мать и отец), а не только по отец.
.

согласен - пример неудобный ,
но
М-программист в этом случае может поступить почти так же, как PM:
создать глобаль
^GT(дитя)=отец:мать
и далее работать с ней ничуть не хуже чем R-программист с таблицей
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34125518
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okdoky
Надеюсь, вы и сами догадываетесь, что языки, ориентированные на обработку XML, удобнее для работы с иерархическими данными?

Вообще-то не языки, ориентированные на обработку XML, а полуструктурированные (или слабоструктурированные) МД в контексте БД упоминаются, в связи с XML. А языки БД для иерахических данных, могут оказаться более удобными в общем случае совсем другие. Например, в иерархических и сетевых СУБД использовались навигационные языки БД. Возможно, в каких-то случаях они окажутся удобнее (в каком-то смысле и для кого-то), но, скорее всего, во многих случая реляционная или проч (ОО, ОР) (какая иерархия, а тем более произвольный граф) окажутся наиболее эффективными решениями в целом. Но иерахичиские, реляционные, ОО и ОР - сильноструктурированные МД. Вот если решающим где-то будет полуструктурированность, то там, может XML имеет шансы. И то сегодня еще это вряд ли в реальных ИС. Только, наверное, как что-то частное.

okdoky
Оно больше подходит для тех, кто работает с мобильными устройствами...

В каком смысле?
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34125573
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
okdoky c127
Сложные иерархические СУБД как раз сейчас обсуждаются в соседнем топике. Вместо того, чтобы болтать языком решили бы с помощью более сложного иерархического ХМЛ-я задачи с авиабилетами или со студентами-преподавателиями, глядишь кто-нибудь и заинтересовался бы зигзагом. А так вряд ли что-нибудь получится с продвижением устаревшей технологии на рынок, несмотря на титанические усилия продвигающих. Это вы XML обзываете устаревшей технологией? А что тогда говорить про таблицы, которые вы так усердно защищаете?
Лучше ничего не говорите о таблицах, в которых Вы мало смыслите. ХМЛ это иерархическая структура данных, которая появилась до реляционной модели, но очень быстро выяснилось, что практические задачи в виде деревьев не записываются. Всё, можно забыть об иерархической структуре, за исключением очень небольшого числа очень простых случаев. А ХМЛ это очередная попытка заработать деньги за счет тех, кто ничего не слышал об иерархических БД, об их проблемах и о том, что это уже проходили.

okdokyНадеюсь, вы и сами догадываетесь, что языки, ориентированные на обработку XML, удобнее для работы с иерархическими данными?
Никто не спорит, только иерархических данных в природе раз-два и обчелся. Как только данные слегка не иерархические, у иерархических БД вместе с ХМЛ-ем появляется куча проблем. Именно поэтому и придумали РСУБД.

okdokyСомнения в быстродействии? Попробую вам объяснить это чисто логически. Надеюсь это не будет похоже на треп. Вы уже знаете как обычно представляется дерево в реляционной модели? Для:
Код: plaintext
1.
2.
3.
4.
5.
          1
         / \\
        2   3
      /   \\
     4     5
    / \\
Обычный способ представления дерева неопределенной глубины в РМ задается таблицами, с примерной структурой:
Узел Предок Свойство

Представьте как будет решаться задача перехода от узла 1 к узлам 4, 5 и ниже. Вы не сможете обойтись без того, чтобы не сделать операцию выборки промежуточных вершин 2, 3. В современных реализациях XML в «поле зрения» будут находится сразу все вершины подчиненные 1 и это выполняется за одно обращение к внешнему устройству....
Оригинальное утверждение было:
"Эта система работает быстрее чем любая РСУБД, особенно с данными имеющими иерархическую зависимость."
/topic/354796&pg=3#3386388

Т.е. Zigzag всегда быстрее чем РСУБД, а когда с деревьями, так тем более. Вот и не съезжайте на деревья, расскажте о том, на основании каких данных Вы выяснили, что Zigzag "работает быстрее чем любая РСУБД" на любой задаче.
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34125884
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
43210 SergSuper
А вот изобразите-ка гениалогическое дерево. Но только что б там были оба предка(мать и отец), а не только по отец.Если база объектная, то два указателя на два родительских объекта, больших делов и по коллекции детишек в каждом родителе.
Ну вот пусть господин okdoky на XML и изобразит. А то на животных у него хорошо получается, пусть к людям перейдёт
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34126848
okdoky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuper okdoky Треп. Пример эффективного представления неограниченного в глубь дерева на основе таблиц?Есть много вариантов
Вот например простейший Опять треп. Где конкретный ответ (ссылка)? Это называется «запутывать следы».
SergSuperА вот изобразите-ка гениалогическое дерево. Но только что б там были оба предка(мать и отец), а не только по отец. Переверните дерево и будет вам ответ. Если серьезно, любую сеть можно представить несколькими деревьями с пересекающимися (эквивалентными) вершинами.
SergSuper okdoky Что такое по вашему B-tree индексация, применяемая в РСУБД? Можно спорить как хранятся файлы, но уж индекс то данными никак не является.…, но имеет прямое отношение к эффективному представлению или хранению.
vadiminfo okdoky
Оно больше подходит для тех, кто работает с мобильными устройствами...
В каком смысле?Речь идет о приложениях реализованных на Zigzag. Один из примеров справочная ОРГАНИЗАЦИИ МОСКВЫ .
c127Т.е. Zigzag всегда быстрее чем РСУБД, а когда с деревьями, так тем более. Вот и не съезжайте на деревья, расскажте о том, на основании каких данных Вы выяснили, что Zigzag "работает быстрее чем любая РСУБД" на любой задаче. Можно посмотреть предыдущий пример, справочную. Например, в «поиске организаций» можно сделать запрос по всем улицам на букву А. Их больше 100. Запрос в Zigzag выполнится мгновенно. При этом надо учесть, что используется невыделенный виртуальный хостинг (работает одновременно много других сайтов). Сама БД Zigzag используется не только для выполнения ваших запросов. Кроме того, интерфейс который вы видите генерируется автоматически на основе текущей БД. Увы, для этого тоже требуются запросы.

Мы проверяли на SQL такие же запросы для индексированной таблицы с перечислением в WHERE более чем 100 значений. Они выполняются медленнее в 1,5 раза для MS Access. Кстати, MS Access работала в 2 раза быстрее чем Interbase и чуть быстрее MS SQL Server. Признаю, запросы проверялись только при однопользовательском режиме. Собственно контроль за множеством пользователей реализовать на Java несложно. Для этого используются и сервера приложений...
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34126905
...запрос по всем улицам на букву А. Их больше 100...
...перечислением в WHERE более чем 100 значений...
Я дико извиняюсь, но ИМХО ... WHERE SOMEFIELD Like "A*"... это совсем не то что перечисление в WHERE более чем 100 значений / Ежели Вы так сравниваете, и на полном серьезе нам предлагаете рассматривать это как критерий истины, то... ГЫ-ГЫ-ГЫ-US ...простите не удержался.....
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34126919
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okdoky
Речь идет о приложениях реализованных на Zigzag.

Это то я понял. Не понял почему они лучше для тех кто работает с мобильными устройствами.
Чем лучше? Быстрее работает, Быстрее на ней реальную ИС разработать, Легче сопровождать? Или для мобильных устройств другие в принципе не подходят? Я это имел в виду уточнить. В чем там особенность мобильности проявляется, которая делает других хуже? Для тех кто работает немобольными устройствами, как я понял, они не лучше уже?
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34126976
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторХотелось бы познакомиться с продолжением мысли. Или с предпосылками. Опустим XML. О иерархическом хранении данных, если можно.

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

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

Хранение данных в виде иерархии позволяет легко выполнять поиск по критериям совпадающим с этой иерархией и крайне затрудняют по остальным параметрам. В этом смысл отказа от деревянных структур.
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34127041
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okdokyМожно посмотреть предыдущий пример, справочную. Например, в «поиске организаций» можно сделать запрос по всем улицам на букву А. Их больше 100. Запрос в Zigzag выполнится мгновенно. При этом надо учесть, что используется невыделенный виртуальный хостинг (работает одновременно много других сайтов). Сама БД Zigzag используется не только для выполнения ваших запросов. Кроме того, интерфейс который вы видите генерируется автоматически на основе текущей БД. Увы, для этого тоже требуются запросы.

Мы проверяли на SQL такие же запросы для индексированной таблицы с перечислением в WHERE более чем 100 значений. Они выполняются медленнее в 1,5 раза для MS Access. Кстати, MS Access работала в 2 раза быстрее чем Interbase и чуть быстрее MS SQL Server. Признаю, запросы проверялись только при однопользовательском режиме. Собственно контроль за множеством пользователей реализовать на Java несложно. Для этого используются и сервера приложений...
Ну, я бы не сказал, что оно так уж мгновенно работает. По одной букве в названии улицы оно искать вообще отказывается, по "мо" реакция была порядка двух секунд, например. Ничем не выдающийся результат, для выборки полутора тысяч объектов из 125 000. Вполне могли б и какой-нить MySQL использовать, который для хостинга куда менее экзотичен.
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34127163
okdoky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мимо пробегал......запрос по всем улицам на букву А. Их больше 100...
...перечислением в WHERE более чем 100 значений...
Я дико извиняюсь, но ИМХО ... WHERE SOMEFIELD Like "A*"... это совсем не то что перечисление в WHERE более чем 100 значений / Ежели Вы так сравниваете, и на полном серьезе нам предлагаете рассматривать это как критерий истины, то... ГЫ-ГЫ-ГЫ-US ...простите не удержался.....Да с запросом ... WHERE SOMEFIELD Like "A*"... SQL работает чуть быстрее, чем с перечислением. Речь идет именно о перечислении WHERE улица='А...' OR улица='А...' ...
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34127210
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
С трудом представляю, для чего в этой задаче и на нормализованной БД может потребоваться перечисление из сотни альтернатив.
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34127222
Афигеть :) Вы хоть сами то прикинте, скока это "чуть быстрее" на самом деле означает. "Like A*" это фактически поиск толко по первой букве,
А WHERE улица='А...' OR улица='А...' ... это точное сранение знавчения поля с искомым значением - и это для более чем для ста значений. Так что Ваше "чуть быстрее" - это ИМХО "быстрее в порядки".
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34127253
То есть если средняя длина названия улицы = 10 символам, то точное сравнение означает 10 посимвольных сравненй. Для более чем ста значений мы получаем более 1000 сравненй. А Like "A*" ' это всего одно сравнение (первого символа). Это "чуть быстрее"?
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34127353
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
okdoky SergSuper okdoky Треп. Пример эффективного представления неограниченного в глубь дерева на основе таблиц?Есть много вариантов
Вот например простейший Опять треп. Где конкретный ответ (ссылка)? Это называется «запутывать следы».
okdoky, ну если Вы не знаете элементарных вещей, почему надо так неуважительно называть мои высказываниям?
Дерево можно хранить с помощью множественной модели, когда каждая ветвь рассматривается как множество и можно проверять входит ли одно множество в другое или нет. Реализации могут быть различны. Пример можно посмотреть тут .

А в ссылочке там ошибка была, правильно /topic/351164&pg=29#3393086
okdoky
SergSuperА вот изобразите-ка гениалогическое дерево. Но только что б там были оба предка(мать и отец), а не только по отец. Переверните дерево и будет вам ответ. Если серьезно, любую сеть можно представить несколькими деревьями с пересекающимися (эквивалентными) вершинами. Т.е. в XML-е это не изобразить(надеюсь Вы сами понимаете, что перевернуть недостаточно)?
Пойдём дальше - любое дерево можно представить в виде таблицы с пересекающимися ячеками
okdoky SergSuper okdoky Что такое по вашему B-tree индексация, применяемая в РСУБД? Можно спорить как хранятся файлы, но уж индекс то данными никак не является.…, но имеет прямое отношение к эффективному представлению или хранению.
Косвенное, косвенное. Только для ускорения получения. Ну собственно то высказывание было не моё, а спор тут чисто теоритический
okdoky
Речь идет о приложениях реализованных на Zigzag. Один из примеров справочная ОРГАНИЗАЦИИ МОСКВЫ .
Это... постеснялись бы такое показывать, что ли... я конечно понимаю что это единственное в мире что было сделано на зигзаге, но всё равно...
...
Рейтинг: 0 / 0
Почему только русские СУБД
    #34127550
okdoky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мимо пробегал...То есть если средняя длина названия улицы = 10 символам, то точное сравнение означает 10 посимвольных сравненй. Для более чем ста значений мы получаем более 1000 сравненй. А Like "A*" ' это всего одно сравнение (первого символа). Это "чуть быстрее"?Вот поэтому я и предлагал зайти в справочную и посмотреть как будет работать Zigzag с таким большим перечислением. Тем более что запрос сделать просто, система сама предлагает список возможных улиц или других атрибутов имеющихся в текущей БД . Ну а запрос на A* в Zigzag конечно тоже можно сделать:
Код: plaintext
= организация (улица:'А'*)
С перечислением будет выглядеть так:
Код: plaintext
= организация (улица:['ааа','ббб'])
...
Рейтинг: 0 / 0
25 сообщений из 141, страница 4 из 6
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Почему только русские СУБД
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]