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

Откуда: http://codearticles.ru
Сообщений: 31089
Eugenkru1

Доли секунды.

Всё, бросаю нафиг сиквел
28 янв 09, 22:09    [6750916]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Абсолют_незарегин
Guest
Забавно. Т.е. рашмор выдаст значение ПУТИН за доли секунды, даже если этого значения нет?
28 янв 09, 22:49    [6751002]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
SergSuper
Member

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

А я ещё раз повторяю для особо умных:
1. Алгоритм Rushmore был запатентован, о чём особо Подчёркнуто в Документации по Foxpro.

Может тогда процитируете что там написано? Может там и номер патента есть? Тогда попробую поискать текст
Eugenkru1

2. Патенты в "открытом доступе" есть, но в качестве законченного продукта. Ни одна фирма не будет раскрывать секреты производства и секреты технологии. Может вам ещё и секреты производства Intel Core2Duo рассказать в "свободном доступе"?

Т.е. я показал к примеру соковыжималку, но как она работает не скажу и внутрь посмотреть не дам?
Нет, тут либо секрет технологии, либо патент - одно из двух. Либо Вы это секретите (но если кто-то сделает также и запатентует, то Вам придётся платить за патент), либо патентуете и вам платят если будут использовать. Например некоторые фокусы Копперфильда запатентованы и в принципе можно эти патенты посмотреть.
Eugenkru1

3. Есть разница между понятиями: Открытие (например в физике) и Изобретение на основе какого то Открытия. Так вот Открытие действительно не патентуется и доступно всем, а Изобретение патентуется, и выдают Патент на Изобретение. Так вот мой дед сделал Открытие, потом сделал Изобретение, а потом получил Патент на Изобретение. Вокруг его открытия по сей день много споров, ибо оно противоречит классическим законам физики. Несмотря на это Изобретение реально работает.
Тогда тем более Вы должны знать что патент даётся только на Устройство. Программу тоже кстати нельзя запатентовать.
28 янв 09, 22:50    [6751004]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Изопропил
Member

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

2. Команда LOCATE FOR использует Rushmore по умолчанию. Все команды Visual Foxpro с фразой FOR используют по умолчанию оптимизацию Rushmore.
Ещё вопросы?

Не подскажете, зачем нужен рашмор для выборки одиночной записи с использованием одного индекса?
28 янв 09, 23:03    [6751021]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
SergSuper
Eugenkru1

2. Патенты в "открытом доступе" есть, но в качестве законченного продукта. Ни одна фирма не будет раскрывать секреты производства и секреты технологии. Может вам ещё и секреты производства Intel Core2Duo рассказать в "свободном доступе"?

Т.е. я показал к примеру соковыжималку, но как она работает не скажу и внутрь посмотреть не дам?
Нет, тут либо секрет технологии, либо патент - одно из двух. Либо Вы это секретите (но если кто-то сделает также и запатентует, то Вам придётся платить за патент), либо патентуете и вам платят если будут использовать. Например некоторые фокусы Копперфильда запатентованы и в принципе можно эти патенты посмотреть.
Да врет он. Или не знает. А скорее всего и то, и другое вместе. Вот ссылка на положение из патентного закона, который, кстати, приводили в соответствие с Международным патентным законом. Ни программы, ни алгоритмы вообще не подлежат патентованию.

Также, всё запатентованное не может быть засекречено. Это тогда квалифицируется как "know-how". Искать по закону по этому вопросу лениво.

ЗЫ. Народ, Вам еще не надоел этот словоблуд?
28 янв 09, 23:20    [6751052]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Senya_L
ЗЫ. Народ, Вам еще не надоел этот словоблуд?
ну раз Вы тут читаете и пишите - значит как минимум Вам не надоел :)
28 янв 09, 23:43    [6751090]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Fox5631
Guest
Копирую перевод хелпа VFP9 (о Рашмор).
Текст не форматированный. Кто хочет, читайте
здесь.

Для того, чтобы помочь вам оптимизировать производительность приложений, Visual FoxPro включает в себя технологию доступа к данным, называемую Оптимизация запросов Rushmore (Rushmore Query Optimization). Применяя технологию Rushmore, вы сможете выполнять определенные сложные табличные операции в сотни и даже тысячи раз быстрее, чем без нее.

Понимание технологии оптимизации запросов Rushmore

Технология оптимизации запросов Rushmore - это технический прием, который использует стандартные индексы Visual FoxPro для того, чтобы оптимизировать доступ к данным. Вы можете использовать Rushmore с любым индексом Visual FoxPro, включая индексы FoxPro 1.x (.idx), компактные (.idx) и составные индексы (.cdx).

Как .cdx- так и компактные .idx-индексы используют технический прием сжатия, при котором их размер становится равным одной шестой части несжатых индексов старого формата. Visual FoxPro может обработать сжатый индекс быстрее, поскольку требуется меньше времени на доступ к диску и большее число индексов будет буферизовано в памяти. Хотя оптимизация запросов Rushmore, подобно другим файловым методам доступа, извлекает преимущества из меньшего размера компактных индексов, она также хорошо работает и с индексами старых форматов.

Когда Visual FoxPro обрабатывает очень большие таблицы на компьютерах с самым минимальной объемом RAM, Rushmore не сможет работать из-за недостатка оперативной памяти. В этом случае, Visual FoxPro может отобразить предупреждающее сообщение "Not enough memory for optimization" ("Не достаточно памяти для оптимизации"). В этом случае, ваша программа хотя и будет функционировать правильно и без потери данных, но вы не получите пользы от оптимизации Rushmore при выполнении запросов.

В своей самой простой форме, Rushmore ускоряет выполнение одно-табличных команд, использующих предложения FOR (FOR clauses) для точного определения наборов записей с точки зрения существующих индексов. Кроме того, Rushmore может ускорять работу таких команд, как LOCATE и INDEX. Полный список оптимизируемых команд приведен в подразделе "Использование оптимизации запросов Rushmore при работе с таблицами".

SQL-команды Visual FoxPro используют Rushmore как основной инструмент оптимизации в многотабличном запросе, применяя для этого существующие индексы и даже создавая новые, специально созданные для этого случая (ad-hoc), индексы, что позволяет ускорить выполнение запроса.

Использование оптимизации запросов Rushmore при работе с таблицами
Используйте Rushmore для оптимизации доступа к данным в зависимости от количества затрагиваемых при этом таблиц. Если вы работаете с одиночными таблицами, то можете получить выигрыш от применения Rushmore везде, где фигурирует предложение FOR. Если вы работаете с множеством таблиц, то запросы SELECT - SQL заменяют собой всю оптимизацию Rushmore. В команде SQL Visual FoxPro сам решает, что необходимо оптимизировать запрос, и делает всю работу за вас. Вам не нужно открывать таблицы или индексы. Если SQL решит, что ему нужны индексы, то он создаст временные индексы для своего собственного использования.

При использования оптимизации запросов Rushmore
1. Для доступа к данным из одиночных таблиц применяйте предложение FOR в таких командах как AVERAGE, BROWSE или LOCATE, или используйте для обновления таблиц команды SQL. Полный список команд, в которых применяется предложение FOR, указан в таблице, приведенной ниже.
или
2. Для доступа к данным из более чем одной таблицы, применяйте команды SELECT - SQL, DELETE - SQL, и UPDATE - SQL.
Следующая таблица содержит команды, которые используют предложение FOR. Rushmore сконструирован таким образом, что скорость его работы прямо пропорциональна количеству извлекаемых записей.
Потенциально оптимизируемые команды с предложением FOR
AVERAGE
BLANK

BROWSE
CALCULATE

CHANGE
COPY TO

COPY TO ARRAY
COUNT

DELETE
DISPLAY

EDIT
EXPORT TO

INDEX
JOIN WITH

LABEL
LIST

LOCATE
RECALL

REPLACE
REPLACE FROM ARRAY

REPORT
SCAN

SET DELETED
SET FILTER

SORT TO
SUM

TOTAL TO

Если вы применяете в командах предложение scope (диапазон), то scope должна быть установлена в значения ALL (все) или REST (остальное), иначе от Rushmore не будет проку. Предложения NEXT (следующие) или RECORD (запись №...) блокируют Rushmore. Поэтому для большинства команд умалчиваемое значение scope всегда установлено в ALL и Rushmore будет работать когда вы пропускаете предложение scope.
Rushmore может использовать любые открытые индексы за исключением фильтрующих и UNIQUE (уникальных) индексов.
Замечание:

Для оптимального выполнения не устанавливайте порядок таблицы.
Создание индекса или тегов автоматически устанавливает порядок. Если Вы хотите получить от Rushmore максимальное преимущество при работе с большими наборами данных, которые должны быть определенным образом упорядочены, то выполните SET ORDER TO для того, чтобы отключить управление индексами, а затем выполните команду SORT.
Эффективная индексация для оптимизации запросов Rushmore
Rushmore не может воспользоваться всеми преимуществами индексов. Если вы применяете в команде INDEX предложение FOR, то Rushmore не сможет использовать этот индекс для оптимизации. Например, следующий оператор не может быть оптимизирован именно из-за использования в нем предложения FOR: INDEX ON ORDNUM FOR DISCOUNT > 10 TAG ORDDISC.
Кроме того, Rushmore не может использовать индекс, созданный с условием NOT. Например, это выражение может быть оптимизировано: INDEX ON DELETED() TAG DEL, а вот это - нет: INDEX ON NOT DELETED() TAG NOTDEL.
В том случае, когда вы хотите исключить из запроса удаленные записи, использование индекс, созданного в первом примере, ускорит операции, при условии, что вы установили SET DELETED в значение ON.
Работа без оптимизации запросов Rushmore
Операции поиска данных продолжаются без оптимизации Rushmore в следующих ситуациях:
• Когда Rushmore не может оптимизировать выражения из предложения FOR в потенциально оптимизируемых командах.
• Когда команда, которая может быть усилена применением Rushmore, содержит предложение WHILE.
• Когда слишком мало памяти. Поиск данных продолжается, но без оптимизации.
Отключение оптимизации запросов Rushmore
Впрочем, иногда возникает необходимость в отключении Rushmore. Когда выполняется команда, оптимизированная по этой технологии, вначале определяется набор записей, отвечающих выражению предложения FOR. Только эти записи и будут обработаны командой.
Если потенциально оптимизируемая команда модифицирует индексный ключ в предложении FOR, то набор записей, с которым оперирует Rushmore, может стать неактуальным. Отключив Rushmore, вы гарантируете себе работу с самой свежей информацией из таблицы.
Чтобы отключить Rushmore для конкретной команды
1. Примените предложение NOOPTIMIZE.
Например, следующая команда LOCATE не оптимизируется:
Копировать код

LOCATE FOR DueDate < {^1998-01-01} NOOPTIMIZE
Вы можете глобально включить или отключить Rushmore для всех команд, получающих выгоду от Rushmore, можно командой SET OPTIMIZE.
Для глобального отключения Rushmore
1. Воспользуйтесь следующим кодом:
Копировать код

SET OPTIMIZE OFF
Для глобального включения Rushmore
1. Воспользуйтесь следующим кодом:
Копировать код

SET OPTIMIZE ON
По умолчанию оптимизация Rushmore установлена в ON.
Оптимизация выражений Rushmore
Технология Rushmore зависит от наличия в предложении FOR или в предложении SQL WHERE основного оптимизируемого выражения. Основное оптимизируемое выражение может составлять все выражение или его часть. А еще, вы можете скомбинировать основные выражения для того, чтобы сформировать составное оптимизируемое выражение.
Создание основных оптимизируемых выражений
Основное оптимизируемое выражение принимает одну из двух следующих форм:
Копировать код

eIndex relOp eExp

или
Копировать код

eExpr relOp eIndex

Основное оптимизируемое выражение имеет следующие характеристики:
• eIndex точно соответствует выражению на котором был создан индекс.
• eExpr это любое выражение, которое может включать переменные и поля из других не связанных таблиц.
• relOp это один из следующих реляционных операторов: <, >, =, <=, >=, <>, #, ==, or !=. Можно также воспользоваться функциями ISNULL( ), BETWEEN( ) или INLIST( ) (или их SQL-эквивалентами, такими как IS NULL и т.п.).
Можно использовать функции BETWEEN( ) or INLIST( ) в следующих двух формах:
Копировать код

BETWEEN(eIndex, eExpr, eExpr)
или
Копировать код

INLIST(eIndex, eExpr [, eExpr, eExpr, ...])
Замечание:

Функции ISBLANK() и EMPTY() не оптимизируются Rushmore.
Если вы создаете индексы firstname, custno, UPPER(lastname) и hiredate, то каждое из следующих выражений будет оптимизируем:
Копировать код

firstname = "Fred"
custno >= 1000
UPPER(lastname) = "SMITH"
hiredate < {^1997-12-30}
Оптимизируемые выражения могут содержать переменные и функции, которые приводятся к определенному значению. Например, если используется индекс addr и вы дали команду STORE "WASHINGTON AVENUE" TO cVar, то следующие операторы так же являются основными оптимизируемыми выражениями:
Копировать код

ADDR = cVar
ADDR = SUBSTR(cVar,8,3)
Осмысление того, когда запросы могут быть оптимизированы
Важно понимать когда запросы будут оптимизированы и когда не будут. Visual FoxPro оптимизирует условия поиска, отыскивая точное совпадение между левой стороной выражения фильтра и индексным ключевым выражением. Следовательно, Rushmore может оптимизировать выражение только в том случае, если вы ведете поиск точно по такому же выражению, которое применено в индексе.
Например, представьте себе, что вы просто создали таблицу и добавляете первый индекс, используя следующую команду:
Копировать код

USE CUSTOMERS
INDEX ON UPPER(cu_name) TAG name
Следующая команда не оптимизируемая, потому что поисковое выражение основано на поле cu_name, а не на выражении индекса:
Копировать код

SELECT * FROM customers WHERE cu_name ="ACME"
Поэтому вы должны создать оптимизируемое выражение, использующее команду, в которой поисковое выражение точно соответствует индексному выражению, а именно:
Копировать код

SELECT * FROM customers WHERE UPPER(cu_name) = "ACME"
Совет:

Для того, чтобы определить уровень оптимизации Rushmore, используйте функцию SYS(3054).

Комбинирование основных оптимизируемых выражений
Вы можете комбинировать простые или сложные выражения, основанные на предложениях FOR или WHERE для того, чтобы увеличивать скорость поиска данных, при условии, что FOR-выражения имеют характеристики основных оптимизируемых выражений.
Основные выражения могут быть оптимизируемыми. Вы можете скомбинировать выражения при помощи логических операторов AND, OR, and NOT для получения сложного выражения в предложении FOR, которое также может быть оптимизируемым. Если одно или больше основных выражений не оптимизируемые, то сложное выражение может быть частично оптимизируемым или совсемне оптимизируемым.
Инструкцией определено, что если выражение формировалось из основных оптимизируемых или неоптимизируемых выражений, то оно может быть полностью оптимизируемым, частично оптимизируемым, или не оптимизируемым. Следующая таблица суммирует в себе правила оптимизации запроса Rushmore.
Комбинирование основных выражений
Основное выражение Оператор Основное выражение Результат запроса
Оптимизируемое AND Оптимизируемое Полностью оптимизируемый
Оптимизируемое OR Оптимизируемое Полностью оптимизируемый
Оптимизируемое AND Не оптимизируемое Частично оптимизируемый
Оптимизируемое OR Не оптимизируемое Не оптимизируемый
Не оптимизируемое AND Не оптимизируемое Не оптимизируемый
Не оптимизируемое OR Не оптимизируемое Не оптимизируемый
— NOT Оптимизируемое Полностью оптимизируемый
— NOT Не оптимизируемое Не оптимизируемый
Вы можете применить оператор AND для комбинирования двух оптимизируемых выражений в одно полностью оптимизируемое выражение:
Копировать код

FIRSTNAME = "FRED" AND HIREDATE < {^1997-12-30} && Оптимизируемое
В следующем примере оператор OR комбинирует основное оптимизируемое выражение с неоптимизируемым выражением, для получения не оптимизируемого выражения:
Копировать код

FIRSTNAME = "FRED" OR "S" $ LASTNAME && Не оптимизируемое
Применение оператора NOT для оптимизируемого выражения создает полностью оптимизируемое выражение:
Копировать код

NOT FIRSTNAME = "FRED" && Полностью оптимизируемое
Вы можете также использовать круглые скобки, чтобы группировать комбинации основных выражений.
Комбинирование сложных выражений
Аналогично комбинированию основных выражений, вы можете объединять сложные выражения для создания еще более сложных выражений, которые будут полностью оптимизируемыми, частично оптимизируемыми, или не оптимизируемыми. Далее снова можно составлять еще более сложные выражения, которые снова могут быть полностью или частично оптимизируемыми, или неоптимизируемым вовсе. В следующей таблице приведены варианты комбинирования сложных выражений. Эти правила справедливы и для группировки выражений с помощью скобок.
Комбинирование сложных выражений
Выражение Оператор Выражение Результат
Полностью оптимизируемое AND Полностью оптимизируемое Полностью оптимизируемое
Полностью оптимизируемое OR Полностью оптимизируемое Полностью оптимизируемое
Полностью оптимизируемое AND Частично оптимизируемое Частично оптимизируемое
Полностью оптимизируемое OR Частично оптимизируемое Частично оптимизируемое
Полностью оптимизируемое AND Не оптимизируемое Частично оптимизируемое
Полностью оптимизируемое OR Не оптимизируемое Не оптимизируемое
— NOT Полностью оптимизируемое Полностью оптимизируемое
Частично оптимизируемое AND Частично оптимизируемое Частично оптимизируемое
Частично оптимизируемое OR Частично оптимизируемое Частично оптимизируемое
Частично оптимизируемое AND Не оптимизируемое Частично оптимизируемое
Частично оптимизируемое OR Не оптимизируемое Не оптимизируемое
— NOT Частично оптимизируемое Не оптимизируемое
Не оптимизируемое AND Не оптимизируемое Не оптимизируемое
Не оптимизируемое OR Не оптимизируемое Не оптимизируемое
— NOT Не оптимизируемое Не оптимизируемое
Вы можете скомбинировать полностью оптимизируемые выражения с помощью оператора OR для создания выражения, которое также будет полностью оптимизируемым:
Копировать код

* Полностью оптимизируемое выражение
(FIRSTNAME = "FRED" AND HIREDATE < {^1997-12-30}) ;
OR (LASTNAME = "" AND HIREDATE > {^1996-12-30})
Для создания частично оптимизируемых выражений скомбинируйте полностью оптимизируемое выражение с неоптимизируемым с помощью оператора AND:
Копировать код

* Частично оптимизируемое выражение
(FIRSTNAME = "FRED" AND HIREDATE < {^1997-12-30}) ;
AND "S" $ LASTNAME
Частично оптимизируемые выражения можно комбинировать для создания также частично оптимизируемого выражения:
Копировать код

* Частично оптимизируемое выражение
(FIRSTNAME = "FRED" AND "S" $ LASTNAME) ;
OR (FIRSTNAME = "DAVE" AND "T" $ LASTNAME)
Результатом комбинирования не оптимизируемых выражений также будет не оптимизируемое выражение:
Копировать код

* Не оптимизируемое выражение
("FRED" $ FIRSTNAME OR "S" $ LASTNAME) ;
OR ("MAIN" $ STREET OR "AVE" $ STREET)
См. также
Ссылки
Оптимизация приложений
Оптимизация вашей системы
Команда LOCATE
Команда INDEX
29 янв 09, 00:01    [6751117]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
SergSuper
Senya_L
ЗЫ. Народ, Вам еще не надоел этот словоблуд?
ну раз Вы тут читаете и пишите - значит как минимум Вам не надоел :)
Просто невозможно не заглянуть, когда топик разросся на столько страниц за пару дней. :) А этот Eugenkru1 надоел в аккурат 9 страниц назад
29 янв 09, 00:05    [6751125]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Подпольщик
Guest
модератор

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

Гуд, Фошыст перешёл к партизанам и теперь называется подпольщиком. Прошу не сильно пинать.
29 янв 09, 01:19    [6751219]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Eugenkru1
Member [заблокирован]

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

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

Гуд, Фошыст перешёл к партизанам и теперь называется подпольщиком. Прошу не сильно пинать.

Ага, 9 страниц назад меня забанили.
Сейчас я смастерю таблицу из милиарда записей и меня разбанят.
Таблица из милиарда проиндексированных записей в каждой из которых будет уникальное значение. Затем я сделаю поиск любого из значений в базе и напишу Оленеводам время поиска!
СКОРОСТЬ поиска нескольких записей согласно описанию Rushmore ПРЯМОПРОПОРЦИОНАЛЬНА количеству извлекаемых записей! Значит ВРЕМЯ извлечения нескольких записей меньше чем одной!
Круто?
29 янв 09, 01:56    [6751248]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Eugenkru1
Member [заблокирован]

Откуда:
Сообщений: 103
Короче сделал пока что DBF 160 милионов записей. Компутер AMD Turion 1,6 GHz.
Заполнил все записи уникальными текстовыми значениями. DBF получился 1,7GB
Проиндексировал получил CDX.
Далее берём любое существующее значение из 160 милионов записей этой таблицы: '_2KK2S86M9'.

Выходим и Foxpro для чистоты эксперимента, входим снова и набираем запрос SQL:
SELECT Фамилия from фамилии WHERE Фамилия='_2KK2S86M9' INTO CURSOR результат
Время выполнения запроса составляет 0,06 секунды!

Меняем выражение с целью найти больше записей
SELECT Фамилия from фамилии WHERE Фамилия='_2KK2S86M' INTO CURSOR результат
Время выполнения запроса составляет 0,09 секунды!
Специально для Оленеводов могу проверить на 1 милиарде записей!
Теперь понятно что такое Rushmore?
29 янв 09, 04:21    [6751297]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Интересно
Guest
А сам автор топика, с выбором СУБД, уже определился или еще нет?
29 янв 09, 04:42    [6751302]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Eugenkru1
Короче сделал пока что DBF 160 милионов записей. Компутер AMD Turion 1,6 GHz.
Заполнил все записи уникальными текстовыми значениями. DBF получился 1,7GB
Проиндексировал получил CDX.
Далее берём любое существующее значение из 160 милионов записей этой таблицы: '_2KK2S86M9'.

Выходим и Foxpro для чистоты эксперимента, входим снова и набираем запрос SQL:
SELECT Фамилия from фамилии WHERE Фамилия='_2KK2S86M9' INTO CURSOR результат
Время выполнения запроса составляет 0,06 секунды!

Меняем выражение с целью найти больше записей
SELECT Фамилия from фамилии WHERE Фамилия='_2KK2S86M' INTO CURSOR результат
Время выполнения запроса составляет 0,09 секунды!
Специально для Оленеводов могу проверить на 1 милиарде записей!
Теперь понятно что такое Rushmore?


Да пипец просто, какая скорость...

Поиск в одной табличке по уникальному индексу одного значения... Вам, батенька, с такими тестами на первые места в tpc.org.

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

По поводу поиска по индексу:

SELECT
  SUM(rows)
FROM
  sys.partitions
WHERE
  object_id = OBJECT_ID('dbo.Event') AND
  index_id IN (0, 1)

-------------------- 
164888594

(1 row(s) affected)


SELECT
  Moment
FROM
  dbo.Event
WHERE
  OwnerObjectID = 855822840000

Moment                                                 
------------------------------------------------------
2008-10-28 16:14:27.437
2008-10-28 16:14:27.860
2008-10-29 11:31:32.080
2008-10-29 11:31:32.097
2008-10-29 11:31:32.190

(5 row(s) affected)


Время выполнения SQL Server:
Время ЦП = 0 мс, истекшее время = 1 мс.
Время синтаксического анализа и компиляции SQL Server:
время ЦП = 0 мс, истекшее время = 1 мс.

А, да... Давайте, как, покажите нам, как фокс умеет на SMP работать. Покажите нам, что-нибудь типа:

StmtText                                                                                                                                                                                                                                                                                                                                
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|--Compute Scalar(DEFINE:([Expr1009]=CONVERT_IMPLICIT(int,[globalagg1017],0), [Expr1010]=CASE WHEN [globalagg1019]=(0) THEN NULL ELSE [globalagg1021] END, [Expr1011]=CASE WHEN [globalagg1023]=(0) THEN NULL ELSE [globalagg1025] END))
|--Parallelism(Gather Streams, ORDER BY:([Expr1008] ASC))
|--Stream Aggregate(GROUP BY:([Expr1008]) DEFINE:([globalagg1017]=SUM([partialagg1016]), [globalagg1019]=SUM([partialagg1018]), [globalagg1021]=SUM([partialagg1020]), [globalagg1023]=SUM([partialagg1022]), [globalagg1025]=SUM([partialagg1024])))
|--Sort(ORDER BY:([Expr1008] ASC))
|--Parallelism(Repartition Streams, Hash Partitioning, PARTITION COLUMNS:([Expr1008]))
|--Hash Match(Partial Aggregate, HASH:([Expr1008]), RESIDUAL:([Expr1008] = [Expr1008]) DEFINE:([partialagg1016]=COUNT(*), [partialagg1018]=COUNT_BIG([Expr1012]), [partialagg1020]=SUM([Expr1012]), [partialagg1022]=COUNT_BIG([Expr1013]), [partialagg1024]=SUM([Expr1013])))
|--Hash Match(Inner Join, HASH:([O].[PersonID])=([PO].[ID]), RESIDUAL:([data].[dbo].[Object].[ID] as [PO].[ID]=[data].[dbo].[Operation].[PersonID] as [O].[PersonID]))
|--Bitmap(HASH:([O].[PersonID]), DEFINE:([Bitmap1028]))
| |--Parallelism(Repartition Streams, Hash Partitioning, PARTITION COLUMNS:([O].[PersonID]))
| |--Hash Match(Inner Join, HASH:([OP].[ID])=([O].[ID]), RESIDUAL:([data].[dbo].[OperationPosting].[ID] as [OP].[ID]=[data].[dbo].[Operation].[ID] as [O].[ID]))
| |--Parallelism(Repartition Streams, Hash Partitioning, PARTITION COLUMNS:([OP].[ID]))
| | |--Index Scan(OBJECT:([data].[dbo].[OperationPosting].[OperationPosting_PlacementPersonID_XIF2] AS [OP]))
| |--Parallelism(Repartition Streams, Hash Partitioning, PARTITION COLUMNS:([O].[ID]))
| |--Compute Scalar(DEFINE:([Expr1008]=datepart(month,[data].[dbo].[Operation].[DocDate] as [O].[DocDate])))
| |--Clustered Index Scan(OBJECT:([data].[dbo].[Operation].[Operation_ID_XPK] AS [O]), WHERE:([data].[dbo].[Operation].[DocDate] as [O].[DocDate]>='2008-01-01 00:00:00.000' AND [data].[dbo].[Operation].[DocDate] as [O].[DocDate]<='2008-12-31 00:00:00.000'))
|--Compute Scalar(DEFINE:([Expr1012]=CASE WHEN [data].[dbo].[Object].[ObjectTypeID] as [PO].[ObjectTypeID]=(88) THEN (1) ELSE NULL END, [Expr1013]=CASE WHEN [data].[dbo].[Object].[ObjectTypeID] as [PO].[ObjectTypeID]=(87) THEN (1) ELSE NULL END))
|--Parallelism(Repartition Streams, Hash Partitioning, PARTITION COLUMNS:([PO].[ID]), WHERE:(PROBE([Bitmap1028])=TRUE) [IN ROW])
|--Index Scan(OBJECT:([data].[dbo].[Object].[Object_ObjectTypeID_XIF2] AS [PO]))

(18 row(s) affected)
29 янв 09, 08:34    [6751428]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
pkarklin
Простите, откуда во втором случае "больше записей", если все значение уникальны?


Он по префиксу ищет. Есть в фоксе такая милая особенность в сравнении строк
Интересно как хваленый рашмор справится с like '%строка' ?

[quote]СКОРОСТЬ поиска нескольких записей согласно описанию Rushmore ПРЯМОПРОПОРЦИОНАЛЬНА количеству извлекаемых записей! [/quote]

глыбако
Кнут пошел нервно курить, надо дома алтарчик рашмору соорудить :)
29 янв 09, 08:51    [6751474]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Gluk (Kazan)
Он по префиксу ищет. Есть в фоксе такая милая особенность в сравнении строк


Типа 'Бла-Бла-Бла%'. Понятно...
29 янв 09, 09:00    [6751492]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Fox5631
Guest
pkarklin,
а что с чем ты сравниваешь? Тебе ж сказали, SQLServer использует тот же Рашмор. MS для того FoxPro и покупал, чтобы Рашмор себе забрать. Это было сказано несколько страниц назад.

Ясно, что на очень сложных выборках сервер выиграет. Для того его и используют.
Для более простых выборок он совсем не нужен. Хотя бы потому, что еще тратятся ресурсы и время на перегон данных с сервера на клиент и обратно.
29 янв 09, 09:38    [6751614]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Fox5631
... Тебе ж сказали, SQLServer использует тот же Рашмор. MS для того FoxPro и покупал, чтобы Рашмор себе забрать. Это было сказано несколько страниц назад.

Несколько страниц назад также спрашивалось - на чем основано сиё утверждение?

Сообщение было отредактировано: 29 янв 09, 09:54
29 янв 09, 09:53    [6751681]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Он явно хочет посравниваться с Oracle или MySQL
29 янв 09, 10:03    [6751722]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Изопропил
Member

Откуда:
Сообщений: 31627
Fox5631
Хотя бы потому, что еще тратятся ресурсы и время на перегон данных с сервера на клиент и обратно.


Сильный ход. Рашмор позволяет получать данные с файлового сервера(dbf и cdx) не передавая их по сети.
29 янв 09, 10:13    [6751758]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Подпольщик
Guest
Gluk (Kazan), прямо любопытно, что даст PostgreSQL на таблице с 1,0 ГигаЗаписью.
Сегодня или завтра попробую.
29 янв 09, 10:15    [6751769]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Подпольщик
Gluk (Kazan), прямо любопытно, что даст PostgreSQL на таблице с 1,0 ГигаЗаписью.
Сегодня или завтра попробую.


Не надо, скорее всего враги туда тоже тайно встроили рашмор
29 янв 09, 10:35    [6751858]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
Хачу рашмор в сиквеле!!!

29 янв 09, 10:38    [6751868]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
МСУ
Хачу рашмор в сиквеле!!!


Рашмор - он не в клозетах серверах, он в головах!!!
29 янв 09, 10:45    [6751896]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
skelet
Member [заблокирован]

Откуда: moskau
Сообщений: 5549
SergSuper
МСУ
Хачу рашмор в сиквеле!!!


Рашмор - он не в клозетах серверах, он в головах!!!


Жжете народ! Сегодня же не пятницо вроде ещё ))
29 янв 09, 11:06    [6752014]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Fox5631
pkarklin,
а что с чем ты сравниваешь? Тебе ж сказали, SQLServer использует тот же Рашмор. MS для того FoxPro и покупал, чтобы Рашмор себе забрать. Это было сказано несколько страниц назад.


Ага, ага... Особенно приведенный план запроса это рашмор показывает...

29 янв 09, 11:13    [6752047]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 75   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить