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

Откуда: МО Электросталь
Сообщений: 5994
А Вы еще раз внимательно вчитайтесь в предложенную мной схему:
1. Это не есть попытка ручками реализовать схему работы, аналогичную Оракл, это идея о том, как правильно на блокировочнике разруливать OLTP и OLAP.
2. Предложенная мной идея (не решение конечно) транзакционно зависимая, где это Вы увидели, что она переживет ROLLBACK ? Данные в таблицу "перерасчет" попадут только по закоммиченным данным из операций по движению денег. А удаляться эти данные оттуда в пределах единой транзакции пересчета баланса, так что здесь накладок быть не может. Как вариант - вместо таблицы буфера всегда можно сделать флаг "участвует в балансе" в таблице движения средств и использовать его, выставляя его в событии после включение суммы записи в баланс.
3. Если рухнет сервер, то при его запуске все незакрытые транзакции откатятся, через минуту запуститься событие и оно продолжит пересчитывать баланс. Не вижу тут никакого повода делать логи или еще чего было.
4. Никто не мешает сделать обновление пересчитываемой таблицы баланса по ночам, а для подсчета текущего баланса клиента брать его баланс и все записи из таблицы движения по счетам, у которых дата ввода в БД больше даты последнего перерасчета баланса. С учетом вышепредложенного мною флага по проведение записи в баланс это дает хорошие функциональные возможности держать подтвержденный на утро баланс и иметь возможность править работу текущих суток, без пересчитывания баланса.
5. Вы мне пытаетесь сказать, что лучше всего универсальный Оракл, который одновременно представляет из себя OLTP и OLAP. Я Вам пытаюсь показать, что при должном подходе и проектировании БД задачу по обработке и накоплению данных можно решить на чистых OLTP-блокировочниках. Если БД получается огромной и по ней часто выполняются аналитические отчеты, то к ним просто рядышком ставится аналитический DSS-сервер, на который по ночам переливаются данные и уже никому не мешая он может быстро промалывать огромные массивы данных, далеко оставляя позади тот же Оракл. Ну а для DSS, где данные обычно сливаются сразу блоками и важна скорость чтения, а не записи, как раз версионность никогда не помешает. Что например и сделано в Sybase IQ :)
22 сен 04, 08:27    [977208]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Константин Лисянский
Member

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

Поскольку в дискусии упоминалась СУБД Teradata, замечу, что там такая штука тоже имеется и называется Prioriry Scheduler. Кстати в отличие от ораклового менеджера, который появился только недавно, в Терадате эта штука существует с самого начала (т.е более 20 лет), что косвенно подтверждает полезность такой возможности.

По поводу оптимизации запросов - к хранилищу данных очень часто даётся доступ тулзам, которые генерируют SQL (BusinessObjects, Cognos Impromptu, Microstrategy). Пользователь, как правило, имеет очень мало возможностей повлиять на вид SQL, поэтому назначение приоритетов в данном случае может спасти от "шалунов", способных загнать сиситему в даун элементарно (cross join, например).

С уважением,
Константин Лисянский
http://lissianski.narod.ru
22 сен 04, 15:03    [979072]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Зорин
Guest
Зл0й
Помнится Сайбэйс тоже когда-то обещал блокировку на уровне записи. Обещанного три года ждут. В случае с Сайбэйсом даже дольше.

Насколько мне известно row level locking в Sybase ASE есть с 1998-го.
примерно в это же время был выпущен MSSQL 7.0.
м?
22 сен 04, 15:47    [979333]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
x
Guest
Зл0й
А разве в MSSQL можно в онлайне логи присылать на standby базу которая открыта на чтение?
Прислать можно,
но на время поднятия логов пользователей из базы придется выгнать.
22 сен 04, 17:19    [979952]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Уважаемый ASCRUS, для того чтобы бороться с проблемой читатели-писатели вы сделали вот что:
- разнесли данные по нескольким таблицам
- завели таблицу транзакций (фактически почти transaction log)
- завели асинхронный по отношению к потоку транзакций процесс, читающий таблицу транзакций и обновляющий таблицу балансов. То есть "почти MQ" только ручками и single-threaded.

Соответственно мы заботу о согласованности данных попросту переложили с СУБД на приложение. Если в случае Оракла об этом заботится СУБД, то в вашем решениее об этом заботится приложение, проверяя timestamps. Недостатки этого подхода такие:
- приложения менее надежны чем СУБД.
- триггеры как работают как минимум на порядок медленнее чем механизмы СУБД
- мы факлически выстроили все транзакции в очередь и выполняем их по одной. Масштабируемость получается практически никакая.
- таблица балансов "отстает" по времени от других таблиц СУБД. Что если данные о балансах требуются более сложной транзакции, которой так же требуются данные из других таблиц? Нам во всех этих таблицах потребуется timestamp? Иначе как мы обеспечим согласованность данных из других таблиц с таблицей балансов?

Например, предположим что есть какая-то бизнес-логика связанная с проверкой баланса, читающая из других таблиц (не движение по счетам). Значит в тех таблицах тоже должен быть timestamp дающий нам информацию об актуальности данных. Иначе данные из этих таблиц могут быть по состоянию на 17:02:05 а балансы по состоянию на 17:01:55. Обеспечивать согласованность данных "ручками" это очень серьезный головняк.

Таким образом мы имеем весьма нетривиальную задачу обработки транзакцй "ручками". У нас есть очередь транзакций, асинхронный по отношению к потоку транзакций процесс их выполняющий, и данные согласованность которых надо проверять вручную. Зачем нам тогда вообще такая СУБД, если обработку транзакций приходится вручную делать? Чем писать собственный обработчик транзакций, может лучше взять готовый? На мэйнфреймах народ обходится MQ, CICS, вообще данные в файлы (VSAM, ISAM) пишет. Не нужна им СУБД, если конкурентного доступа к данным нет. Ваше решение, уважаемый ASCRUS есть по сути отказ от СУБД в пользу мэйнфреймовой идеологии обработки транзакций.

ИМХО решение крайне громоздкое, неэффективное и дорогое в разработке и обслуживании. Гораздо проще (и грамотнее) возложить обработку транзакций на СУБД и не заморачиваться самодельными TP мониторами.

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

Откуда: МО Электросталь
Сообщений: 5994
Уважаемый Зл0й. У меня начали возникать смутные подозрения, что мы с Вами явно общаемся на разных языках и никак не можем понять друг друга. Подскажите пожалуйста - Вы программист или администратор ?

автор
- разнесли данные по нескольким таблицам
- завели таблицу транзакций (фактически почти transaction log)
- завели асинхронный по отношению к потоку транзакций процесс, читающий таблицу транзакций и обновляющий таблицу балансов. То есть "почти MQ" только ручками и single-threaded.

В своем последнем посте я предложил более элегантное решение проблемы - создание флага участия в балансе в таблице "Движение". Но и в предыдущем предложенном решении я ничего такого из вышеперечисленного не делал. Я просто создал табличку, в которой тусуются неподтвержденные в балансе записи до их добавления значений в баланс. Когда они добавяться, то табличка очистится. Заметьте я говорю языком проектировщика БД, Вы же шпрехаете терминами этакого заправского сисадмина.

автор
Соответственно мы заботу о согласованности данных попросту переложили с СУБД на приложение. Если в случае Оракла об этом заботится СУБД, то в вашем решениее об этом заботится приложение, проверяя timestamps. Недостатки этого подхода такие:
- приложения менее надежны чем СУБД.
- триггеры как работают как минимум на порядок медленнее чем механизмы СУБД
- мы факлически выстроили все транзакции в очередь и выполняем их по одной. Масштабируемость получается практически никакая.
- таблица балансов "отстает" по времени от других таблиц СУБД. Что если данные о балансах требуются более сложной транзакции, которой так же требуются данные из других таблиц? Нам во всех этих таблицах потребуется timestamp? Иначе как мы обеспечим согласованность данных из других таблиц с таблицей балансов?

Ни о каком приложении и речи быть не может. Вся забота о TIMESTAMP лежит на СУБД, которое автоматически обновляет это поле при добавлении/изменении записи и запросах, в фильтрах которых стоит условие Поле TimeStamp <= NOW(). Так что Ваше высказывания о приложениях только подтверждает мои догадки, что Вы особо не реализовывали сложную бизнес-логику средствами СУБД. Насчет триггеров тоже промашка - в Оракле конечно может FOR EACH ROW и работают медленно и вызываются на каждую запись, но вот в ASA и MSSQL триггера FOR EACH STATEMENT вызываются только раз на весь массив изменяемых данных и при их граммотной реализации особо тормозов не наблюдается. Таблица балансов просто обязана отставать по времени - думаю Вы слышали про понятие банковский день, то есть мы имеем определенный на промежуток времени стабильный и подтвержденный баланс. Мало ли какие операции произойдут за этот промежуток. Всегда должно быть закрытие периода с перерасчетом аггрегатных таблиц, когда информация уже подтверждена, прошла контроль и готова войти в закрытый период. Это используется в любой задаче и мне удивительно, что Вы это игнорируете и пытаетесь влепить банку в реалтайме плавающий баланс. Насчет TIMESTAMP и других таблиц честно говоря ничего не понял. Если Вы имеете ввиду, что у Вас есть еще какие то таблицы, содержащие аггрегированные значения по входящим данным, то они всегда будут соотвествовать действительности, так как все будут пересчитываться одновременно в пределах одной транзакции на момент закрытия периода, как раз в том самом единственно запущенном событии (параллейном потоке). Исходя из вышесказанного просьба - давайте вести обсуждение по конкретной постановке, а не придумывать "А вот если ...".

автор
Таким образом мы имеем весьма нетривиальную задачу обработки транзакцй "ручками". У нас есть очередь транзакций, асинхронный по отношению к потоку транзакций процесс их выполняющий, и данные согласованность которых надо проверять вручную. Зачем нам тогда вообще такая СУБД, если обработку транзакций приходится вручную делать? Чем писать собственный обработчик транзакций, может лучше взять готовый? На мэйнфреймах народ обходится MQ, CICS, вообще данные в файлы (VSAM, ISAM) пишет. Не нужна им СУБД, если конкурентного доступа к данным нет. Ваше решение, уважаемый ASCRUS есть по сути отказ от СУБД в пользу мэйнфреймовой идеологии обработки транзакций.

У меня нет обработки транзакций ручками. Чуть выше я обьяснил почему. У меня есть понятие закрытой (стабильной) точки для аггрегатных (расчетных) таблиц и данные, пока не вошедшие в закрытый период во входящих таблицах. Где здесь транзакции ручками хоть убей не вижу, я вроде тут пользуюсь стандартными транзакциями РСУБД и используя преимущества блокировочника, эффективно без лишнего потребления ресурсов решаю поставленную задачу.

Теперь более подробно разжую мной последнюю предложенную схему:

1. Есть входящая табличка "Движение", в которой регистрируются (то есть добавляются) записи по движению денег клиентов по счетам. В ней есть 2 служебных поля "Обработано" и "ВремяИзменения".

2. Есть аггрегатная табличка "Баланс", в которой на каждого клиента по каждому его счету храниться сумма баланса на закрытый период (банковский день). В ней есть служебное поле "ВремяИзменения" на всякий пожарный, так как здесь оно нам не пригодится.

3. Есть представление "Текущий баланс", в котором есть запрос, обьединяющий данные с таблички "Баланс" с данными с таблички "Движение", выставляя ей фильтр "Обработано = 0 AND TimeStamp <= Now()". Блокировать это представление никого не будет, так как в табличку движение новые данные уже будут добавляться с TimeStamp больше текущего времени на момент вызова представления и целостность будет прекрасно соблюдаться даже на уровне "Non-repeatable read", который не мешает писателям продолжать добавлять новые записи в табличку "Движение".

4. Есть событие (EVENT), которое автоматически запускается СУБД например в 4 часа утра и на этот момент стартует транзакцию, пересчитывает все аггрегатные таблички (в данном случае "Баланс") с учетом внесенных за сутки новых данных, ориентируясь по фильтру "Обработано = 0 AND TimeStamp <= Now", далее выставляет флаг "Обработано" для записей, вошедших в баланс и подтверждает проведение транзакции. Во время проведения транзакции таблица "Движение" идет на уровне изоляции "Non-repeatable read", а таблица "Баланс" на "Phantom row".

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

Кстати заметьте - Вы стали не продукты сравнивать (MSSQLvsOracle), а технологии. А этого делать никогда нельзя, если не знать обе технологии в совершенстве (что даже теоретически представляется сомнительным). Плюс Вы ко всему прочему вместо того, чтобы доказать на практических примерах преимущество версионника, попытались теоретически порассуждать, чем плох блокировочник. Если бы у меня было много свободного времени, то я бы Вам написал 1000 и одно решение на приведенные в пользу версионника задачи, которые бы доказывали, что блокировочник не хуже, а может быть даже и лучше. Все Ваши доводы против моих предложенных схем пока свелись к типовому высказыванию многих знакомых мне ораклистов "Это же думать надо и ручками писать. Круче, когда сама СУБД за тебя думает и делает".

Ну и главное:

OLTP - главная задача быстро собирать входящую информацию и рассчитывать по ней дополнительную. Писатели должны иметь более высокий приоритет перед читателями. Любой блокировочник удовлетворяет этому условию и поэтому я называю его "чистым" OLTP. Если в БД граммотно реализована бизнес-логика, то во входящие таблицы информация только добавляется и почти никогда не обновляется/удаляется, что не накладывает блокировки на уже архивные данные и позволяет читателям выполнять по ним запросы, без конфликтов с писателями. На аггрегатные таблицы, в которых одновременно могут применяться операции добавления, изменения, удаления обычно вешают параллейный поток и обновляют их через определенные промежутки времени, согласно постановке задачи (банковский день, расчетный месяц в зарплате и т.д.).

DSS - главная задача обрабатывать большие массивы информации и иметь быстрый ответ системы на любой запрос без его лимитирования на обьем обрабатываемых данных. Читатели должны иметь более высокий приоритет перед писателями. Обычно данные в такие системы собираются не в реалтайме, а за определенные промежутки времени. Таким образом я называю Terradata и Sybase IQ "чистыми" DSS.

С учетом вышесказанного смотрим на Оракл и видим, что его механизм версионности - это попытка совместить OLTP и DSS, то есть фактически схема "Два в одном". Вот ответьте мне на вопрос, что лучше - "сотовый + цифровой фотоаппарат" или же "сотовый со встроенным фотоаппаратом" ? А не ответите, потому что слово "лучший" в данном случае очень расплывчато. Смотря для чего лучше. Если с точки зрения скорости и качества - то по отдельности всегда было и будет лучше. А если с точки зрения цены и удобства использования, то эффективнее получается сотовик со встроенным цифровиком. Я в данном случае ратую для своих задач "за скорость+качество", а вы "за цену+удобство". Но по моему говорить, что Ваше "Два в одном" круче как минимум не стоит. Для Вас может быть и круче, а лично для меня версионность Оракла - это такой большой и подозрительный мыльный маркетинговый пузырь от компании Оракл для менеджеров и руководителей, на который Вы купились из за недостаточного знания механизмов проектирования БД на блокировочниках и фактически занимаетесь здесь тем, что цитируете рекламные лозунги Оракла. Вот чего меня удивляет, почему бы ораклистам, вместо того, чтобы ставить в заслугу Оракла довольно сомнительный механизм его версионности, не вспомнить о действительно его полезных фичах, которых нет например в MSSQL - кроссплатформенность, партиции, возможность тонкой ручной настройки, множество механизмов индексов, поддержка сжатых таблиц, довольно мощный PL/SQL и приличный оптимизатор запросов и т.д. и т.п. - тут много я за них достоинств привести не могу хотя бы по причине того, что не работал в тяжелых практических проектах с Ораклом. У меня даже начинают возникать смутные подозрения - а может всем этим никто и не пользуется в России на Оракле, может быть все так и продолжают по привычке курсорами гонять и не думая раскатывать по своим сегментам гигантские транзакции, говоря "Пущай, если будет ступориться, тачку помощнее купим, делов то".

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

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

на счет универсальности оракла уже как-то устал показывать на лидируещее положение оракла в тестах как OLPT так и DSS ... в то время как мыльный маркетинговых пузырь sybase не способен показать результат хотябы в разы отстающий от оракла.
23 сен 04, 12:35    [981747]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Yo!
2ASCRUS

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

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

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

Ладно уважаемые коллеги администраторы-ораклисты. Заканчиваем беседу, все равно у нас разные параллейные вселенные и даже если я потрачу на вас свое время и выложу скрипты решений, которые будут эффективно работать, думаю все равно вы останетесь при своем мнении и будете продолжать цитировать маркетинговые лозунги Оракла, даже не вникая в то, что я пишу.

P.S. Возражения и замечания по данному сообщению принимаются. Возражения по всем моим сообщениям выше игнорируются, больше я ничего обьяснять не буду, устал однако :)
23 сен 04, 13:09    [981827]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
ну тут мне осталось наверно только улыбнутся :)

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

реальные тесты реальных задач вы можете посмотреть на http://www50.sap.com/benchmark/

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

реально оракл работает на ERP решениях от SAP, PeopleSoft, Oracle applicatons, MS Navison и других менее крутых.

автор
Может быть в тестах Sybase и не способен показать "колоссальные результаты работы", но вот опять же из практики я сколько не видел банков

список банков в которых работает решения оракла можно посмотреть сдесь:
http://www.oracle.com/customers/index.html

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

наверно именно из-за этих самых результатов все ведущие игроки в ИТ подерживают субд оракл и ни один из лидеров SAP, PeopleSoft, Oracle applicatons, MS Navison непашут на sybase ;)

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

т.е. мое проэктирование заведомо кривое ... логично :)

2ASCRUS
очень бы хотелось кроме слепой веры хоть чуть-чуть посмотреть на факты. вы так и не смогли доказать главного - если ваше решение имеет ограничение то какие бонусы оно за это дает? то что ваша очередь эфективней на данный момент вызывает большие сомнения ...
23 сен 04, 14:06    [982150]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Yo!
наверно именно из-за этих самых результатов все ведущие игроки в ИТ подерживают субд оракл и ни один из лидеров SAP, PeopleSoft, Oracle applicatons, MS Navison непашут на sybase ;)

ASE:
http://www.sybase.com/partner/alliance
http://www.sybase.com/detail_list/1,6902,44640,00.html
http://www.sybase.com/detail_list/1,6902,44634,00.html

ASA:
http://www.ianywhere.com/success_stories/index.html

Это называется так - "Сижу я в своем болоте и знаю, что круче этого болота нету на свете, потому как из за камышей другой местности мне не видно" :)

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

Откуда: МО Электросталь
Сообщений: 5994
Кстати вдогонку - Sybase с SAP и PeopleSoft не просто партнеры, а большие друзья, можно сказать стратегические партнеры. Так что Ваши замечания по меньшей мере были смешны.
23 сен 04, 14:24    [982242]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
мне совершенно не интересны достижения sybase, я вам отведил на конкретные выпады относящиеся к ораклу.

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

SAP - WALLDORF, Germany and DUBLIN, Calif. - 11/17/2003 12:00:00 AM - SAP AG (NYSE: SAP) and Sybase, Inc. (NYSE: SY) today announced a worldwide agreement to deliver integrated solutions by aligning SAP® Business One with Sybase data management solutions for small and midsize businesses (SMBs).

не знаю что такое SAP® Business One ... я говорил о mySAP ERP

PeopleSoft - Sybase’s enterprise database, integration, and infrastructure expertise optimizes PeopleSoft’s Supply Chain Management, CRM, Enterprise Service Automation, Financial, and Human Capital

это все ? а остальное ?

Oracle EBS - мимо
MS Navision - мимо


давайте вернемся к версионости и очередям, а то мерятся уже немного достало.
23 сен 04, 14:40    [982332]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
EugeneS
Member

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


Поле TimeStamp <= NOW(). Так что Ваше высказывания о приложениях только подтверждает мои догадки, что Вы особо не реализовывали сложную бизнес-логику средствами СУБД. Насчет триггеров тоже промашка - в Оракле конечно может FOR EACH ROW и работают медленно и вызываются на каждую запись, но вот в ASA и MSSQL триггера FOR EACH STATEMENT вызываются только раз на весь массив изменяемых данных и при их граммотной реализации особо тормозов не наблюдается.

Мне это напомнило историю, когда примерно лет 10 тому назад, пришел один товаришь и принес программульку для бухгалтерии написанную с использоваением СУБД Paradox и показывал как это круто.
Когда его спросили знает ли о про функционал который предоставляет Oracle ( тогда это был Oracle5 или 6 версии, на что он сказал , что это "херня", потому как он матекматик и все предусмотрел и в этом вопросе понимает лучше .

Насчет триггеров:
Oracle имеет триггера которые срабатывают как в случае FOR EACH ROW так и на уровне оператора, и могут быть как BEFORE так и AFTER .

Насколько я слышал, уровня BEFORE в MSSQL нет , думаю его нет и в SYBASE.
А то о чем вам намекали, это том что внутренние механизмы ядра СУБД отрабатывают события намного быстрей , чем самописные.

ASCRUS

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

А еще есть такая штука , как карточный счет, который должен в обязательном порядке подерживаться в on-line. Иначе вы сможете появляется ситуация когда вы сможете снять со счета больше денег чем у вас есть.

Или сходить в интернет на большее время , чем у вас заплачено, в случае предоставления услуг например Dial-up. Там теже счета, что и в банке, только расчет происходит в момент дисконнекта пользователя.
23 сен 04, 14:45    [982359]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
ASCRUS
Кстати вдогонку - Sybase с SAP и PeopleSoft не просто партнеры, а большие друзья, можно сказать стратегические партнеры. Так что Ваши замечания по меньшей мере были смешны.


Да, блин куда ни кинь у SAP все производители СУБД просто дружбаны.
Не понятно как только они деньги зарабатывают.

У SAP есть такая вещь как sizer ( то есть тест SAP SD benchmark ).
Cпециально чтобы пользователи смогли смасштабировать свои системы , согласно своих потребностей.
Смотреть сюда: www50.sap.com/benchmark


Так там SYBASE как лучшего дружбана даже нет в списках.
Зато там есть такая СУБД как SAP DB, которая на некоторых тестах делает
например MSSQL ( до 8 проц).
Вы не находите это странным?
Я лично нахожу.
23 сен 04, 14:54    [982407]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
EugeneS
Member

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

http://www.sybase.com/partner/alliance
http://www.sybase.com/detail_list/1,6902,44640,00.html
http://www.sybase.com/detail_list/1,6902,44634,00.html


Лезу, открываю.
http://www.sybase.com/detail/1,6904,1032460,00.html

Currently, the SEC system has 200 users across the United States and the data warehouse is 320 gigabytes. With the new growth capabilities of the system, Foster sees the data warehouse quickly expanding to a terabyte of data. 


автор

In addition to Sybase IQ, the new architecture includes Sun Microsystems Sun Fire™ hardware and an EMC Symmetrix® SAN.



Объем просто поражает, особенно с учетом того на каком оборудовании он крутится.
Вот и получается, что Sybase занимает почетное 4 место с 4 процентами рыночной доли, которая постоянно снижается.


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

Откуда: МО Электросталь
Сообщений: 5994
Уважаемые оппоненты с платформы Оракл. Хотелось бы вести с вами двустороннюю беседу, то есть когда я внимательно читаю и думаю над вашими сообщениями, и вы в свою очередь проделываете над моими сообщениями.

Скажите пожалуйста, вот это:
ASCRUS
3. Есть представление "Текущий баланс", в котором есть запрос, обьединяющий данные с таблички "Баланс" с данными с таблички "Движение", выставляя ей фильтр "Обработано = 0 AND TimeStamp <= Now()". Блокировать это представление никого не будет, так как в табличку движение новые данные уже будут добавляться с TimeStamp больше текущего времени на момент вызова представления и целостность будет прекрасно соблюдаться даже на уровне "Non-repeatable read", который не мешает писателям продолжать добавлять новые записи в табличку "Движение".

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

Так же у вас совершенно нет оснований говорить что "Оракл круче, потому что я думаю, что в другой СУБД этого нет или реализовано не эффективно или тесты на каком то сайте доказывают". Думать и доказывать можно много, но лучше знать. Поэтому отвечаю: в Sybase ASE нет BEFORE триггеров, в Sybase ASA они есть. И я вас так же спрашиваю: "А вы знаете, какой есть функционал у той же Sybase ASA ?" и вы на это мне заявляете, что это все херня, потому что это не Оракл, а вы как ораклисты в этих вопросах уж точно понимаете лучше.

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

Вас обижает, что я обвиняю версионность Оракла и его "Два в одном" обычным маркетинговым ходом. Меня же поражает, что вы абсолютно необоснованно высказываете свое мнение о тех СУБД, с которыми не работали и не можете составить обоснованное о них мнение. Причем в таких обвинениях вы даже не удосуживаетесь различать круг задач и ложно создаете впечатление, что Оракл везде полезен и крут, а все остальные далеко позади.

Так что никаких теоретических выкладок пожалуйста - или вы даете конкретные примеры, где действительно MSSQL/Sybase ASE/Sybase ASA/Sybase IQ/IBM DB2/Terradata не справились с задачей и после перевода ее на Оракл произошло чудо, или же просто рассказываете в качестве ликбеза о достоинствах Оракла, не задевая зазря другие технологии и СУБД.

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

Откуда: МО Электросталь
Сообщений: 5994
Кстати не понятно, если все с Ораклом так хорошо, то почему та самая пресловутая MB вешается с ним каждый день и содержит не малый по размерам штат администраторов ? И почему у моего друга сисадмина в конторе месяц назад поставили решение на Оракле и я выслушиваю теперь его поток жалоб на этот "вечный версионный тормоз" ? "Кривые ручки" скажите Вы и будете сто раз правы. Но как же тогда спрашивается супер-версионный механизм Оракла, который по идее сам должен разруливать любые ситуации, где проектировщику не нужно продумывать политику работы читателей и писателей и не задумываться о блокировках ? Почему он вместо разруливания выступает ручным тормозом ? Кто виноват и что делать клиентам ?

P.S. И кстати что делать, если по бизнес-логике потребуется специально заблокировать некоторые данные, чтобы их никто не мог изменить до подтверждения заблокировавшей их транзакции ?
23 сен 04, 15:40    [982639]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
select ... for update [nowait]

его есть у нас.
23 сен 04, 15:55    [982741]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
EugeneS
Member

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

Что такое MB, я честно скажу не знаю.
И почему ваш друг жалуется вам я тоже не могу ответить.
Есть еще такой вопрос как выбор поставщика решения , и тут СУБД Oracle как бы не причем.

Супер-версиионный механизм от Oracle != механизм "защита от дурака" у него другое назнаечение, сохранение старый версий блоков.


ASCRUS

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


В общем случае
select fld1 , ....fldN from table_name fro update of fld1,... N;
23 сен 04, 16:04    [982804]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
автор
не является ли способом получения актуального баланса ? Вы с постоянным упорством продолжаете меня обвинять в том, что я якобы работаю с неактуальными данными, создается такое впечатление, что вы не читали моих постов или же не захотели вникать в то, что в них написано.


упорсто связано с тем что ...
автор
Например, предположим что есть какая-то бизнес-логика связанная с проверкой баланса, читающая из других таблиц (не движение по счетам). Значит в тех таблицах тоже должен быть timestamp дающий нам информацию об актуальности данных. Иначе данные из этих таблиц могут быть по состоянию на 17:02:05 а балансы по состоянию на 17:01:55.


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


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


автор
Вас обижает, что я обвиняю версионность Оракла и его "Два в одном" обычным маркетинговым ходом. Меня же поражает, что вы абсолютно необоснованно высказываете свое мнение о тех СУБД, с которыми не работали и не можете составить обоснованное о них мнение. Причем в таких обвинениях вы даже не удосуживаетесь различать круг задач и ложно создаете впечатление, что Оракл везде полезен и крут, а все остальные далеко позади.

1. нас обидеть можно только зарплатой, т.е. вы пока не сможете :)
2. на счет "маркетинговым ходом", хоть убей не понимаю у нас получается что оракл доказавший свою субд и в независимых тестах (sap&tpc) и в реальных задачах лидеров рынка (sap, ms, peoplesoft) на протежении 30 лет, подвердил тучей сертификатов и независимых коммисий и прочей лабудой - маркетинговый ход ... ок, согдасен а где все это у сайбеза ? или мы должны верить наслово ? смешно.


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

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


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


Уважаемый, если вы считаете, что ваш механизм будет работать быстрей ,чем ядро СУБД , безотносительно какую СУБД вы используете, то либо функциональность СУБД "ниже плинтуса", либо вы чего-то не увидели.
Это обычно просто правило "хорошего тона" если для решения задачи необходимая функциональность есть в СУБД надо ей пользоваться, свой вариант чаще всего будет хуже. Исключение только ранние версии СУБД когда разработчик СУБД еще не "отладился".


ASCRUS


Так что никаких теоретических выкладок пожалуйста - или вы даете конкретные примеры, где действительно MSSQL/Sybase ASE/Sybase ASA/Sybase IQ/IBM DB2/Terradata не справились с задачей и после перевода ее на Оракл произошло чудо, или же просто рассказываете в качестве ликбеза о достоинствах Оракла, не задевая зазря другие технологии и СУБД.


Доказательством тех. возможностей того или иного продукта служат benchmark тесты:
- общие ( типа TPC ) - это типа пузомерки, их часто недостаточно, они часто не отражают ситуацию, но дают общее представление.
- специальные ( типа SAP SD ) - тесты приложений.

Так может вы поясните почему нет тестов SAP SD для SYBASE?
Тем более SAP и SYBASE партнеры.
23 сен 04, 16:23    [982934]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Интересно, а что это вы так плавненько тему на Sybase переводите ? Я привел пример на Sybase ASA (которая кстати на самом деле даже не продукт Sybase) только из за того, что это мой сейчас основной рабочий инструмент. С таким же успехом я мог привести пример на Sybase ASE, MSSQL или DB2. Вы тут вроде как утверждали, что Оракл крут по сравнению со всеми именно из за того, что он версионник, а остальные блокировочники. Ну так и давайте не ограничиваться рамками одной СУБД, а посмотрим на все блокировочники: MSSQL, IBM DB2, Sybase ASE, Sybase ASA, ... Я от их всего имени выступал вообще то, а не от конкретно продукта, вот давайте все их и обсудим на досуге, выдавая по шаблону темы "Почему Оракл круче MSSQL", "Почему Оракл круче DB2", и т.д. Ну а насчет Sybase - мне честно говоря как то все равно, какие там у нее тесты есть, официальная информация всегда лежит у них на сайте, если кого то интересует, то всегда можно ее посмотреть, в том числе и где у нее тесты на SAP. Я лично работаю с iAnywhere Solution, Sybase для нее выступает только как крыша.

P.S. Эк вас задело всех высказывания насчет маркетинговых фишек и "Двух в одном" :) А вместо доказательств опять мне подсовываете ссылочки на тесты и маркетинговые заявления. Мне пожалуйста "Success story" с цифрами - какая СУБД стояла, какие были нагрузки и техника, почему был выбран Оракл для замены решения и что клиент от этого выиграл. Я человек недоверчивый и пока я как то не увидел в Оракле чего то революционного, что нельзя было бы эффективно решить средствами связки "Блокировочник OLTP" + "Аналитический сервер DSS".

автор
1. нас обидеть можно только зарплатой, т.е. вы пока не сможете :)

Гм - и тут вы оказывается уверены и знаете, что гарантировано получаете больше меня из за своего знания Оракла :)
23 сен 04, 17:43    [983399]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
давайте вернемся к балансу на текущее время, а унивесальность оракла в другой, ок ?

для начало ответе все таки Злому:
автор

Например, предположим что есть какая-то бизнес-логика связанная с проверкой баланса, читающая из других таблиц (не движение по счетам). Значит в тех таблицах тоже должен быть timestamp дающий нам информацию об актуальности данных. Иначе данные из этих таблиц могут быть по состоянию на 17:02:05 а балансы по состоянию на 17:01:55.


если очень нужно привязатся к задаче давайте берем кто-то тут предложил онлаин казино. тысячи юзеров/транзакций, каждую секунду баланс меняется. на монитор выводим в реал-тайме график выйгрышей, чтоб не проеба[censored] момент когда народу "слишком" повезло.
23 сен 04, 18:04    [983507]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
какие-то вы все "версионщики" действительно странные.
Ну допустим надо Вам постоянно правильная сумма по муллиону записей - есть у вас такая возможность постоянно скаладывать никого не блокируя - вот вы так и делаете. А если подумать: можно же эту сумму постоянно пересчитывать при вводе каждого выигрыша - и не надо постоянно муллионы складывать и спокойно без версионности можно.

Кстати, правильно ли я понял что эта версионность спасает только если данные "для посмотреть"? Что-то менять на основании этих данных я не могу - хоть они и закоммиченные, но всё равно могут быть устаревшие.
23 сен 04, 18:32    [983592]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
protector
Member

Откуда: Иваново, Россия
Сообщений: 600
SergSuper
Кстати, правильно ли я понял что эта версионность спасает только если данные "для посмотреть"? Что-то менять на основании этих данных я не могу - хоть они и закоммиченные, но всё равно могут быть устаревшие.

Истину глаголишь. Так и есть.
23 сен 04, 19:23    [983720]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить