Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 9 [10] 11 12 13   вперед  Ctrl
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Зл0й
Уважаемый onstat,

В Оракле тоже есть способы посмотреть кто, что и где заблокировал. На грубом уровне ищем в словаре (data dictionary). Более тонко, на уровне записи все находится с помощью второй сессии, пытающейся сделать блокировку. Делается это достаточно редко, ибо обычно необходимость в этом не возникает. Тем не менее в оракловом форуме sql.ru все достаточно подробно расписано, поэтому в детали вдаваться не буду.


И не нужно, я сам приводил ссылку на best way FAQ
по работe с блокировками непосредственно от Oracle в этом топике.

Зл0й

Что касается тестирования, то тестирование СУБД "самой по себе" бессмыслено. Ибо оно ничего не показывает. Точно так же как и тесты TPC-* показывают только то насколько хорошо данная СУБД решает данную конкретную тестовую задачу. Как только в некой СУБД Х появляется фича хорошо подходящая для данной задачи, то эта СУБД Х сразу оказывается "на голову выше" всех остальных. Ценность такого теста ИМХО крайне сомнительна, особенно учитывая "искусственность" тестовой задачи. Что до тестов SAP то там, по крайней мере, мы имеем вполне реальное (хоть и криво написанное - поубивал бы!) приложение.


Согласен по поводу SAP. Его разработчики пытаются усидеть на нескольких стульях(базах данных) и поэтому ответственность за целоснтость на базу не возлагают. Что там есть стоящего это методология, и соответствие международным стандартам учета.
Как очень часто бывает, идея хорошая - реализация дерьмо.
Никого не хотел обидеть.

Зл0й

Ответить на праздный вопрос "что лучше Оракл или Информикс" эти тесты конечно не позволяют, ибо на него вообще невозможно ответить. Зато они позволяют ответить на вопрос "что лучше подходит для установки SAP Оракл или Информикс". Поскольку этот вопрос не праздный, то эти тесты ИМХО имеют определенную (хотя и ограниченную) ценность.


Я не пытался доказать что лучше.

Зл0й

Предположим мы с вами затеяли тестирование "что лучше Оракл или Информикс" и даже сравнили результаты. В конечном итоге мы получили ответ на вопрос "кто лучше умеет писать приложения onstat или Зл0й" а не на вопрос "что лучше Оракл или Информикс".
Я такую работу делаю, только если есть конкретное приложение которое надо протестировать, плюс если мне за нее платят 100-120 долларов в час. Как говорится "Всякий труд должен быть оплачен". От себя добавлю "адекватно оплачен".


Я завел речь о тестировании для того чтобы доказать некоторым, что сам по себе продукт (будь то Oracle M$SQL или informix) требует професионального онтошения, Не нужно говорить, что в 90% случаем ни о чем думать не нужно.
Один бестолковый програмист может повесить на блокировку работу всей организации(есть опыт эксплуатации такого софта под Oracle).
Так, что думать нужно в зависимости от критичности приложения.

Зл0й

Про sequence и автоинкрементный тип, намек был на то что если мы допускаем "дырки" в последовательности id, то отпадает необходимость в жесткой сериализации (в смысле ANSI-стандарта) а можно обойтись Оракловой сериализацией (по науке называемой snapshot). Оракловая при всех прочих рабных будет масштабироваться лучше, ибо допускает параллелизм. Дело не в том у кого какая фича есть (ибо подобная фича есть почти в любой СУБД), а в том как оно работает, и как масштабируется.


Что значит при прочих равных? О чем вы говорите?
Откуда оракловая сериализация в других базах данных?
Маштабируемие чего? Опять 25 .
Вами названная сериализация это инструмент(фича) базы Oracle и закладываться(сравнивать) на него(его) при работе с другими базами
по крайней мере не конструктивно в споре ( и не професионально в работе).
Согласитесь, что это упрощение в по работе с блокировками
(относительно стандарта),
которое имеет свои слабые стороны,
о которых нужно знать при написании приложения.
Если бы это была панацея, все базы данных поддерживали бы такой
вид сериализации, и спорить былобы уже не очем.

По поводу дырок в последовательности ID я вобще ничего не понял.

С уважением.
29 сен 04, 10:58    [995307]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
andy st
Member

Откуда:
Сообщений: 899
Yo!
не тормози - на агрегате датчики, управление с процессором в соседней комнате.

;)
ну это смотря какой агрегат и какие датчики... некоторые датчики по сути пром.компьютеры или контроллеры и на ура могут управлять системой.
да и соседнюю комнату не всегда найдешь...
29 сен 04, 15:15    [996723]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
ASCRUS
Кстати не понятно, если все с Ораклом так хорошо, то почему та самая пресловутая MB вешается с ним каждый день

А Вы не пробовали спрашивать у самой МВ? Как только туда взяли хорошего главного админа, Оракл вешаться практически перестал. Хотя на тему проектирования базы там можно медитировать куда больше, чем над приведенными здесь примерами.

ASCRUS
и содержит не малый по размерам штат администраторов ?

... в количестве двух человек (было три; может, снова взяли третьего). Заодно спросите о количестве серверов в той же пресловутой МВ.

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

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

Может. А с "неораклом" это не так?

ASCRUS
P.S. И кстати что делать, если по бизнес-логике потребуется специально заблокировать некоторые данные, чтобы их никто не мог изменить до подтверждения заблокировавшей их транзакции ?

Читать доки. На предмет оператора select .. for update.
29 сен 04, 17:48    [997632]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
softwarer
Все мои отцитированные Вами фразы были взяты из контекста моей речи, где я убедительно (надеюсь) пытался доказать, что дело не в СУБД, а человеческом факторе. Утверждения некоторых товарищей, что Оракл однозначно, везде и всегда лучше блокировочников, в том числе и при кривых ручках, по меньшей мере смешно. В принципе Вы в своем посте это и высказали и многие другие это делали уже не раз, хотя судя по всему до сих пор не все ораклисты согласились с этим высказыванием - но это как говорится уже их личные проблемы, с чем соглашаться, а чем нет. Лично я и не против, чтобы Оракл был крут, но не могу о нем высказать компетентное мнение, так как не работаю с ним с точки зрения писателя БД, хотя приходиться работать с точки зрения читателя чужих БД, что в принципе не дает ничего полезного в плане его анализа, разве что кроме частого удивления, почему так много разработчиков Оракла не пользуются всем тем, что в нем есть, программируют по старинке и частенько криво. По теоретической базе насчет возможностей Оракла и PLSQL я более менее знаю, что он умеет, а что нет, доки и форум Оракла на sql.ru почитывать иногда приходится :)
29 сен 04, 18:37    [997851]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Про "дырки" в последовательности ID вот какая штука:
1. можно требовать чтобы ID присваивались строго по порядку 1,2,3,4,5,...
2. можно допускать 1,4,7,9 и требовать чтобы более поздние ID были больше более ранних
3. можно просто требовать только уникальности ID без каких-то иных ограничений.

Разные задачи - разные требования. В случае 1. ничто, кроме жесткой сериализации в полном соответствии с ANSI-стандартом, не спасет "отца русской демократии". Это тот случай когда от ораклового serializable (который на самом деле snapshot) толку не много. Производительность будет примерно одинаково паршивая, ибо мы фактически исключаем параллельность транзакций.

Варианты 2 и 3 реализуемы на оракловом уровне изоляции snapshot, причем за счет
параллельности транзакций работают быстрее чем 1. То есть, при всех прочих равных (например когда все - в Оракле) 3. быстрее чем 2. быстрее чем 1.

Проблема с блокировщиками в том, что варианты 2. и 3. в них зачастую выполняются так же медленно как и 1. Если предположить что разработчики Оракла не глупее и не умнее других, что первый вариант работает в Оракле и Информиксе (DB2, Sybase, MSSQL) примерно одинаково. Соответственно для реализации 1. все равно какую СУБД брать. Зато для реализации вариантов 2. и 3. предпочтительнее Оракл.

ЗЫ а на самом деле, обычно ставят ту СУБД которая в организации уже есть. Под которую уже есть опытные админы, итп. Надежность и отсутствие "сюрпризов" перевешивает все технические достоинства и недостатки СУБД. Ибо решения принимает менеджмент, которому важнее всего чтобы "не падало".
30 сен 04, 03:39    [998236]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
f2f
Guest
Какие-то бездоказательные рассуждения (и неверные на мой взгляд рассуждения) и не понятно к чему
30 сен 04, 09:40    [998640]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Зл0й
Про "дырки" в последовательности ID вот какая штука:
1. можно требовать чтобы ID присваивались строго по порядку 1,2,3,4,5,...
2. можно допускать 1,4,7,9 и требовать чтобы более поздние ID были больше более ранних
3. можно просто требовать только уникальности ID без каких-то иных ограничений.


Дальше по тексту вы эти 3 варианта имеете ввиду?
Так ка других нет то наверное.

Зл0й

Разные задачи - разные требования. В случае 1. ничто, кроме жесткой сериализации в полном соответствии с ANSI-стандартом, не спасет "отца русской демократии". Это тот случай когда от ораклового serializable (который на самом деле snapshot) толку не много. Производительность будет примерно одинаково паршивая, ибо мы фактически исключаем параллельность транзакций.


Паралельные транзакции исключаются с пересекающимися данными,
если же данные не пересекаются то паралелить можно сколько угодно.
Единица блокирования у нас запись(результат условия where).
А также если приложение позволяет зделать предположение о работе
соседней сессии, то можно включить грязное чтение и достать еще незокмиченные данные( если нужно). В oracle с этим большие проблемы.
Скорость генерация ID(sequnce) несоимеримо мала относительно времени выполнения любой другой транзакции.

Зл0й

Варианты 2 и 3 реализуемы на оракловом уровне изоляции snapshot, причем за счет
параллельности транзакций работают быстрее чем 1. То есть, при всех прочих равных (например когда все - в Оракле) 3. быстрее чем 2. быстрее чем 1.
Проблема с блокировщиками в том, что варианты 2. и 3. в них зачастую выполняются так же медленно как и 1. Если предположить что разработчики Оракла не глупее и не умнее других, что первый вариант работает в Оракле и Информиксе (DB2, Sybase, MSSQL) примерно одинаково. Соответственно для реализации 1. все равно какую СУБД брать. Зато для реализации вариантов 2. и 3. предпочтительнее Оракл.


Я не совсем понимаю что вы хотели сказать.
Если мы имеем ввиду изоляцию commited read, то чтение производится
паралельно если никто ничего не меняет. Я пока не вижу проблем в распаралеливании выполнения. Все зависит от задачи.
При правильном проектировании в блокировчнике никто на блокировках не ждет. Зато в оракле нужно помнить, что если вы открыли кусрсор, а в
это время кто-то изменит значение, то у вас будут еще старые данные.
Я где то видел пример с одновременным дебетованием двух счетов,
который для корректного разрешения требует serializable,
что автоматом приводит либо нарушении целосности данных, либо необходимости явного блокирования записи.
Т.Е. чтобы подстраховать целостность данных oracle програмист должен
работать на вашем уровне 1. И запретить распаралеливание, хотя
блокировочник сможет паралелиться на чтении и при этом корректно обработать эту ситуацию.
В данном случае неявная блокировка записи на изменение у болкировчника,
гораздо масштабируемие Вашего снапшота.


Зл0й

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


Здесь согласен, возразить нечему.

С уважением, onstat.
30 сен 04, 11:16    [999086]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Всегда и везде палка о 2-х концах при сравнении любых технологий :)

Наше бремя (блокировочник)
автор
Если мы имеем ввиду изоляцию commited read, то чтение производится
паралельно если никто ничего не меняет. Я пока не вижу проблем в распаралеливании выполнения. Все зависит от задачи.
При правильном проектировании в блокировчнике никто на блокировках не ждет.

Еще как ждет, причем в serializable :) Примитивный примерчик:
SELECT *
FROM Table
UNION ALL
SELECT *
FROM Table;
В таблице записи никогда не изменяются и не удаляются, только добавляются. Казалось бы READ COMMITED и все счастливы. Но на самом деле: пока по таблице идет первый проход, в нее добавляется с другой транзакции запись и коммитится. Во втором проходе она уже войдет в запрос и в итоге у нас получится несоотвествие возвращаемых данных и запроса, то есть на одну запись больше :) Это и есть так называемый нестабильный курсор.

Если есть поле TIMESTAMP, то для данного запроса можно выкрутиться таким способом и на READ COMMITED:
DECLARE @LastTime timestamp;

SELECT Max(LastTime)
INTO @LastTime
FROM Table;

SELECT *
FROM Table
WHERE LastTime <= @LastTime
UNION ALL
SELECT *
FROM Table;
WHERE LastTime <= @LastTime
В данном случае мы фиксируем время последнего подтвержденного в таблице COMMIT и уже проводим выборку, имея на руках строгую точку ограничения записей. Соотвествующе если в запросе участвует 10 табличек, то придется для каждой получать время последнего COMMIT, причем именно в изоляции serializable. В итоге можно констатировать, что все таки при очень интенсивных вставках и изменениях данных только уровень изоляции serializable может 100% гарантировать достоверный результат выполнения запроса. Так что в этом плане, ораклисты правы, говоря о недостатках (хотя это слишком громко, я бы сказал фичах) блокировочников. Это не означает, что это плохо, это означает, что нужно знать особенности блокировочников и использовать те приемы и рекомендации, которые разработаны для блокировочников, т.е. не затягивать транзакции, пользоваться времянками, применять TIMESTAMP, если этого достаточно, если система не требует данных на реальный момент времени, перекидывать их на аналитические сервера и т.д.

Бремя Оракла (версионник)
автор
Я где то видел пример с одновременным дебетованием двух счетов,
который для корректного разрешения требует serializable,
что автоматом приводит либо нарушении целосности данных, либо необходимости явного блокирования записи.
Т.Е. чтобы подстраховать целостность данных oracle програмист должен
работать на вашем уровне 1. И запретить распаралеливание, хотя
блокировочник сможет паралелиться на чтении и при этом корректно обработать эту ситуацию.

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

Мораль - закон сохранения энергии: чем больше хорошего в чем то, тем больше плохого в другом чем то. Вывод - отсутствие кривых рук, присутствие ясной головы, опыта и знаний, а так же использование по назначению могут сделать хорошим любой продукт :)
30 сен 04, 12:57    [999545]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
2ASCRUS

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

ЗЫ. на самом деле спор разрешит MS когда юкон в tpc-c будет выступать в режиме snapshot.
30 сен 04, 13:49    [999821]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
onstat
Guest
Yo!
2ASCRUS

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

ЗЫ. на самом деле спор разрешит MS когда юкон в tpc-c будет выступать в режиме snapshot.



Прямизну Ваших ручек на оценить было не на чем.
Мы могли оценить только ширину растопырки пальцев.
Может для начала вы нам предоставите какое либо предварительное
решение для Oracle.

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

С уважением.
30 сен 04, 14:35    [1000047]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
ASCRUS
softwarer
Все мои отцитированные Вами фразы были взяты из контекста моей речи, где я убедительно (надеюсь) пытался доказать, что дело не в СУБД, а человеческом факторе. Утверждения некоторых товарищей, что Оракл однозначно, везде и всегда лучше блокировочников, в том числе и при кривых ручках, по меньшей мере смешно.

Ну, как минимум фраза про немалый по размерам штат админов точно показывает только не доскональное владение приводимым примером.

Насчет некоторых товарищей - не могу сказать, что я внимательно прочитал все предыдущие страницы топика :) - но кардинальной активности такого рода здесь не заметил.

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

ASCRUS
кроме частого удивления, почему так много разработчиков Оракла не пользуются всем тем, что в нем есть, программируют по старинке и частенько криво.

Хм. Воспользоваться всем, что в нем есть, имхо довольно трудно.

Недавно была вакансия, где требовалось "95-процентное знание оракла". Я, с моей точки зрения, знаю оракл процентов на пятьдесят - однако, выслушал ряд комплиментов и не пошел туда. Имхо это довольно точно отражает реальную ситуацию :)
30 сен 04, 19:03    [1000505]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Ну, как минимум фраза про немалый по размерам штат админов точно показывает только не доскональное владение приводимым примером.

Я не работал в MB, информация у меня была на руках от лиц, работающих там, в этом Вы полностью правы. Но все равно же там админов > 1 ??? Для меня и это уже целый штат админов, так как для того, на чем я работаю (Sybase ASA) и параллейно изучаю (Sybase IQ) один админ - это уже по самое не хочу :)
30 сен 04, 19:13    [1000523]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Мимо пробегал...
Guest
softwarer
Вот только сегодня я узнал, что MS SQL не поддерживает параметризованные клиентские запросы - меня так это шокировало, если честно


Видимо Вы не все узнали....наверное потому что о MS SQL "за сегодня" все узнать невозможно :) Попытаюсь вывести вас из шока. В MS SQL есть определяемые пользователем функции, функционал которых без проблем позволяет выполнять такого рода действия ( и не только их). То, что это действие оформлено не как запрос, а как функция ИМХО не должно напрягать, тем более, что пользовать их можно точно так же как и любые другие таблицы и запросы.

То есть, прежде чем о чем то говорить, надо об этом ОЧЕНЬ МНОГО знать.... а иначе это будет не жисть, а сплошной шок
30 сен 04, 19:23    [1000544]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
MasterZiv
Member

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

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

Это каких-таких запросов нет в MSSQL ? Фсе там есть.
30 сен 04, 20:05    [1000621]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 ASCRUS
Давно хочу спросить Вас: "А как Вы вообще вышли на Sybase в нашей стране?"
Про Оракл и MSSQL и даже DB2 понятно. А вот про Sybase нет. Первые три особенно 1 и 3 лидируют и в мире по числу инстоляций по 36%. Второй 16%. Но MS в нашей стране лидирует по операционке - это дает дорогу и другим MS продуктам. В лит-ре про БД эти СУБД упорно упоминаются, на их примерах многое обсуждается. А вот остальные СУБД для меня полная загадка. Откуда они то нарисовались тут? Хотя Sybase и упоминается в лит-ре по БД, но как-то без излишних восхвалений.
30 сен 04, 20:12    [1000628]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
автор
Я не работал в MB, информация у меня была на руках от лиц, работающих там, в этом Вы полностью правы. Но все равно же там админов > 1 ??? Для меня и это уже целый штат админов, так как для того, на чем я работаю (Sybase ASA) и параллейно изучаю (Sybase IQ) один админ - это уже по самое не хочу


а что вас удиаляет ? то что более сложным прграмным комплексои сложнее управлять ? понятно что sybase есть 1 вид индексов - btree, плоские таблички и все ... администрить практически нечего.
но если действительно интересно почитайте как оракл RACом ставят ... :)
30 сен 04, 21:48    [1000724]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Yo!
а что вас удиаляет ? то что более сложным прграмным комплексои сложнее управлять ? понятно что sybase есть 1 вид индексов - btree, плоские таблички и все ... администрить практически нечего.
но если действительно интересно почитайте как оракл RACом ставят ... :)

Интересно, Вам не надоело выставлять себя безграммотным аппелиционным ... ? :) Прежде чем делать какие либо заявления, неплохо бы иногда знакомиться с тем, что пишут авторы, а заодно и с предметом Ваших заявлений. Итак даю ссылки Вам, как новичку, который по наивности думает, что название СУБД у Sybase - Sybase и их оказывается аж целых 3:
https://www.sql.ru/faq/faq_topic.aspx?fid=178
Странно что весь этот многостраничный топик Вам твердят, что не надо путать ASE, ASA и IQ, что у них и производители разные, только общая торговая марка Sybase, но пока Вы это еще как видно никак переварить не можете :)

Немного технические характеристики всех 3 СУБД:
http://sybase.sql.ru/asa9/ASE-ASA-IQ.pdf

Более подробные ссылки о Sybase IQ, котором я говорил (и который кстати да будем Вам известно является версионником)
- Отсюда можно начинать читать о том, что это такое:
http://www.sybase.com/products/informationmanagement/sybaseiq

- И есть результаты его тестирования в так любимом Вами tpc.org:
http://www.tpc.org/tpch/results/tpch_price_perf_results.asp

Если хоть раз в жизни удосужитесь ознакомиться с материалом (именно познавательных целях, а не с целью выискивания, где что покритиковать), то заодно узнаете, сколько индексов и каких держит IQ, как он хранит данные и за счет чего выигрывает в скорости, во сколько раз сжимает информацию БД и почему его размер БД нужно умножать, чтобы получить реальный размер данных, на каких платформах работает и т.д. и т.п. Я лично Вам ничего рассказывать или тестово писать не буду, както участвовать в шоу клоунов не хочется, где один серьезно что то пытается рассказать, а второй строит при этом мины, даже не вникая в то, чего ему говорят. Хотите цирк, велком, но без меня, я наличием свободного времени особо не страдаю :)

vadiminfo
Давно хочу спросить Вас: "А как Вы вообще вышли на Sybase в нашей стране?"
Про Оракл и MSSQL и даже DB2 понятно. А вот про Sybase нет. Первые три особенно 1 и 3 лидируют и в мире по числу инстоляций по 36%. Второй 16%. Но MS в нашей стране лидирует по операционке - это дает дорогу и другим MS продуктам. В лит-ре про БД эти СУБД упорно упоминаются, на их примерах многое обсуждается. А вот остальные СУБД для меня полная загадка. Откуда они то нарисовались тут? Хотя Sybase и упоминается в лит-ре по БД, но как-то без излишних восхвалений.

Познакомился с Sybase ASA совершенно случайно. От знакомых с Украины я наслышался о Sybase Power Builder и решил с ним познакомиться поближе, так как давно хотелось найти то средство построения клиентских приложений, которое было бы заточено именно под это и позволяло лепить приличный и легко поддерживаемый интерфейс с минимум кодирования и усилий. Ну а в составе PowerBuilder в качестве встроенной демонстрационной СУБД и шла урезанная версия Sybase ASA :) Вот уже полтора года я работаю с ASA и PB, разработано множество решений, компонент, технологий и проектов и я очень доволен своим выбором. Особенно доволен ASA, которая постоянно с каждым ежемесячным патчем становится мощнее и функциональнее, а главное движется строго туда, куда мне и хочется, что и не удивительно, учитывая, что работа iAnywhere по развитию ASA ведется вместе вживую с разработчиками по материалам форумов и каждый желающий может принять участие и предложить, куда и как лучше развиваться или же выложить на исправление найденные баги.
30 сен 04, 23:59    [1000802]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Кстати вдогонку - "тот самый" Sybase ASE, который как говорят являлся прародителем MSSQL и которого именно и вспоминают, говоря СУБД Sybase, я так ни разу в жизни и не видел и даже не представляю, что это такое :) Знаю только его примерные возможности по диалекту TSQL в ASA, который доработан специально для совместимости с ASE и MSSQL и далеко отстает от развития родного диалекта WatcomSQL хотя бы по той причине, что в него "разрешают" добавления только при движении TSQL в ASE и MSSQL, а WatcomSQL подгоняют по семантике и возможностям под PL/SQL и DB2, причем вводя еще и свои полезные фичи.
1 окт 04, 00:06    [1000807]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Рыжий Кот
Member

Откуда: Мягкий Диван; [забанен] Рустамом; [разбанен] П02;
Сообщений: 21678
автор
Про Оракл и MSSQL и даже DB2 понятно. А вот про Sybase нет. Первые три особенно 1 и 3 лидируют и в мире по числу инстоляций по 36%. Второй 16%. Но MS в нашей стране лидирует по операционке - это дает дорогу и другим MS продуктам. В лит-ре про БД эти СУБД упорно упоминаются, на их примерах многое обсуждается. А вот остальные СУБД для меня полная загадка. Откуда они то нарисовались тут? Хотя Sybase и упоминается в лит-ре по БД, но как-то без излишних восхвалений.


По количеству инсталляций лидирует акцец.
З.Ы. Поменьше смотрите рекламу.

Картинка с другого сайта.
1 окт 04, 08:58    [1001115]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
>По количеству инсталляций лидирует акцец.

акцец не считается - все-таки это СУБД другого класса. Файл серверная, офисная, учебная. Там тогда пришлось бы еще и фокспро учитывать и все такое. Я и сам использую акцец. Если считать, то тогда конечно его почти столько сколько и Вордов установлено - сколько офисов. А это почти вся наша страна.
1 окт 04, 09:40    [1001251]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Pi
Member

Откуда:
Сообщений: 278
Рыжий Кот

По количеству инсталляций лидирует акцец.
З.Ы. Поменьше смотрите рекламу.
Картинка с другого сайта.


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

Это во-первых. А во-вторых, в 80 % случаев вместо Access можно поставить Oracle, из оставшихся (я имею в виду устаревшее железо, нехватку ОЗУ и прочие нищенские траблы) в 15% - MS SQL . Не ставят только потому, что МОЖНО не ставить. А Вы попробуйте продавать билеты на все поезда или все авиарейсы России на Access.

Так что ездите на своем велосипеде, но на форуме автолюбителей лучше помолчите.
1 окт 04, 14:41    [1002264]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Pi
Member

Откуда:
Сообщений: 278
ASCRUS
Но все равно же там админов > 1 ??? Для меня и это уже целый штат админов, так как для того, на чем я работаю (Sybase ASA) и параллейно изучаю (Sybase IQ) один админ - это уже по самое не хочу :)


Все же количество админов - это больше вопрос предприятия, чем софта.
Приведу такой пример. В операционной системе OS/400 (я работал еще на старой - в.2.2) нет суперюзера как класса. Если Вы Офицер Безопасности - пожалуйста, настройте все политики. Но сделать ничего нельзя. Надо зайти как Системный оператор - и все сделать (естесвенно, изменить в политиках ничего нельзя). Вот Вам пример защиты от человесекого фактора. В Советском Союзе, кстати, в стратегических системах строилась защита от сговора двоих. А Вы -про одного админа.
1 окт 04, 14:54    [1002286]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Guest_2
Guest
автор
А во-вторых, в 80 % случаев вместо Access можно поставить Oracle, из оставшихся (я имею в виду устаревшее железо, нехватку ОЗУ и прочие нищенские траблы) в 15% - MS SQL . Не ставят только потому, что МОЖНО не ставить. А Вы попробуйте продавать билеты на все поезда или все авиарейсы России на Access.

У Вас, лично, Oracle купленный, а ли краденый?
Похоже, что краденый, раз предлагаете, краденый Access на краденый Oracle всем менять.
1 окт 04, 15:16    [1002387]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Pi
Member

Откуда:
Сообщений: 278
ASCRUS

Бремя Оракла (версионник)
автор
Я где то видел пример с одновременным дебетованием двух счетов,
который для корректного разрешения требует serializable,
что автоматом приводит либо нарушении целосности данных, либо необходимости явного блокирования записи.
Т.Е. чтобы подстраховать целостность данных oracle програмист должен
работать на вашем уровне 1. И запретить распаралеливание, хотя
блокировочник сможет паралелиться на чтении и при этом корректно обработать эту ситуацию.

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


Dear ASCRUS,
Вы так здорово расписали проблемы блокировочников, и главное - показали решения этих проблем, что остается сказать
БОЛЬШОЕ СПАСИБО!

Но вот что касается версионика - ничего не понял. Какое распаралеливание запретить? Кто это где это читал? Может, не дебетирование двух счетов, а дебетирование одного счета с кредитированием другого в агло-саксонском конто? Так это вроде проблема именно блокировочника!
Простите за бестолковость, но можно ли на примерах?
1 окт 04, 15:24    [1002457]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
автор
Если хоть раз в жизни удосужитесь ознакомиться с материалом (именно познавательных целях, а не с целью выискивания, где что покритиковать), то заодно узнаете, сколько индексов и каких держит IQ, как он хранит данные и за счет чего выигрывает в скорости, во сколько раз сжимает информацию БД и почему его размер БД нужно умножать, чтобы получить реальный размер данных, на каких платформах работает и т.д. и т.п. Я лично Вам ничего рассказывать или тестово писать не буду, както участвовать в шоу клоунов не хочется, где один серьезно что то пытается рассказать, а второй строит при этом мины, даже не вникая в то, чего ему говорят. Хотите цирк, велком, но без меня, я наличием свободного времени особо не страдаю :)


у вас просто одержимость других считать глупее себя, зря ;)
у syabase настроек минимум, админ повлиять на процессы в субд практически не может, поэтому и надобность в нем минимальная.
то что эти настройки сделали предефинены и разнесли в 3 субд сути не меняет. что можно настраиват в ASA ? как можно повлиять на скорость конкретной задачи ? добать индекс - все. сравните с ораклом. что есть IQ ? как можно повлиять на скорость запроса ? сравните с ораклом.

на счет прайс перфоменс у mysql он круче ну и что ? мне например не понятно в чем тайный смысл IQ, который в ad hoc ничего показать не может , но при этом требует еще и OLPT сервер, цена которого почему то в price/perfomenc как то не фигурирует ... я понимаю terradata - которая там оракл в 2-3 раза делала.
1 окт 04, 15:45    [1002568]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 9 [10] 11 12 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить