Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 14 15 16 17 18 19 20 21 [22] 23   вперед  Ctrl
 Re: MSSQL или Oracle  [new]
Chabster
Member

Откуда:
Сообщений: 12
softwarer
А было ли написано? Вы случайно индекс по функции с user-defined индексом не спутали?

нет.
softwarer
Вы это о чем? Разве в MS оптимизатор не умеет пользоваться такими индексами?

Я бы сказал, что не умеет :))

CREATE FUNCTION f_BeginsWithA(@STR VARCHAR)
RETURNS VARCHAR(100)
WITH SCHEMABINDING
AS
BEGIN
IF @STR LIKE 'a%' RETURN 'YES'
RETURN 'NO'
END

GO

SET NOCOUNT ON

IF (OBJECT_ID('T') IS NOT NULL) DROP TABLE T
CREATE TABLE T(
	ID INT PRIMARY KEY NONCLUSTERED IDENTITY,
	STR VARCHAR(100),
	IS_STR_BEGINS_WITH_a AS CASE WHEN STR LIKE 'a%' THEN 'YES' ELSE 'NO' END,
	IS_STR_BEGINS_WITH_a_FB AS dbo.f_BeginsWithA(STR)
)
CREATE INDEX IX$STR ON T(STR)
CREATE INDEX IX$IS_STR_BEGINS_WITH_a ON T(IS_STR_BEGINS_WITH_a)
CREATE INDEX IX$IS_STR_BEGINS_WITH_aFB ON T(IS_STR_BEGINS_WITH_a_FB)

DECLARE @i INT
SELECT @i = 100000
WHILE @i <> 0
	BEGIN
		INSERT INTO T(STR) VALUES(CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255))
		SELECT @i = @i - 1
	END
GO

SET STATISTICS TIME ON
PRINT 'QUERY 1'
SELECT * FROM T WITH (INDEX(IX$IS_STR_BEGINS_WITH_aFB)) WHERE dbo.f_BeginsWithA(STR) = 'YES'
PRINT 'QUERY 2'
SELECT * FROM T WHERE dbo.f_BeginsWithA(STR) = 'YES'
PRINT 'QUERY 3'
SELECT * FROM T WHERE CASE WHEN STR LIKE 'a%' THEN 'YES' ELSE 'NO' END = 'YES'
PRINT 'QUERY 4'
SELECT * FROM T WHERE IS_STR_BEGINS_WITH_a = 'YES'
PRINT 'QUERY 5'
SELECT * FROM T WHERE IS_STR_BEGINS_WITH_a_FB = 'YES'

GO

SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 1 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 1 ms.
QUERY 1

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 1 ms.

(763 row(s) affected)

SQL Server Execution Times:
CPU time = 20 ms, elapsed time = 163 ms.
QUERY 2

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 1 ms.

(763 row(s) affected)

SQL Server Execution Times:
CPU time = 14871 ms, elapsed time = 38306 ms.
QUERY 3

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 1 ms.

(764 row(s) affected)

SQL Server Execution Times:
CPU time = 391 ms, elapsed time = 1313 ms.
QUERY 4

SQL Server Execution Times:
CPU time = 10 ms, elapsed time = 12 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 1 ms.

(764 row(s) affected)

SQL Server Execution Times:
CPU time = 340 ms, elapsed time = 736 ms.
QUERY 5

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 1 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 1 ms.

(763 row(s) affected)

SQL Server Execution Times:
CPU time = 15352 ms, elapsed time = 37800 ms.

Плачевно, да.

Во всех случаях - Table Scan.

И не надо говорить, что "а вот с функцией UPPER индекс используется", я вкурсе :)
10 фев 07, 21:22    [3766618]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
Очередной ниспровергатель пришел. Не имеющий ни малейшего понятия о том, как работает оптимизатор в MSSQL. С чего-то вдруг решил, что для выполнения первых 3 запросов оптимизатор должен воспользоваться индексами на вычисляемые поля. Наверное потому, что очень хочется. Действительно, почему бы оптимизатору по заданным условиям не пробежаться по всем индексам и не проверить, а не совпадают ли синтаксически их выражение к тому, что задано в упомянутых условиях. Готов допустить, что есть более совершенные оптимизаторы, которые умеют это делать, но, увы, MSSQL к таковым не относится. Хотя, не скрою, хотелось бы, узнать бы только цену...

Остались последние 2 запроса. Казалось бы, с ними то что не так ? Для этого вместо времени исполнения стоило бы взглянуть на соотношения IO для данных запросов и их же, но с заданным хинтом соответствующих индексов, наподобие как в первом запросе, которые выполнятся значительно быстрее. И выясним, что количество логических чтений, а при "холодном" кэше - фактически физических, в случае использования индексов окажется значительно выше. С точки зрения MSSQL-оптимизатора, обращения к диску стоят дороже, чем использование процессора. Поэтому потенциально гораздо дешевле просто просканировать таблицу. Вот такая вот печальная история.

Остается вопрос, а почему же чтений-то больше ? Очень бы хотелось задать этот вопрос ниспровергателю в качестве домашнего задания, но боюсь, в свете предыдущих заявлений, он не справится. Хотя кто знает, может еще не все потеряно ?
11 фев 07, 00:26    [3767019]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
ChA
Готов допустить, что есть более совершенные оптимизаторы, которые умеют это делать, но, увы, MSSQL к таковым не относится. Хотя, не скрою, хотелось бы, узнать бы только цену...

Хм... как-то не вижу там заметной "цены", если не пытаться делать суперпродвинутого анализа. Ну а так -

SQL> create table test_fbi ( a, b, c ) as select rownum, rownum, rownum from dual connect by level <= 1000000 ;

Table created

SQL> create index test_fbi_i on test_fbi ( a + b + c ) ;

Index created

SQL> exec dbms_stats.gather_schema_stats ( ownname => user ) ;

PL/SQL procedure successfully completed

SQL> alter table test_fbi modify a not null modify b not null modify c not null ;

Table altered

SQL> explain plan for
  2  select a + b + c from test_fbi ;

Explained

SQL> select * from table ( dbms_xplan.display ) ;

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3327195276
--------------------------------------------------------------------------------
| Id  | Operation            | Name       | Rows  | Bytes | Cost (%CPU)| Time
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |            |   999K|    14M|   451   (1)| 00:00:0
|   1 |  INDEX FAST FULL SCAN| TEST_FBI_I |   999K|    14M|   451   (1)| 00:00:0
--------------------------------------------------------------------------------

8 rows selected

SQL> explain plan for
  2  select * from test_fbi where a + b + c < 100 ;

Explained

SQL> select * from table ( dbms_xplan.display ) ;

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 1296792208
--------------------------------------------------------------------------------
| Id  | Operation                   | Name       | Rows  | Bytes | Cost (%CPU)|
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |            |     1 |    15 |     4   (0)|
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST_FBI   |     1 |    15 |     4   (0)|
|*  2 |   INDEX RANGE SCAN          | TEST_FBI_I |     1 |       |     3   (0)|
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("A"+"B"+"C"<100)

14 rows selected

SQL> explain plan for
  2  select * from test_fbi where a + b < 100 - c ;

Explained

SQL> select * from table ( dbms_xplan.display ) ;

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 206999037
------------------------------------------------------------------------------
| Id  | Operation         | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |          | 49993 |   732K|   576   (6)| 00:00:07 |
|*  1 |  TABLE ACCESS FULL| TEST_FBI | 49993 |   732K|   576   (6)| 00:00:07 |
------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("A"+"B"<100-"C")

13 rows selected

ChA
Остается вопрос, а почему же чтений-то больше ?

Плохая кластеризация, полагаю?
11 фев 07, 00:50    [3767074]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
softwarer
Хм... как-то не вижу там заметной "цены", если не пытаться делать суперпродвинутого анализа. Ну а так -

...
Неплохо, в MSSQL(2K) это делается только через вычисляемые поля, то бишь индексы по произвольному выражению, увы, невозможны, только по полям. Создай именованное выражение в виде поля и вперед.
Когда-то давно с возможностью создавать индекс по выражению столкнулся еще в DOS-овском FoxPro, иногда было очень удобно. Более того, была возможность создать индекс с учетом фильтра, т.е., можно было сделать нечто вроде INDEX ON (A + B) FOR (C + D > 0).
А с пользовательскими функциями в индексах Oracle так же хорошо справляется ?
softwarer
Плохая кластеризация, полагаю?
Там она вообще отсутствует :) Вообще-то мне хотелось услышать ответ от ниспровергателя. Может он меня еще чем-нибудь поразил бы...
11 фев 07, 01:46    [3767149]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
ChA
А с пользовательскими функциями в индексах Oracle так же хорошо справляется ?

Да в общем-то нет разницы, единственно требуется, чтобы функция была детерминированной (то есть ее результат вычислялся опираясь на аргументы, а не на глобальные переменные и прочие волатильные факторы).
11 фев 07, 01:57    [3767152]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
softwarer
Да в общем-то нет разницы, единственно требуется, чтобы функция была детерминированной (то есть ее результат вычислялся опираясь на аргументы, а не на глобальные переменные и прочие волатильные факторы).
Понятно. В MSSQL аналогичные требования по детерминированности, без него смысл индекса просто исчезает. В этом смысле показательно также ограничение
BOL
Any float expression is considered nonprecise and cannot be a key of an index; a float expression can be used in an indexed view but not as a key. This is true also for computed columns. Any function, expression, user-defined function, or view definition is considered non-deterministic if it contains any float expressions, including logical ones (comparisons).
11 фев 07, 02:23    [3767161]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Chabster
Member

Откуда:
Сообщений: 12
ChA
Очередной ниспровергатель пришел. Не имеющий ни малейшего понятия о том, как работает оптимизатор в MSSQL. С чего-то вдруг решил, что для выполнения первых 3 запросов оптимизатор должен воспользоваться индексами на вычисляемые поля. Наверное потому, что очень хочется. Действительно, почему бы оптимизатору по заданным условиям не пробежаться по всем индексам и не проверить, а не совпадают ли синтаксически их выражение к тому, что задано в упомянутых условиях. Готов допустить, что есть более совершенные оптимизаторы, которые умеют это делать, но, увы, MSSQL к таковым не относится. Хотя, не скрою, хотелось бы, узнать бы только цену...

Враки. Враки. Враки. Хочется, точней в этом смысл индексов, - не трогая запросы добится улучшения произвоительности. Именно об этом я и говорю - оптимизатор MSSQL не умеет пользоватся функциями своего же ядра. Именно поэтому вместо одного большого запроса пишут километровые скрипты с временными таблицами, из которых частенько удаляют строки и т.д.
ChA

Остались последние 2 запроса. Казалось бы, с ними то что не так ? Для этого вместо времени исполнения стоило бы взглянуть на соотношения IO для данных запросов и их же, но с заданным хинтом соответствующих индексов, наподобие как в первом запросе, которые выполнятся значительно быстрее. И выясним, что количество логических чтений, а при "холодном" кэше - фактически физических, в случае использования индексов окажется значительно выше. С точки зрения MSSQL-оптимизатора, обращения к диску стоят дороже, чем использование процессора. Поэтому потенциально гораздо дешевле просто просканировать таблицу. Вот такая вот печальная история.

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


Я специально удалил SET STATISTIC IO, но ты мог бы и проверить :)
11 фев 07, 12:10    [3767349]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
Chabster
Хочется, точней в этом смысл индексов, - не трогая запросы добится улучшения произвоительности.
Угу. Как я Вас понимаю. А еще лучше, если бы и запросы писать не приходилось.
Chabster
ChA
Остается вопрос, а почему же чтений-то больше ? Очень бы хотелось задать этот вопрос ниспровергателю в качестве домашнего задания,
но боюсь, в свете предыдущих заявлений, он не справится. Хотя кто знает, может еще не все потеряно ?


Я специально удалил SET STATISTIC IO, но ты мог бы и проверить :)
В общем, приблизительно это и ожидалось. Очередной треп вместо аргументов.
USE tempdb
GO
SET ANSI_NULLS, ANSI_PADDING, ANSI_WARNINGS, ARITHABORT, CONCAT_NULL_YIELDS_NULL, QUOTED_IDENTIFIER, NOCOUNT ON
SET NUMERIC_ROUNDABORT OFF
GO

CREATE FUNCTION f_BeginsWithA(@STR VARCHAR)
RETURNS VARCHAR(100)
WITH SCHEMABINDING
AS
BEGIN
IF @STR LIKE 'a%' RETURN 'YES'
RETURN 'NO'
END
GO

IF (OBJECT_ID('T') IS NOT NULL) DROP TABLE T
CREATE TABLE T(
	ID INT PRIMARY KEY NONCLUSTERED IDENTITY,
	STR VARCHAR(100),
	IS_STR_BEGINS_WITH_a AS CASE WHEN STR LIKE 'a%' THEN 'YES' ELSE 'NO' END,
	IS_STR_BEGINS_WITH_a_FB AS dbo.f_BeginsWithA(STR)
)
DECLARE @i INT
SELECT @i = 100000
WHILE @i <> 0
	BEGIN
		INSERT INTO T(STR) VALUES(CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255) + CHAR(RAND() * 255))
		SELECT @i = @i - 1
	END

CREATE INDEX IX$STR ON T(STR)
CREATE INDEX IX$IS_STR_BEGINS_WITH_a ON T(IS_STR_BEGINS_WITH_a)
CREATE INDEX IX$IS_STR_BEGINS_WITH_aFB ON T(IS_STR_BEGINS_WITH_a_FB)
GO

SET STATISTICS TIME ON
SET STATISTICS IO ON
PRINT 'Query 1'
SELECT * FROM T WHERE IS_STR_BEGINS_WITH_a = 'YES'
PRINT 'Query 2'
SELECT * FROM T WITH(INDEX(IX$IS_STR_BEGINS_WITH_a)) WHERE IS_STR_BEGINS_WITH_a = 'YES'
PRINT 'Query 3'
SELECT * FROM T WHERE IS_STR_BEGINS_WITH_a_FB = 'YES'
PRINT 'Query 4'
SELECT * FROM T WITH(INDEX(IX$IS_STR_BEGINS_WITH_aFB)) WHERE IS_STR_BEGINS_WITH_a_FB = 'YES'

GO
SET STATISTICS TIME OFF
SET STATISTICS IO OFF
DROP TABLE T
DROP FUNCTION dbo.f_BeginsWithA
Результат:

Table 'T'. Scan count 1, logical reads 428, physical reads 0, read-ahead reads 0.

SQL Server Execution Times:
CPU time = 391 ms, elapsed time = 461 ms.
Query 2

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

Table 'T'. Scan count 1, logical reads 807, physical reads 0, read-ahead reads 0.

SQL Server Execution Times:
CPU time = 109 ms, elapsed time = 174 ms.
Query 3

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.

Table 'T'. Scan count 1, logical reads 428, physical reads 0, read-ahead reads 0.

SQL Server Execution Times:
CPU time = 15469 ms, elapsed time = 16180 ms.
Query 4

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

Table 'T'. Scan count 1, logical reads 805, physical reads 0, read-ahead reads 0.

SQL Server Execution Times:
CPU time = 94 ms, elapsed time = 162 ms.

Читаем внимательно. Ответ на ранее заданные вопросы уже не жду. Уровень аргументации уже понятен.
11 фев 07, 17:46    [3768037]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
softwarer
SQL> explain plan for
2 select a + b + c from test_fbi ;
Чисто ради интереса, а если так
select b + a + c from test_fbi
? Sorry, нет Oracle под рукой.
11 фев 07, 17:54    [3768065]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
ChA
Чисто ради интереса, а если так

SQL> explain plan for select b + a + c from test_fbi ;

Explained

SQL> select * from table ( dbms_xplan.display ) ;

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3327195276
--------------------------------------------------------------------------------
| Id  | Operation            | Name       | Rows  | Bytes | Cost (%CPU)| Time
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |            |   999K|    14M|   451   (1)| 00:00:0
|   1 |  INDEX FAST FULL SCAN| TEST_FBI_I |   999K|    14M|   451   (1)| 00:00:0
--------------------------------------------------------------------------------

8 rows selected
11 фев 07, 18:02    [3768099]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
softwarer

INDEX FAST FULL SCAN| TEST_FBI_I |   999K|    14M|   451   (1)| 00:00:0
Искренне восхищен. Oracle (+)
11 фев 07, 18:10    [3768131]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
А.В.
Guest
ChA
...
Когда-то давно с возможностью создавать индекс по выражению столкнулся еще в DOS-овском FoxPro, иногда было очень удобно. Более того, была возможность создать индекс с учетом фильтра, т.е., можно было сделать нечто вроде INDEX ON (A + B) FOR (C + D > 0).
...

В PostgreSQL частичные индексы имеются, но оптимизатор может их применять только если условие в запросе совпадает тютелька-в-тютельку с условием индекса. Это действительно удобно, для больших таблиц получается такой как-бы partitioning (которого до версии 8.1 не было).
Если не ошибаюсь, в Оракле частичных индексов нет, потому что есть index partitioning.
12 фев 07, 05:11    [3769377]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

Chabster wrote:
> Враки. Враки. Враки.
С этого места - поподробнее.

>Хочется, точней в этом смысл индексов, - не трогая
> запросы добится улучшения произвоительности. Именно об этом я и говорю -
И что мешает?

> оптимизатор MSSQL не умеет пользоватся функциями своего же ядра. Именно
> поэтому вместо одного большого запроса пишут километровые скрипты с
> временными таблицами, из которых частенько удаляют строки и т.д.
Никто не без греха, надо сказать. Хотя "километровый запрос" - это
"набор частных случаев". А "частный случай", как известно - решается
значительно проще "общего случая".


Для Вашего примера на моей машинке индекс по ВК начал использоваться
после 2^6 строк в табличке T. Ну, и статистику пришлось создать.

Posted via ActualForum NNTP Server 1.3

12 фев 07, 12:30    [3770839]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Chabster
Member

Откуда:
Сообщений: 12
Кстати, еще одна интересная штука для сравнения:
MSSQL:
IF (OBJECT_ID(N'UIX_NULLS') IS NOT NULL) DROP TABLE UIX_NULLS
GO

CREATE TABLE UIX_NULLS
(
ID INT PRIMARY KEY NONCLUSTERED IDENTITY,
StrName VARCHAR(100) NULL,
Prefix INT NULL,
Suffix INT NULL
)
GO

CREATE UNIQUE INDEX UIX$UIX_NULLS__StrName ON UIX_NULLS(StrName)
CREATE UNIQUE INDEX UIX$UIX_NULLS__Prefix_Suffix ON UIX_NULLS(Prefix, Suffix)

INSERT INTO UIX_NULLS(StrName, Prefix, Suffix) VALUES('A', NULL, NULL)
INSERT INTO UIX_NULLS(StrName, Prefix, Suffix) VALUES('B', NULL, NULL)

INSERT INTO UIX_NULLS(StrName, Prefix, Suffix) VALUES(NULL, 1, 1)
INSERT INTO UIX_NULLS(StrName, Prefix, Suffix) VALUES(NULL, 2, 2)

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

Oracle подобные операции позволяет, право, видимо, лишь потому, что NULL значения не хранит в индексе со всеми вытекающими проблемами с оптимизатором и мудоханьем с "AND MyNullableFieldThatRequiresUsingIndex IS NOT NULL"
12 фев 07, 13:34    [3771355]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
kennethr
Member

Откуда:
Сообщений: 175
Chabster

Старо как мир и даже не интересно. В Oracle NULL<>NULL и поэтому
CREATE TABLE UIX_NULLS
(
ID INT PRIMARY KEY NONCLUSTERED IDENTITY,
StrName VARCHAR(100) NULL,
Prefix INT NULL,
Suffix INT NULL
)
GO

CREATE UNIQUE INDEX UIX$UIX_NULLS__StrName ON UIX_NULLS(StrName)
CREATE UNIQUE INDEX UIX$UIX_NULLS__Prefix_Suffix ON UIX_NULLS(Prefix, Suffix)
писать ошибочно.
12 фев 07, 14:15    [3771686]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
Chabster

Oracle подобные операции позволяет, право, видимо, лишь потому, что NULL значения не хранит в индексе со всеми вытекающими проблемами с оптимизатором


Ээээ... эт ты о чем вообще? В случае составных индексов Oracle строит индекс, если одно из значений - не нулловое. Соответственно - строит запрос.

А буквари нужно учить. Тогда и проблем с оптимизатором (пониманием его) - не будет.


CREATE TABLE test AS SELECT owner, objecT_name FROM  all_objects;
ALTER TABLE test MODIFY owner NULL;
UPDATE test SET owner = NULL WHERE owner = 'SYS';
CREATE INDEX test_idx ON test(owner, object_name);
ANALYZE TABLE test COMPUTE STATISTICS;
--
SELECT * FROM TEST WHERE OWNER IS NULL AND object_NAME = 'TEST';

Execution Plan
-----------------------------------------------------------------------------
| Id  | Operation        | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT |          |     1 |    21 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| TEST_IDX |     1 |    21 |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("OWNER" IS NULL AND "OBJECT_NAME"='TEST')
       filter("OBJECT_NAME"='TEST')
16 фев 07, 17:22    [3798270]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
grexhide
Member [заблокирован]

Откуда: Страна непреодолимых противоречий
Сообщений: 8553
kennethr
В Oracle NULL<>NULL и поэтому


Ответ не верный. Результат выражения NULL = NULL будет NULL. В равной степени, как и NULL <> NULL тоже будет NULL

DECLARE
  a BOOLEAN;
BEGIN
  a := NULL = NULL;
  
  IF A IS NULL THEN DBMS_output.put_line('null = null is null'); END IF;
  
  a := NULL <> NULL;
  
  IF A IS NULL THEN DBMS_output.put_line('null <> null is null'); END IF;
  
  -- íî âîò òàê
  IF NULL = NULL THEN 
    DBMS_output.put_line('a'); 
  ELSE
    DBMS_output.put_line('else 1'); 
  END IF;
  
  IF NULL <> NULL THEN 
    DBMS_output.put_line('a'); 
  ELSE
    DBMS_output.put_line('else 2'); 
  END IF;

  IF not(NULL = NULL) THEN 
    DBMS_output.put_line('a'); 
  ELSE
    DBMS_output.put_line('else 3'); 
  END IF;
  
  IF not(NULL <> NULL) THEN 
    DBMS_output.put_line('a'); 
  ELSE
    DBMS_output.put_line('else 4'); 
  END IF;
  
END;
/
null = null is null
null <> null is null
else 1
else 2
else 3
else 4


Дети, понять это не возможно. Это нужно - просто выучить!
16 фев 07, 17:34    [3798358]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
kennethr
Member

Откуда:
Сообщений: 175
grexhide
Типичное непонимание на уровне лексики. Про NULL "папаша" мне известно. И если бы вы вдумались, зачем я это написал, то вопросов не возникло бы.
19 фев 07, 07:48    [3803027]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
DamirS
Member

Откуда:
Сообщений: 181
Заранее прошу прощения, если не в тему выскажусь...
В 2005 появились аналитические функции (в Оракл они были давно).
Но... не все появилось.
Недавно мне катострофически не хватало Lead() и Last() - пришлось извращаться.
Так же MS не поддерживает sum() over( order by) - обидно, однака...

PS: вообще-то, пишу под 2000, про Оракл только читал, а 2005 только-только щупаю.
28 фев 07, 11:58    [3841887]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
DamirS
Member

Откуда:
Сообщений: 181
а в Оракловых тригерах на инструкцию мне не понравилос то, что строчки недоступны.
Т.е. нету аналога таблиц deleted и inserted от MS. Неудобно.
28 фев 07, 12:22    [3842080]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
DamirS
а в Оракловых тригерах на инструкцию мне не понравилос то, что строчки недоступны.
Т.е. нету аналога таблиц deleted и inserted от MS. Неудобно.

afair обсуждалось страниц пятнадцать назад.
28 фев 07, 12:38    [3842207]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
1virtual!
Member

Откуда: Москва
Сообщений: 22
Не подскажете, Oracle поддерживает INFORMATION_SCHEMA? Или только свои Ораклийные ALL_TABLES, ALL_TAB_COLUMNS и т.д.
1 мар 07, 12:30    [3847862]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
n0name2
Member

Откуда:
Сообщений: 7
softwarer
В десятой версии появилась весьма правильная возможность с крайне неудачным названием. Суть возможности - выполнение кучи DDL в одной транзакции (и таким образом, откат всех при неудаче). Весьма разумно для задач типа наката патчей. По непонятным мне причинам для этого употребили термин SCHEMA


к сожалению, ничего на эту тему найти не смог, вопрос для меня актуален. приведи, пожалуйста пример как можно сделать кучу DDL сделать в транзакции. заранее огромное спасибо
1 мар 07, 21:40    [3850966]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

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

http://www.oracle.com/pls/db102/search?remark=quick_search&word=create+schema&tab_id=&format=ranked
1 мар 07, 21:56    [3850988]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
n0name2
Member

Откуда:
Сообщений: 7
softwarer
n0name2
пример как можно сделать кучу DDL сделать в транзакции.

http://www.oracle.com/pls/db102/search?remark=quick_search&word=create+schema&tab_id=&format=ranked


ок, новую схему с чистого листа понятно как создать. а что делать если нужно существующую схему поправить в "транзакции"? наверное, как-то можно через workspaces, versioning? или в create schema можно допустим создать dummy схему а менять таблицы в другой схеме?

можно ли делать online table redefinition в "транзакционном" режиме?

P.S. respect и еще раз спасибо за информацию
2 мар 07, 13:42    [3853616]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 14 15 16 17 18 19 20 21 [22] 23   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить