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

Откуда: Москва
Сообщений: 1320
Блог
Yo.!
andsm

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

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

Эту проблему в большинстве случаев можно решить введя партиционирование горячего индекса.
Yo.!

andsm
В этом случае можно запретить эскалации вообще, запретить эскалации


ну сервер захлебнется в юлозании по огромному списку локов, мсдн об этом не раз предупреждает ....

Можно запретить эскалации только на определенных таблицах (там где они вредны), и разрешить на остальных. В этом случае количество блокировок будет нормальным.
9 мар 10, 14:01    [8449231]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
interesting
Guest
Yo.!
sdvsamara

Важно что эта фича именно для RAC и в другом случае не нужна. А так как MS SQL, насколько я знаю, таку конфигурацию не поддерживает, то ему этот индекс и не нужен. А вот если поддерживает, то это ошибка не иметь такой индекс.

не понял, вы пытаетесь меня убедить, что мсскл единственная субд где мистическим образом конкуренции не происходит ? дык, не получится, да и andsm собственно разъяснил как в мсскл предлагается выкручиваться без реверс индекса. согласен, при условии, что драка происходит только за примари кей то проканает ...




Можно я попробую повернуть беседу в конструктивное русло
( касательно сравнения конкурентного доступа к блокам).



Пришел с новыми тезисами( мыслями).


Зачем в СУБД вообще нужен индекс ?
Правильно для ускорения поиска . И чем больше всевозможных критериев для поиска
покрывает индекс, тем выше его юзабилити.

Что мы имеем в 2-х выше перечисленных подходах.

1 . Подход Oracle, имеем некоторые проблемы со сканированием по диапазону индекса.
( проблемы с функциональностью индекса , что есть факт)

2. Подход MS не полностью решает проблемы конкуренции за изменение, зато его индекс более
функционален с точки зрения его изначального предназначения.

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

Прошу понять меня правильно , я пытаюсь быть не предвзятым в сравнении.



зы show must go on :)
9 мар 10, 14:25    [8449445]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
Yo.!
Guest
andsm

Эту проблему в большинстве случаев можно решить введя партиционирование горячего индекса.


а разве можно навешивать индекс отпартиционированный по другому полю чем таблица ?

andsm
Можно запретить эскалации только на определенных таблицах (там где они вредны), и разрешить на остальных. В этом случае количество блокировок будет нормальным.

угу, в больших ERP на мсскл так и предлагают выкручиваться, на ощупь искать баланс между конкурентным доступом и кол-вом блокировок.
9 мар 10, 14:30    [8449478]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
interesting
2. Подход MS не полностью решает проблемы конкуренции за изменение, зато его индекс более функционален с точки зрения его изначального предназначения.

Вы уверены? Далеко не факт, что сервер поддерживает range scan при таком партиционировании.

interesting
Что в конечном итоге окажет больший вес в конечной оценке производительности всей системы - тяжело сказать. Но допускать однобокое сравнение я нехочу.

Думаю, в любом случае, для оценки окажет большое значение доля range scan-ов по первичному ключу :)
9 мар 10, 14:31    [8449483]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
interesting
Guest
Yo.!
andsm

Эту проблему в большинстве случаев можно решить введя партиционирование горячего индекса.


а разве можно навешивать индекс отпартиционированный по другому полю чем таблица ?



Можно, если он не уникальный.

Правильнее даже сказать так,
что в уникальный индекс должно входить условие партиционирования таблицы.
9 мар 10, 14:40    [8449563]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
interesting
Guest
softwarer
interesting
2. Подход MS не полностью решает проблемы конкуренции за изменение, зато его индекс более функционален с точки зрения его изначального предназначения.

Вы уверены? Далеко не факт, что сервер поддерживает range scan при таком партиционировании.


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


softwarer

interesting
Что в конечном итоге окажет больший вес в конечной оценке производительности всей системы - тяжело сказать. Но допускать однобокое сравнение я нехочу.

Думаю, в любом случае, для оценки окажет большое значение доля range scan-ов по первичному ключу :)


Полностью согласен.
9 мар 10, 14:45    [8449603]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

pkarklin wrote:

> Trace Flags 1211 и 1224

Рад, что в MS таки сделали тонкую настройку эскалации.
( SET ( LOCK_ESCALATION = { AUTO | TABLE | DISABLE } ) )

Всё-таки не конченый продукт.

Posted via ActualForum NNTP Server 1.4

10 мар 10, 10:43    [8453679]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
Yo.!
Guest
interesting

Можно, если он не уникальный.


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

interesting
я предложил тезисы требующие доказательств или опровержений,
а не утверждения.

ну и на кого же мы возложим бремя доказательств ?
10 мар 10, 14:19    [8455667]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
угу, в больших ERP на мсскл так и предлагают выкручиваться, на ощупь искать баланс между конкурентным доступом и кол-вом блокировок.


Ну, не совсем так, я бы даже сказал - совсем не так. Lock Partitioning
10 мар 10, 14:48    [8455991]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
interesting
Guest
Yo.!
interesting

Можно, если он не уникальный.


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


Нет никаких ограничений по типам данных, есть ограничение со списком полей:

ORA-14039

If the user, indeed, desired to create an index whose partitioning columns do not form a subset of its key columns, it must be created as non-UNIQUE; otherwise, correct the list of key and/or partitioning columns to ensure that the index' partitioning columns form a subset of its key columns


Я думаю глубже эту тему вы сами нагуглить сможете.
У Кайта ( на асктоме) вроде тоже обсуждалась эта тема.



Yo.!

interesting

я предложил тезисы требующие доказательств или опровержений,
а не утверждения.

ну и на кого же мы возложим бремя доказательств ?


Почему бремя ?
Мне кажется тема интересна с точки зрения обещего
професионального развития.
10 мар 10, 15:08    [8456190]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
Yo.!
Guest
pkarklin

Ну, не совсем так, я бы даже сказал - совсем не так. Lock Partitioning

вот спасибо ! а я бы сказал, что отличная иллюстрация на на какие ухищрения приходится идти ммскл когда юлозание по оргромным спискам локов переходит границу в 16 cpu. как я понимаю система с менее чем 16 cpu и отключенной эскалации вообще обречена.
еще спасибо за ссылку, собственно она и объясняет почему дба вынужден искать баланс с конкурентным доступом, а не тупо отключить эскалацию на всю базу.
10 мар 10, 15:10    [8456211]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
Yo.!
Guest
interesting

Нет никаких ограничений по типам данных, есть ограничение со списком полей:

ну в оракле то я и не сомневался, а вот что означает эта фраза об мсскл:
http://msdn.microsoft.com/en-us/library/ms187526.aspx
An index does not have to participate in the same named partition function to be aligned with its base table. However, the partition function of the index and the base table must be essentially the same, in that 1) the arguments of the partition functions have the same data type, 2) they define the same number of partitions, and 3) they define the same boundary values for partitions.
10 мар 10, 15:16    [8456272]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
interesting
Guest
Yo.!
interesting

Нет никаких ограничений по типам данных, есть ограничение со списком полей:

ну в оракле то я и не сомневался, а вот что означает эта фраза об мсскл:


Я вроде уже говорил , что не силен мсскл,

За пару минут беглого просмотра приведенной вами ссылки
напрашиваетмся вывод , что Вы либо не внимательно читали ссылку, либо пытаетесь
выдернуть фрузу из контекста

автор

Aligning an index with a partitioned table is particularly important if you anticipate that it will expand by taking on additional partitions, or that it will be involved in frequent partition switches. For more information, see Designing Partitions to Manage Subsets of Data. When a table and its indexes are in alignment, SQL Server can switch partitions quickly and efficiently while maintaining the partition structure of both the table and its indexes



Дальше то что вы процетировали ( типа ограничения , чем приходится платить за
alignment indexes)

http://msdn.microsoft.com/en-us/library/ms187526.aspx
An index does not have to participate in the same named partition function to be aligned with its base table. However, the partition function of the index and the base table must be essentially the same, in that 1) the arguments of the partition functions have the same data type, 2) they define the same number of partitions, and 3) they define the same boundary values for partitions.


а еще дальше

автор

Generally, the Database Engine Tuning Advisor can be used to recommend indexes for performance, and this can be a mix of aligned and nonaligned indexes. For more information, see Database Engine Tuning Advisor Overview.
10 мар 10, 15:49    [8456538]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
Yo.!
Guest
interesting

Я вроде уже говорил , что не силен мсскл,

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

interesting
За пару минут беглого просмотра приведенной вами ссылки

а если присмотреться ? лично я не вижу, чтобы что-либо указывало что предупреждение относится лишь к alignment indexes. мало того
http://msdn.microsoft.com/en-us/library/ms187526.aspx

An index does not have to participate in the same named partition function to be aligned ... However

на сколько мне хватает английского, я вижу прямое указание, что речь идет об индексе который не обязан быть aligned.
10 мар 10, 16:31    [8456928]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!

Ну, как обычно, в своем репертуаре.

автор
на какие ухищрения приходится идти ммскл когда юлозание по оргромным спискам локов переходит границу в 16 cpu.


А вот в статье, как раз с точностью до наоборот. если в системе более 16 ЦПУ, то есть дополнительная фича, снижающая "юлозание по оргромным спискам локов". Только нет никакой коррелляции локи-цпу. Просто предполагается, что в системах с менее 16 цпу (не по кол-ву цпу, а по нагрузке, которая такая система должна держать) не так актуальна проблема "юлозание по оргромным спискам локов".

автор
как я понимаю система с менее чем 16 cpu и отключенной эскалации вообще обречена.


Совсем не правильно понимаете, ибо, как и в случае с "проблемами с tempdb" при включенной версионности, Вы выносите чисто имперические суждения, не подтвержденный практикой. У меня, к счастью, другой опыт.
10 мар 10, 17:42    [8457562]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
hvlad
Member

Откуда:
Сообщений: 11555
pkarklin
если в системе более 16 ЦПУ, то есть дополнительная фича, снижающая "юлозание по оргромным спискам локов".
Там вообще ни слова про "списки локов" :)
10 мар 10, 17:45    [8457581]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
Yo.!
Guest
pkarklin

А вот в статье, как раз с точностью до наоборот.

мы говорим об одной и той же статье ? собственно что за проблему решает мсскл партиционированием локов:
msdn
For large computer systems, locks on frequently referenced objects can become a performance bottleneck as acquiring and releasing locks place contention on internal locking resources.


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

ЗЫ. намекаете, что ноты посвященные проблемам ио в темпдб не достаточный аргумент ?
10 мар 10, 18:53    [8457918]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
interesting
Guest
Yo.!
interesting

Я вроде уже говорил , что не силен мсскл,

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


Я нигде Вам ничего не доказывал про MSSQL .
Ни в вопросе ни в ответе MSSQL не звучало, пока Вы не
процитировали MSDN под моей цитатой.

Я попытался ответить , и сам паралельно подучился :)


Yo.!


interesting
За пару минут беглого просмотра приведенной вами ссылки

а если присмотреться ? лично я не вижу, чтобы что-либо указывало что предупреждение относится лишь к alignment indexes. мало того
http://msdn.microsoft.com/en-us/library/ms187526.aspx

An index does not have to participate in the same named partition function to be aligned ... However

на сколько мне хватает английского, я вижу прямое указание, что речь идет об индексе который не обязан быть aligned.



Думаю вы не вникли смысл same named partition function в понимании MS.
Я сам сейчас пытаюсь вникнуть.

Если вникать облом, погуглите

"Msg 1908, Partition columns for a unique index must be a subset of the index key."

то найдете кучу примеров обсуждений , где используются разные типы.
10 мар 10, 20:36    [8458231]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
намекаете, что ноты посвященные проблемам ио в темпдб не достаточный аргумент ?


Намекаю на то, что для Вас любая нота от MS, описывающая возможные узкие места с производительностью и способами оптимизации производительности чего угодно является гарантированным фактом подтверждения того, что эта проблема обязательно случиться.

Как на счет: Oracle® Database Performance Tuning Guide?! Не хилый такой документик, и в какой раздел не загляни, например...

I/O Configuration and Design

Тут, следуя Вашей логике:

автор
If the files with high-I/O are datafiles that belong to the TEMP tablespace, then investigate whether to tune the SQL statements performing disk sorts to avoid this activity, or to tune the sorting.
After the application has been tuned to avoid unnecessary I/O, if the I/O layout is still not able to sustain the required throughput, then consider segregating the high-I/O files.


следует сделать вывод, что у Oracle есть проблемы с сортировкой...

да и с REDO логами совсем плохо...

автор
If the archiver is slow, then it might be prudent to prevent I/O contention between the archiver process and LGWR by ensuring that archiver reads and LGWR writes are separated. This is achieved by placing logs on alternating drives.

For example, suppose a system has four redo log groups, each group with two members. To create separate-disk access, the eight log files should be labeled 1a, 1b, 2a, 2b, 3a, 3b, 4a, and 4b. This requires at least four disks, plus one disk for archived files
10 мар 10, 20:54    [8458274]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
Yo.!
Guest
interesting

Я нигде Вам ничего не доказывал про MSSQL .
Ни в вопросе ни в ответе MSSQL не звучало, пока Вы не
процитировали MSDN под моей цитатой.

вы утверждали "Можно, если он не уникальный." в контексте спора могут ли партиции мсскл решить проблему горячего блока...

interesting

Думаю вы не вникли смысл same named partition function в понимании MS.

если у таблицы и индекса разные функции для партиционированния, то по моему ясно как божий день, что ничего align-нового у них не получится, что бы там МС под align не понимала. далее фраза о том, что функция к тому же и не обязана быть aligned, вообще не оставляет никакого маневра ...

2pkarklin

собственно я об этом и говорю, читая оракловый перфоменс гвайд и смотря на архитектуру мсскл я начинаю задаваться вопросом, а не перемножаться ли ио проблемы если бы в оракле UNDO запихнули в TEMP тайблспейс. читая аналогичный майкрософтский гвайд я вижу подтверждение своим предположениям о том, что проблемы не просто усугубятся, но перемножаться. лично мне кажется ухищрения которые вынуждена рекомендовать мс для темпдб тому доказательства.
10 мар 10, 22:04    [8458433]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
interesting
Guest
Yo.!
interesting

Я нигде Вам ничего не доказывал про MSSQL .
Ни в вопросе ни в ответе MSSQL не звучало, пока Вы не
процитировали MSDN под моей цитатой.

вы утверждали "Можно, если он не уникальный."


Я всего лишь ответил на Ваш странный вопрос

Yo.!

а разве можно навешивать индекс отпартиционированный по другому полю чем таблица ?




Yo.!

в контексте спора могут ли партиции мсскл решить проблему горячего блока...


Баян :)

На этот вопрос уже был дан ответ.

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

Yo.!

interesting

Думаю вы не вникли смысл same named partition function в понимании MS.

если у таблицы и индекса разные функции для партиционированния, то по моему ясно как божий день, что ничего align-нового у них не получится, что бы там МС под align не понимала. далее фраза о том, что функция к тому же и не обязана быть aligned, вообще не оставляет никакого маневра ...


Слив засчитан :)
11 мар 10, 00:18    [8458795]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
SYS_NC00002$
Guest
Yo.!
locky

байтики считаем?

неа - деньги. если к каждому полю где у меня upper() индекс висит пришлось бы дублировать поле я бы в 4гб XE редакции бы не влез.


А не пробовал считать колонки с названиями SYS_* ?

sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Thu Mar 11 17:16:27 2010

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.


Connected to:
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production

SQL> create table test_lower (s varchar2(4000));

Table created.

SQL> create index test_lower_i on test_lower (lower(s));

Index created.

SQL> insert into test_lower values('TEST');

1 row created.

SQL> select table_name,column_name,data_type from user_tab_cols where table_name=upper('test_lower');

TABLE_NAME		       COLUMN_NAME		      DATA_TYPE
------------------------------ ------------------------------ ---------------------------------------------------
TEST_LOWER		       S			      VARCHAR2
[b]TEST_LOWER		       SYS_NC00002$	      VARCHAR2[/b]


SQL> select SYS_NC00002$ from test_lower;

SYS_NC00002$
--------------------------------------------------------------------------------
test

SQL> 

11 мар 10, 20:33    [8464897]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
...Было слышно, как тикают часы и капает вода из крана...
11 мар 10, 21:26    [8465093]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
Эталон Этанолович
Member

Откуда: Институт благородных девиц. Палата №6
Сообщений: 332
SYS_NC00002$
А не пробовал считать колонки с названиями SYS_* ?
А не пробовал сначала жевать, а потом говорить?

SQL> create table test_lower (s varchar2(4000));

Table created.

SQL> create index test_lower_i on test_lower (lower(s));

Index created.

SQL> insert into test_lower values('TEST');

1 row created.

SQL> commit;

Commit complete.

SQL> select cols,intcols from tab$ where obj#=(select object_id from dba_objects where object_name='TEST_LOWER' and object_type='TABLE');

      COLS    INTCOLS
---------- ----------
         1          2

SQL> select col#,segcol#,intcol#,name from col$ where obj#=(select object_id from dba_objects where object_name='TEST_LOWER' and object_type='TABLE');

      COL#    SEGCOL#    INTCOL# NAME
---------- ---------- ---------- ------------------------------
         1          1          1 S
         0          0          2 SYS_NC00002$

SQL> select dbms_rowid.rowid_relative_fno(rowid), dbms_rowid.rowid_block_number(rowid) from test_lower;

DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------------------------ ------------------------------------
                                   1                                43634

SQL> alter system dump datafile 1 block 43634;

System altered.

SQL>

Start dump data blocks tsn: 0 file#: 1 minblk 43634 maxblk 43634
buffer tsn: 0 rdba: 0x0040aa72 (1/43634)
scn: 0x0000.004959f6 seq: 0x01 flg: 0x02 tail: 0x59f60601
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Block header dump:  0x0040aa72
 Object id on Block? Y
 seg/obj: 0x77b9  csc: 0x00.4959f5  itc: 2  flg: O  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0009.000.00001698  0x02400514.013f.4b  --U-    1  fsc 0x0000.004959f6
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
 
data_block_dump,data header at 0x33f685c
===============
tsiz: 0x1fa0
hsiz: 0x14
pbl: 0x033f685c
bdba: 0x0040aa72
     76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x1f98
avsp=0x1f83
tosp=0x1f83
0xe:pti[0]	nrow=1	offs=0
0x12:pri[0]	offs=0x1f98
block_row_dump:
tab 0, row 0, @0x1f98
tl: 8 fb: --H-FL-- lb: 0x1  cc: 1
col  0: [ 4]  54 45 53 54
end_of_block_dump
End dump data blocks tsn: 0 file#: 1 minblk 43634 maxblk 43634

pkarklin
...Было слышно, как тикают часы и капает вода из крана...
Надо смеяться?

P.S. А вообще забавно наблюдать, как тот, кто мало разбирается в reverse in dexes (Yo.!) обсуждает их с теми, кто в них вообще ни в зуб ногой :)
11 мар 10, 21:34    [8465121]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL vs Sybase  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Эталон Этанолович,

Переведи... ((с) х\ф Москва слезам не верит)

автор
Надо смеяться?


Это цитата из романа ужасов...
11 мар 10, 21:45    [8465191]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить