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

Откуда: SPb
Сообщений: 5488
А ведь точно, я под СВМ и сам делал. А вот под примусом вроде не получалось
Ну тогда слава советским многомашинным комплексам!
13 ноя 06, 12:04    [3390682]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
okdoky
Member

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

Сложные иерархические СУБД как раз сейчас обсуждаются в соседнем топике. Вместо того, чтобы болтать языком решили бы с помощью более сложного иерархического ХМЛ-я задачи с авиабилетами или со студентами-преподавателиями, глядишь кто-нибудь и заинтересовался бы зигзагом. А так вряд ли что-нибудь получится с продвижением устаревшей технологии на рынок, несмотря на титанические усилия продвигающих.
Это вы XML обзываете устаревшей технологией? А что тогда говорить про таблицы, которые вы так усердно защищаете? Первоначальные реализации SQL работали с обыкновенными последовательными файлами (на тех же ЕС 1020). При этом использовались обыкновенные механизмы выборки, те самые SELECT. Я смотрю на XQuery, Zigzag и SQL только как на языковые инструменты. Сравнивать их реализации (и прежде всего быстродействие) здесь на форуме бессмысленно. Я уже когда-то пытался. Тоже можно сказать и про приложения, разработанные на основе этих языков. Поэтому я давно уже не демонстрирую и не продвигаю то, что мы разработали на основе Zigzag. Оно больше подходит для тех, кто работает с мобильными устройствами...

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

Представьте как будет решаться задача перехода от узла 1 к узлам 4, 5 и ниже. Вы не сможете обойтись без того, чтобы не сделать операцию выборки промежуточных вершин 2, 3. В современных реализациях XML в «поле зрения» будут находится сразу все вершины подчиненные 1 и это выполняется за одно обращение к внешнему устройству.... Если вас интересуют другие задачи, чисто табличные, по-моему я уже демонстрировал. Впрочем, могу продемонстрировать, если будет время, еще, как на XQuery, так и Zigzag.
13 ноя 06, 14:09    [3391785]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
автор
Представьте как будет решаться задача перехода от узла 1 к узлам 4, 5 и ниже. Вы не сможете обойтись без того, чтобы не сделать операцию выборки промежуточных вершин 2, 3. В современных реализациях XML в «поле зрения» будут находится сразу все вершины подчиненные 1 и это выполняется за одно обращение к внешнему устройству....

Это только при условии что таблица будет с примерной структурой:
Узел Предок Свойство
. А есть еще много вариантов.
Да и моделировать объекты обычно приходится гораздо более сложной структуры чем дерево.

Неважно устаревшая технология XML или нет, но использовать её как хранилище данных глупо. Для передачи информации, хранения каких-то настроек - да, замечательно. Но не нужно использовать там, для чего оно не предусмотрено
13 ноя 06, 14:40    [3392036]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
автор
Надеюсь, вы и сами догадываетесь, что языки, ориентированные на обработку XML, удобнее для работы с иерархическими данными?


само хранение данных в виде иерархии является неэффективным.
13 ноя 06, 14:44    [3392082]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
nik_x
Member

Откуда:
Сообщений: 1887
1024
автор
Надеюсь, вы и сами догадываетесь, что языки, ориентированные на обработку XML, удобнее для работы с иерархическими данными?


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


Прана-прана, таблицы в деревьями - изживать как класс!
Запросы типа connect by prior - ф топку!
13 ноя 06, 16:05    [3392796]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
1024
автор
Надеюсь, вы и сами догадываетесь, что языки, ориентированные на обработку XML, удобнее для работы с иерархическими данными?


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

Хотелось бы познакомиться с продолжением мысли. Или с предпосылками. Опустим XML. О иерархическом хранении данных, если можно.
13 ноя 06, 17:38    [3393672]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
okdoky
Member

Откуда:
Сообщений: 349
SergSuper
Это только при условии что таблица будет с примерной структурой:
Узел Предок Свойство
. А есть еще много вариантов.
Треп. Пример эффективного представления неограниченного в глубь дерева на основе таблиц?
SergSuper
Да и моделировать объекты обычно приходится гораздо более сложной структуры чем дерево.
Иерархическая модель может рассматриваться как множество таблиц, имеющих иерархическую зависимость. Каждый уровень иерархии по сути это таблица. Я не говорю об иерархии типов, как у Oracle, которое принципиально ничего не меняет. Я говорю об иерархии данных. Самый наглядный пример:
      животные(признак1)
/ \
млекопитающие(признак2) птицы(признак3)
/ \ / \
Здесь фактически три таблицы. Например, таблица «животные» имеет две записи «млекопитающие» и «птицы», с определенными значениями в полях признак1. Одновременно, эти же записи (или их идентификаторы) определяют новые таблицы с другими признаками.
SergSuper
Неважно устаревшая технология XML или нет, но использовать её как хранилище данных глупо. Для передачи информации, хранения каких-то настроек - да, замечательно. Но не нужно использовать там, для чего оно не предусмотрено
Для внутреннего представления даже в XML-СУБД совсем необязательно должен использоваться XML. Также как в РСУБД, внутреннее представление отнюдь не таблица.
1024
само хранение данных в виде иерархии является неэффективным.
Упссс. А как хранятся данные в архивах? Что такое по вашему B-tree индексация, применяемая в РСУБД? Сможете представить вашу файловую систему в виде таблиц?
13 ноя 06, 17:58    [3393865]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
Dmitriy Ivanov
Member

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

ня> Хотелось бы познакомиться с продолжением мысли. Или с
ня> предпосылками. Опустим XML. О иерархическом хранении данных, если
ня> можно.

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

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



Posted via ActualForum NNTP Server 1.3

13 ноя 06, 18:13    [3393963]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
okdoky
Треп. Пример эффективного представления неограниченного в глубь дерева на основе таблиц?
Есть много вариантов
Вот например простейший
okdoky

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

А вот изобразите-ка гениалогическое дерево. Но только что б там были оба предка(мать и отец), а не только по отец.

okdoky
Что такое по вашему B-tree индексация, применяемая в РСУБД?
Можно спорить как хранятся файлы, но уж индекс то данными никак не является.
13 ноя 06, 18:19    [3393991]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
43210
Guest
SergSuper

А вот изобразите-ка гениалогическое дерево. Но только что б там были оба предка(мать и отец), а не только по отец.
Если база объектная, то два указателя на два родительских объекта, больших делов и по коллекции детишек в каждом родителе.
13 ноя 06, 20:15    [3394390]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
MX -- ALEX
Guest
SergSuper

А вот изобразите-ка гениалогическое дерево. Но только что б там были оба предка(мать и отец), а не только по отец.
.


согласен - пример неудобный ,
но
М-программист в этом случае может поступить почти так же, как PM:
создать глобаль
^GT(дитя)=отец:мать
и далее работать с ней ничуть не хуже чем R-программист с таблицей
13 ноя 06, 22:19    [3394661]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
okdoky

Надеюсь, вы и сами догадываетесь, что языки, ориентированные на обработку XML, удобнее для работы с иерархическими данными?

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

okdoky

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

В каком смысле?
14 ноя 06, 01:00    [3394960]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
c127
Guest
okdoky
c127

Сложные иерархические СУБД как раз сейчас обсуждаются в соседнем топике. Вместо того, чтобы болтать языком решили бы с помощью более сложного иерархического ХМЛ-я задачи с авиабилетами или со студентами-преподавателиями, глядишь кто-нибудь и заинтересовался бы зигзагом. А так вряд ли что-нибудь получится с продвижением устаревшей технологии на рынок, несмотря на титанические усилия продвигающих.
Это вы XML обзываете устаревшей технологией? А что тогда говорить про таблицы, которые вы так усердно защищаете?

Лучше ничего не говорите о таблицах, в которых Вы мало смыслите. ХМЛ это иерархическая структура данных, которая появилась до реляционной модели, но очень быстро выяснилось, что практические задачи в виде деревьев не записываются. Всё, можно забыть об иерархической структуре, за исключением очень небольшого числа очень простых случаев. А ХМЛ это очередная попытка заработать деньги за счет тех, кто ничего не слышал об иерархических БД, об их проблемах и о том, что это уже проходили.

okdoky
Надеюсь, вы и сами догадываетесь, что языки, ориентированные на обработку XML, удобнее для работы с иерархическими данными?

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

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

Представьте как будет решаться задача перехода от узла 1 к узлам 4, 5 и ниже. Вы не сможете обойтись без того, чтобы не сделать операцию выборки промежуточных вершин 2, 3. В современных реализациях XML в «поле зрения» будут находится сразу все вершины подчиненные 1 и это выполняется за одно обращение к внешнему устройству....

Оригинальное утверждение было:
"Эта система работает быстрее чем любая РСУБД, особенно с данными имеющими иерархическую зависимость."
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=354796&pg=3#3386388

Т.е. Zigzag всегда быстрее чем РСУБД, а когда с деревьями, так тем более. Вот и не съезжайте на деревья, расскажте о том, на основании каких данных Вы выяснили, что Zigzag "работает быстрее чем любая РСУБД" на любой задаче.
14 ноя 06, 02:58    [3395028]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
43210
SergSuper

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

Ну вот пусть господин okdoky на XML и изобразит. А то на животных у него хорошо получается, пусть к людям перейдёт
14 ноя 06, 10:01    [3395480]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
okdoky
Member

Откуда:
Сообщений: 349
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 несложно. Для этого используются и сервера приложений...
14 ноя 06, 13:15    [3397253]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
Мимо пробегал...
Guest
...запрос по всем улицам на букву А. Их больше 100...
...перечислением в WHERE более чем 100 значений...
Я дико извиняюсь, но ИМХО ... WHERE SOMEFIELD Like "A*"...это совсем не то что перечисление в WHERE более чем 100 значений/ Ежели Вы так сравниваете, и на полном серьезе нам предлагаете рассматривать это как критерий истины, то... ГЫ-ГЫ-ГЫ-US ...простите не удержался.....
14 ноя 06, 13:25    [3397344]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
okdoky

Речь идет о приложениях реализованных на Zigzag.

Это то я понял. Не понял почему они лучше для тех кто работает с мобильными устройствами.
Чем лучше? Быстрее работает, Быстрее на ней реальную ИС разработать, Легче сопровождать? Или для мобильных устройств другие в принципе не подходят? Я это имел в виду уточнить. В чем там особенность мобильности проявляется, которая делает других хуже? Для тех кто работает немобольными устройствами, как я понял, они не лучше уже?
14 ноя 06, 13:28    [3397371]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
1024
Member

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


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

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

Хранение данных в виде иерархии позволяет легко выполнять поиск по критериям совпадающим с этой иерархией и крайне затрудняют по остальным параметрам. В этом смысл отказа от деревянных структур.
14 ноя 06, 13:38    [3397451]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
DocAl
Member

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

Мы проверяли на SQL такие же запросы для индексированной таблицы с перечислением в WHERE более чем 100 значений. Они выполняются медленнее в 1,5 раза для MS Access. Кстати, MS Access работала в 2 раза быстрее чем Interbase и чуть быстрее MS SQL Server. Признаю, запросы проверялись только при однопользовательском режиме. Собственно контроль за множеством пользователей реализовать на Java несложно. Для этого используются и сервера приложений...

Ну, я бы не сказал, что оно так уж мгновенно работает. По одной букве в названии улицы оно искать вообще отказывается, по "мо" реакция была порядка двух секунд, например. Ничем не выдающийся результат, для выборки полутора тысяч объектов из 125 000. Вполне могли б и какой-нить MySQL использовать, который для хостинга куда менее экзотичен.
14 ноя 06, 13:48    [3397547]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
okdoky
Member

Откуда:
Сообщений: 349
Мимо пробегал...
...запрос по всем улицам на букву А. Их больше 100...
...перечислением в WHERE более чем 100 значений...
Я дико извиняюсь, но ИМХО ... WHERE SOMEFIELD Like "A*"...это совсем не то что перечисление в WHERE более чем 100 значений/ Ежели Вы так сравниваете, и на полном серьезе нам предлагаете рассматривать это как критерий истины, то... ГЫ-ГЫ-ГЫ-US ...простите не удержался.....
Да с запросом ... WHERE SOMEFIELD Like "A*"... SQL работает чуть быстрее, чем с перечислением. Речь идет именно о перечислении WHERE улица='А...' OR улица='А...' ...
14 ноя 06, 14:08    [3397736]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
С трудом представляю, для чего в этой задаче и на нормализованной БД может потребоваться перечисление из сотни альтернатив.
14 ноя 06, 14:16    [3397811]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
Мимо пробегал...
Guest
Афигеть :) Вы хоть сами то прикинте, скока это "чуть быстрее" на самом деле означает. "Like A*" это фактически поиск толко по первой букве,
А WHERE улица='А...' OR улица='А...' ... это точное сранение знавчения поля с искомым значением - и это для более чем для ста значений. Так что Ваше "чуть быстрее" - это ИМХО "быстрее в порядки".
14 ноя 06, 14:19    [3397833]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
Мимо пробегал...
Guest
То есть если средняя длина названия улицы = 10 символам, то точное сравнение означает 10 посимвольных сравненй. Для более чем ста значений мы получаем более 1000 сравненй. А Like "A*" ' это всего одно сравнение (первого символа). Это "чуть быстрее"?
14 ноя 06, 14:23    [3397876]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
okdoky
SergSuper
okdoky
Треп. Пример эффективного представления неограниченного в глубь дерева на основе таблиц?
Есть много вариантов
Вот например простейший
Опять треп. Где конкретный ответ (ссылка)? Это называется «запутывать следы».

okdoky, ну если Вы не знаете элементарных вещей, почему надо так неуважительно называть мои высказываниям?
Дерево можно хранить с помощью множественной модели, когда каждая ветвь рассматривается как множество и можно проверять входит ли одно множество в другое или нет. Реализации могут быть различны. Пример можно посмотреть тут.

А в ссылочке там ошибка была, правильно https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351164&pg=29#3393086
okdoky

SergSuper
А вот изобразите-ка гениалогическое дерево. Но только что б там были оба предка(мать и отец), а не только по отец.
Переверните дерево и будет вам ответ. Если серьезно, любую сеть можно представить несколькими деревьями с пересекающимися (эквивалентными) вершинами.
Т.е. в XML-е это не изобразить(надеюсь Вы сами понимаете, что перевернуть недостаточно)?
Пойдём дальше - любое дерево можно представить в виде таблицы с пересекающимися ячеками
okdoky
SergSuper
okdoky
Что такое по вашему B-tree индексация, применяемая в РСУБД?
Можно спорить как хранятся файлы, но уж индекс то данными никак не является.
…, но имеет прямое отношение к эффективному представлению или хранению.

Косвенное, косвенное. Только для ускорения получения. Ну собственно то высказывание было не моё, а спор тут чисто теоритический
okdoky

Речь идет о приложениях реализованных на Zigzag. Один из примеров справочная ОРГАНИЗАЦИИ МОСКВЫ.
Это... постеснялись бы такое показывать, что ли... я конечно понимаю что это единственное в мире что было сделано на зигзаге, но всё равно...
14 ноя 06, 14:39    [3398005]     Ответить | Цитировать Сообщить модератору
 Re: Почему только русские СУБД  [new]
okdoky
Member

Откуда:
Сообщений: 349
Мимо пробегал...
То есть если средняя длина названия улицы = 10 символам, то точное сравнение означает 10 посимвольных сравненй. Для более чем ста значений мы получаем более 1000 сравненй. А Like "A*" ' это всего одно сравнение (первого символа). Это "чуть быстрее"?
Вот поэтому я и предлагал зайти в справочную и посмотреть как будет работать Zigzag с таким большим перечислением. Тем более что запрос сделать просто, система сама предлагает список возможных улиц или других атрибутов имеющихся в текущей БД. Ну а запрос на A* в Zigzag конечно тоже можно сделать:
= организация (улица:'А'*)
С перечислением будет выглядеть так:
= организация (улица:['ааа','ббб'])
14 ноя 06, 15:22    [3398294]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить