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

Откуда: МО Электросталь
Сообщений: 5994
Кстати вдогонку про друга - он сейчас в Москве тем же самым занимается, дописывает и сопровождает в команде проект, написанный на ASA и PB, только уже в качестве клиентов выступают Австралия, Китай, США и еще куча стран. И это нормальная ситуация для ASA, если залезть на сайт iAnywhere и посмотреть "Success Story", то как раз основная масса реализованных на ней решений работает по всему миру как тиражные продукты, ПО для удаленных филиалов и мобильные СУБД для КПК - всего в мире порядка 20 000 зарегестрированных разработчиков ASA и 8 миллионов инсталяций СУБД их ПО у клиентов и это говорит не о том, что ASA там популярна, а о только том, что ее способности работать без админов прекрасно находят применение во многих нишах.
24 сен 04, 13:55    [985393]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Guest_2
автор
Хорошо по-русски.
Вместо того чтобы сосредоточится на разработки бизне-логики проекта, вы вдобавок сосредотачиваетесь на логике самописного монитора транзакций.
Итого имеет
- разработать свой монитор транзакций
- разработать софт который требует заказчик.
Вместо
- просто разработать софт который требует заказчик.

А где Вы увидели в примере ASCRUS'a монитор транзакций?
То что он написал не выходит за рамки, говорю в Ваших же терминах, разработки бизне-логики проекта.


В таком случае "написание свой СУБД" можно тоже классифицировать как
разработку бизне-логики.
24 сен 04, 13:55    [985396]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
2Злой.
да нет у него монитора :) там все гораздо прроще - фоновый процесс дубово блокирует всю таблицу баланса, чтоб ненароком никто по балансам неконсистентный отчет не снял, и меняет баланс + подчищает лог транзакций. а то что баланс не консистентен с другими табличками - так это фигня, пишем что это фича.

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

Откуда:
Сообщений: 1255
ASCRUS
Кстати вдогонку про друга - он сейчас в Москве тем же самым занимается, дописывает и сопровождает в команде проект, написанный на ASA и PB, только уже в качестве клиентов выступают Австралия, Китай, США и еще куча стран. И это нормальная ситуация для ASA, если залезть на сайт iAnywhere и посмотреть "Success Story", то как раз основная масса реализованных на ней решений работает по всему миру как тиражные продукты, ПО для удаленных филиалов и мобильные СУБД для КПК - всего в мире порядка 20 000 зарегестрированных разработчиков ASA и 8 миллионов инсталяций СУБД их ПО у клиентов и это говорит не о том, что ASA там популярна, а о только том, что ее способности работать без админов прекрасно находят применение во многих нишах.


Уважаемый я не обсуждаю СУБД ни для ПК ни для КПК.
Для них с успехом подойдет старый добрый Fox-Pro или Access, да все что угодно.
24 сен 04, 14:18    [985471]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Yo!
2ASCRUS
вы предлагаете мерятся саксес стори оракла и сайбеза ? может друзьями ? :) я конечно понимаю что вас немного задело, но мы ж вроде не труд всей вашей жизни опустили. не стоит совсем терять лицо и пытатся затмить ошибки крутостью сайбеза. сайбез это для малого бизнеса и с ораклом совершенно не конкурирует и не нада нам сказки про банки, нефть и кластера, мы этого от оракла достаточно налушались, давайте завязывать с маркетингом и вернемся к техническим аспектам, у ?

Действительно Sybase ASA позиционируется как SMB и мобильные решения и я не вижу в этом ничего плохого - это реальная ниша с реальными финансовыми перспективами (в качестве доказательства я привел их success story, а не для того, чтобы меряться). А вот насчет высказывания "сайбез это для малого бизнеса и с ораклом совершенно не конкурирует" то я скажу наоборот - это Оракл в решениях SMB с Sybase ASA совершенно не конкурирует и проигрывает по всем позициям: цене, требованиям железу, стоимости разрабки и сопровождения решений, администрированию и т.д. Опять же я это говорю не к тому, чтобы "опустить" Оракл, а чтобы показать Вам, что задач много и для каждой может оказаться эффективным тот инструмент, который на другой задаче показал бы себя неэффективным. Когда Вы признаете сей простой факт и подтвердите тот факт, что Оракл может быть где то и крут, но не везде и не для всех решений, тогда мы сможем двинуться дальше и сможем завязать с маркетингом, у ? :)

автор
Уважаемый я не обсуждаю СУБД ни для ПК ни для КПК.

Ну как же - Вы же заявили, что версионник Оракл круче блокировочников. Sybase ASA является промышленной кроссплатформенной масштабируемой СУБД от КПК и ПК до уровня серверов без накладывания ограничений на кол-во процессоров или RAM, с реализацией механизма блокировщика. Соотвествующе Ваши высказывания относились и к ней, потому что в своих высказываниях Вы нигде не уточнили, что Оракл круче блокировочников именно для ниши больших корпоративных хранилищ данных с тяжелой нагрузкой и условиями работы в реалтайме. Уточнили бы, я и в спор с Вами ввязываться не стал, это не моя ниша и меня на текущий момент не интересуют такие вещи. Вот как появится необходимость освоения и эксплуатации Sybase IQ, тогда и тема для разговоров появиться на этом поприще :) И кстати вопросик - почему не обсуждаете то ? Считаете ниже собственного достоинства или же просто никогда не делали тиражных решений для SMB и не имеете достаточно опыта для обсуждения онных ?

автор
Для них с успехом подойдет старый добрый Fox-Pro или Access, да все что угодно.

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

All
Так что если мы будем конкретизировать свои высказывания и оперировать фактами, а не высказываниями "Круто", "Революция", "Если", "Я думаю" и т.д., то тема топика вернется в конструктивное русло и вместо того, чтобы спорить, что круче - троллейбус или танк, может быть сможем перейти к непредвзятому обсуждению различных существующих СУБД, их достоинств и недостатков и перспектив развития, причем для каждой отдельно взятой ниши.
24 сен 04, 17:13    [986230]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
автор
Ну как же - Вы же заявили, что версионник Оракл круче блокировочников. Sybase ASA является промышленной кроссплатформенной масштабируемой СУБД от КПК и ПК до уровня серверов без накладывания ограничений на кол-во процессоров или RAM, с реализацией механизма блокировщика.

Где доказательства. про масштабируемость?
То есть если софт работает на разных платформах, это еще не значит что он хорошо масштабирутеся , он просто работает.

Где тесты подтверждающие масштабируемость?
Какими тестами это подтверждается ?
Success story по вашему это достаточное подверждение?
Я технический специалист и мне нужны цифры, а не сказки типа "Success story" , коих полно у каждой компании производителе софта.
Это обычное маркетинговое фуфло, и не важно от кого оно от Oracle, Sybase или Microsoft. Cуть от этого не меняется.

автор
Соотвествующе Ваши высказывания относились и к ней, потому что в своих высказываниях Вы нигде не уточнили, что Оракл круче блокировочников именно для ниши больших корпоративных хранилищ данных с тяжелой нагрузкой и условиями работы в реалтайме.
Уточнили бы, я и в спор с Вами ввязываться не стал, это не моя ниша и меня на текущий момент не интересуют такие вещи. Вот как появится необходимость освоения и эксплуатации Sybase IQ, тогда и тема для разговоров появиться на этом поприще :) И кстати вопросик - почему не обсуждаете то ? Считаете ниже собственного достоинства или же просто никогда не делали тиражных решений для SMB и не имеете достаточно опыта для обсуждения онных ?

1. Oracle насколько я знаю никогда к Real-time системам и не относился.
Он вообще-то СУБД общего назначения.
2. Почему мне не интерестны решения КПК?
Это очень просто, сделать софт для однопользовательского режима меня уже давно не "возбуждает", а вот софт для того чтобы с ним могли работать одновременно несколько сотен чел. это совсем другое.
Ну это из той серии почему мне не интересен Запорожец, а интересен Мерс.
Это лично мое мнение. Технических решений которые и
использовались при производстве Мерседеса в разы больше.
Далее, достоинства или необходимость механизма мульти-версионности, проявляется при конкурентном доступе, и соответственно мультиверсионность необходима для крупных решений или тяжелых, там где есть конкурентный доступ.
Я очень сильно сомневаюсь , что на КПК есть необходимость конкурентном доступе, поэтому тут подойдет любое решение, хоть плоский файл, хоть sql бд, лишь бы в ресурсы втиснуться.
Или вы сможете там развернуть БД объемом несколько GB ?
Предполагалось, что если вы заговорили про версионность речь идет о конкурентном доступе, а следовательно о крупных решения, ну минимун решениях уровня рабочих групп, ну никак не однопльзовательский режим.

3. Вы вообще на сайт Oracle когда-нибудь заходили ?
Достали вы меня со своими КПК.
Вас интересует есть ли у Oracle для этого продукты.
Да, есть ну и что?
Я не вижу никакого интереса в использовании Oracle на КПК, но если это будет необходимо, это возможно сделать.
То что вас интересует называется
автор
Oracle Database Lite

Key Product Features

Lightweight Enterprise class database for Windows CE, Palm Computing Platform, Symbian EPOC, and Windows 95/98/NT
Full JDBC & ODBC support on all platforms
Web-based centralized deployment and management on all platforms
Built-in, highly scaleable two-way data synchronization over any connection: Internet, wireless, LAN, etc.

Ну и что дальше?
Уверен у Sybase позиционирование продуктов подобное.
И то, что можно сделать на Enterprise server , нельзя сделать на KПК.
Что здесь удивительного?
Что вы мне хотели доказать?
Что мультиверсиионность не нужна, в однопльзовательском режиме ?
Так это и коню понятно.
24 сен 04, 17:52    [986407]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
хорошо, хорошо - вы убедили, просто давайте сайбез заменим на mysql, а оракл на сайбез, смотрите как смешно получается:

Действительно MYSQL позиционируется как SMB и я не вижу в этом ничего плохого - это реальная ниша с реальными финансовыми перспективами (в качестве доказательства я привел их success story про yahoo и NASA, а не для того, чтобы меряться). А вот насчет высказывания "MYSQL это для малого бизнеса и с SYBASE совершенно не конкурирует" то я скажу наоборот - это SYBASE в решениях SMB с MYSQL совершенно не конкурирует и проигрывает по всем позициям: цене, требованиям железу, стоимости разрабки и сопровождения решений, администрированию и т.д. Опять же я это говорю не к тому, чтобы "опустить" SYABSE, а чтобы показать Вам, что задач много и для каждой может оказаться эффективным тот инструмент, который на другой задаче показал бы себя неэффективным. Когда Вы признаете сей простой факт и подтвердите тот факт, что SYABASE может быть где то и крут, но не везде и не для всех решений, тогда мы сможем двинуться дальше и сможем завязать с маркетингом, у ? :)

MYSQL является промышленной кроссплатформенной масштабируемой СУБД от КПК (linux и не на таком живет) и ПК до уровня серверов без накладывания ограничений на кол-во процессоров или RAM (к стате mysql нихера и не накладывает), с реализацией механизма блокировщика. Соотвествующе Ваши высказывания относились и к ней, потому что в своих высказываниях Вы нигде не уточнили, что SYBASE круче блокировочников именно для ниши больших корпоративных хранилищ данных с тяжелой нагрузкой и условиями работы в реалтайме. Уточнили бы, я и в спор с Вами ввязываться не стал, это не моя ниша и меня на текущий момент не интересуют такие вещи. Вот как появится необходимость освоения и эксплуатации MYSQL MAX, тогда и тема для разговоров появиться на этом поприще :) И кстати вопросик - почему не обсуждаете то ? Считаете ниже собственного достоинства или же просто никогда не делали тиражных решений для SMB и не имеете достаточно опыта для обсуждения онных ?
---------

комизм в том что я набравшись пивом с умной рожой смогу вам часами рассказывать о крутости mysql ничуть не хуже чем вы мне про сайбез. :)
24 сен 04, 18:24    [986565]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Это обычное маркетинговое фуфло, и не важно от кого оно от Oracle, Sybase или Microsoft. Cуть от этого не меняется.

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

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

Уважаемый, все что я говорил относилось к SMB (я даже это подчеркнул), SMB расшифровывается как Small Medium Buiness, то есть это не КПК, а те самые решения для рабочих групп, для которых насклолько я понимаю Вы тоже продолжаете утверждать, что Оракл будет выгоднее, чем использование Sybase ASA :) Если это так, то нам есть о чем поговорить, если Ваши утверждения касаются только крупных хранилищ данных, то тут я не спорщик, у меня другое направление работы, не касающееся этого направления.

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

Я хотел Вам просто доказать, что для каждого решения свой инструмент. я человек терпеливый и готов это доказывать в своем каждом топике :)

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

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

про SMB и оракл - берем наш пример, берем грубо цены ASE ~ $1K, oracle one ~$5K = разница $4K. я лучше потрачу $4K на оракл, чем буду наблюдать как вы на мои деньги будете воротить плохо маштабируемую систему с ограничения типа "банковский день" с совершенно не гарантируемым результатом. зачем мне это если я даже не могу предпложить в какие деньги мне выльется подержка системы с таким хитрым алгоритмом. а если мне нужно будет баланс с другими табличками связать ? этот геморой не стоит 2х типовых писюков.
24 сен 04, 18:40    [986603]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
EugeneS
Member

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

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


Это так кажется на первый взгляд, на самом деле мне безразлично.
Уровень специалиста тем выше , чем проще решения он предлагает.
Есть такой термин технологичность продукта.
Это, когда один сделал, а другой в его отсутствии завсегда исправить может без матюков.
Это когда открываешь чужой код и восхищаешься красотой, того что человек сделал.
А когда он правой ногой левое ухо чешет, ну что тут сказать.
Плакать надо. И при чем тут загибание пальцев?

Ваше решение , которое вы предлагали выше в этом топике, не из этой серии.
Об этом вам говорили куча народа, а вы упорно не соглашались с этим, занимаясь изобретениями "велосипедов".
Знаете я, за 10 лет уже такие "велосипеды" видел, меня редко чем можно удивить.

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

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

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

про SMB и оракл - берем наш пример, берем грубо цены ASE ~ $1K, oracle one ~$5K = разница $4K. я лучше потрачу $4K на оракл, чем буду наблюдать как вы на мои деньги будете воротить плохо маштабируемую систему с ограничения типа "банковский день" с совершенно не гарантируемым результатом. зачем мне это если я даже не могу предпложить в какие деньги мне выльется подержка системы с таким хитрым алгоритмом. а если мне нужно будет баланс с другими табличками связать ? этот геморой не стоит 2х типовых писюков.


Точно в яблочко.
24 сен 04, 18:45    [986612]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
-----------
Guest
EugeneS
[quot автор]
Что вы мне хотели доказать?
Что мультиверсиионность не нужна, в однопльзовательском режиме ?
Так это и коню понятно.
Не знаю чем занимаются на компьютере кони,
а у меня в виндах режим хоть и однопользовательский, но многозадачный
24 сен 04, 18:48    [986619]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
-----------
EugeneS
[quot автор]
Что вы мне хотели доказать?
Что мультиверсиионность не нужна, в однопльзовательском режиме ?
Так это и коню понятно.
Не знаю чем занимаются на компьютере кони,
а у меня в виндах режим хоть и однопользовательский, но многозадачный


И вы конечо в разных окнах одновременно сможете создать ну просто сумашедший поток транзакций ?

На КПК надо полагать тоже?

Да, пятница явно удалась.
24 сен 04, 18:50    [986623]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
EugeneS
Member

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

про SMB и оракл - берем наш пример, берем грубо цены ASE ~ $1K, oracle one ~$5K = разница $4K. я лучше потрачу $4K на оракл, чем буду наблюдать как вы на мои деньги будете воротить плохо маштабируемую систему с ограничения типа "банковский день" с совершенно не гарантируемым результатом. зачем мне это если я даже не могу предпложить в какие деньги мне выльется подержка системы с таким хитрым алгоритмом. а если мне нужно будет баланс с другими табличками связать ? этот геморой не стоит 2х типовых писюков.


Точно в яблочко.


Еще добавлю, если взять разницу в 3к, это для приличного программера на Украине ЗП за 3 мес одному.
Рисковать данными банка за 3 мес зарплату?
Тем более банки не такие бедные, чтобы на таком экономить.

Простой пример задачка "учет материальных ценостей"
Для обычных предприятий стоил -100$
Аналогичный софт для банка обходился в 500-700$
( это было в мою бытность работы в банке, вряд ли что-то по другому стало сейчас ).
24 сен 04, 18:56    [986631]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Yo!
2ASCRUS
про SMB и оракл - берем наш пример, берем грубо цены ASE ~ $1K, oracle one ~$5K = разница $4K. я лучше потрачу $4K на оракл, чем буду наблюдать как вы на мои деньги будете воротить плохо маштабируемую систему с ограничения типа "банковский день" с совершенно не гарантируемым результатом. зачем мне это если я даже не могу предпложить в какие деньги мне выльется подержка системы с таким хитрым алгоритмом. а если мне нужно будет баланс с другими табличками связать ? этот геморой не стоит 2х типовых писюков.

Ограничения "типа банковский день", расчетный месяц в зарплате или кварплате или еще чего - это вообще то условие постановки задачи, описанное законодательством, а не ограничение. Исходя из него Вы по любому в понятиях "опердень" (или банковский день) будете фиксировать остатки/баланс на определенный момент времени. Если же Вы не будете соблюдать постановку задачи и вместо хранения остатков все время пересчитывать аггрегатами по табличкам с входящей информацией, думаю вряд ли найдете для своего продукта клиентов по соотвествующему решению. Ваши же рассуждения, что деньги "пофиг", главное чтобы круто было, мы уже вместе обсуждали и не раз. У меня, например, уже находится в опытной эксплуатации проект "Управление персоналом предприятия", в комплект которого входит расчет заработной платы, что для РФ не самая легкая задача, планируемый обьем клиентов - сотни, требования к продукту - низкие аппаратные требования (вряд ли конторка из 50 человек будет себе навороченный сервак для расчета зп и кадров покупать), низкая конкуретноспособная цена (у нас СУБД ASA будет входить как встраиваемая СУБД в состав продукта и бесплатно поставляться вместе с ним, клиенты будут оплачивать только лицензии из примерного расчета 100$ на одно рабочее место, что снижает общую стоимость всего продукта), масштабируемость (программе должно быть все равно, сколько рабочих мест - 1 или 100 и сколько народу считать - 50 сотрудников или 100 000, во всех случаях нужно высокое быстродействие), нулевое администрирование (интересно посмотреть, как без этого требования можно сопровождать свой продукт у сотен клиентов) и функциональность (из за непрерывного изменения трудового и налогового кодекса РФ и сложности алгоритмов расчетов неплохое решение для такой задачи - это перенос всей бизнес-логики и расчетов на ХП, с организацией хранения истории изменения самих алгоритмов расчета, которое вытекает из за возможности изменения почти любой входящей информации пользователями задними числами, с последующим сторнированием в расчетах, т.е. в закрытых периодах, наличие которых Вы упорно отвергаете). Вот пожалуйста - вот Вам и задача, на которой как раз Оракл окажется не выгодным и для которой как раз на нем кроме геммороя с установкой и администрированием и завышенной стоимости разработки и цены продукта ничего не получишь.

автор
берем грубо цены ASE ~ $1K, oracle one ~$5K

На всякий случай: Sybase ASA (разработчик - iAnywhere Solution, бывший Watcom) != Sybase ASE (разработчик - Sybase) ни в чем, разве что на уровне поддержки в качестве дополнительного диалекта TSQL для совместимости с ASE. Я с Sybase ASE не работал и поэтому не могу обсуждать ее достоинства, недостатки и ценовую политику. Так что давайте обсуждать, то что хорошо знаете Вы и то, что неплохо знаю я :)
24 сен 04, 19:08    [986664]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
EugeneS
Ваше решение , которое вы предлагали выше в этом топике, не из этой серии.
Об этом вам говорили куча народа, а вы упорно не соглашались с этим, занимаясь изобретениями "велосипедов".
Знаете я, за 10 лет уже такие "велосипеды" видел, меня редко чем можно удивить.

Ну давайте и здесь померяемся :) Я за 13 лет профессиональной работы тоже не мало велосипедов насмотрелся, ими вообще никого не удивишь :) А сам лично велосипедов не изобретаю - Вас послушать, так я только и делаю ежедневно, что борюсь с блокировками своих СУБД :) Повторяю еще раз лично для Вас - здесь задали вопрос, как вот это сделать на блокировочнике, я подал идею, как это можно было бы сделать, если уж сильно бы прижало именно так сделать. Сам я так никогда не делаю, потому что у меня нет дурной привычки бороться с блокировками и вообще механизмами работы СУБД, наоборот я их люблю, ценю и пользуюсь их преимуществами, там и для тех задач, где они действительно являются преимуществами и в реальной жизни никогда не делаю так, как предложили в примере по той простой причине, что так на блокировочнике не принято делать. Думаю теперь мы вполне достаточно осветили вопрос велосипедов, убедились в высоком профессионализме друг друга и не будем обвинять других в том, чего нет, у ? :)

автор
Да, пятница явно удалась.

Угу. А вообще это полезно - учиться правильно спорить, не скатываясь на голословные утверждения и безосновательные выводы, так что день прошел не зря, я получил массу удовольствия :)
24 сен 04, 19:22    [986681]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
мне не мнтересны сказки про ваш чудесный велосипед, вы это лучше клиентам своим рассказываете. мы обсуждали конкретный пример с конкретной реализацией.
итак я утверждаю что реализация SMB задачи "онлаин казино" по описанаму вами алгоритму где 100 онлаин клиентов будет на оракле дешевле, надежней, более маштабируема и прочее. аргументы:

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

ЗЫ. oracle standart one стоит $149 на рабочее место vs 100$ сайбеза. это составляет 10 молочных коктелей по ценам Pulp Fiction ...
24 сен 04, 19:42    [986722]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
killed
автор
Я бы сказал - нашлепка сверху. Изначально же в Oracle не было этой фичи с получением данных из сегмента отката. Потом добавили.


Сможешь вспомнить, когда, в каком году эта "нашлепка" была сделана?


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


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

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

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

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

Сурово, ничего не скажешь :)

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

Прошу уточнения, какой именно алгоритм имеется ввиду ? Если Вы насчет таблички, в которой хранятся аггрегатные значения баланса на каждого клиента, то еще хочу поинтересоваться - а Вы правда что ли каждый раз баланс рассчитываете по всей истории клиентов ? (просто стало интересно)

Yo!
ЗЫ. oracle standart one стоит $149 на рабочее место vs 100$ сайбеза. это составляет 10 молочных коктелей по ценам Pulp Fiction ...

Еще пару вопросиков - разрешается ли мне включать в комплект своего ПО сам сервер бесплатно, есть ли у этой версии Оракла какие либо ограничения на размер БД, границу поддержки конфигурации сервера и т.д. Так же интересует - могу ли я включить Оракл как пакет для инсталяции вместе со своим приложением (например в InstallShield), чтобы он автоматически инсталировался при инсталяции программы ?

Ну и последние вопросики - насколько эта версия Оракла требует наличия администратора, может ли она после инсталяции самостоятельно настроиться и привязаться к конфигурации сервера клиента и работать без какого либо требования, за исключением критических ситуаций, к присутствию человеческого фактора (в том числе по расписанию делать проверки, различные виды Backup-ов, в онлайне, в офлайне, с зеркалированием на другой сервер, с их хранением на другом сервере и т.д.). И можно ли средстами Оракла подключить к своему ПО реакцию на эти критические ситуации и написав свой интерфейс только силами клиента восстанавливать работоспособность БД от поднятия бакупов и накладывания логов, до автоматической перезагрузки структуры и данных БД в новую ?

P.S. Про криптографию БД и логов не спрашиваю, и так знаю, что в Оракле ее нет :)

автор
OK, считаем тот алгоритм не удачным ! предложите другой, вы профи с 13 летним стажем для вас это не должно составить труда. задача "онлайн казино" - есть баланс, есть движение по счетам, есть длинные отчеты.

Для SMB решения, где максимальное кол-во пользователей 100 и БД не дотягивает до 100гб, вполне приемлимым решением будет повесить на табличку "Движение" триггер AFTER INSERT FOR EACH STATEMENT, который будет к балансу просто прибавлять/отнимать суммы, прошедшие по движению в проводимой транзакции, причем одним запросом. Длинного отчета в SMB к сожалению не получится из за кол-ва клиентов и обьема БД, можно правда смодулировать долгий отчет, однако в данном случае в ХП такого отчета будет достаточно обьявить DECLARE LOCAL TEMPORARY TABLE NOT TRANSACTIONAL, в режиме serializable загрузить в нее нужные данные с баланса и сделав COMMIT делать свой долгий отчет сколько влезет. Даже если у 100 клиентов будет по 100 счетов, то это будет ровно 10 000 записей в балансе, которые в нелогируемую времянку перенесутся буквально за секунды и никто из клиентов, продолжающих пополнять свой счет особо не пострадает.

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

Откуда: Северная Калифорния
Сообщений: 686
По поводу предложенного ASCRUS решения, согласен с Yo, монитора транзакций там действительно нет. Ибо процесс выполняющий транзакции там ОДИН, соответственно координировать там нечего. Мы просто поставили транзакции в очередь и выполняем по одной. Зачем нам тогда вообще СУБД? При таком подходе можно вообще все в файлы писать, только надо написать фоновый процесс архивирующий логи и приблуду позволяющюю их накатить "если что".

ASCRUS

1. С помощью временных локальных и глобальных таблиц
2. С помощью автоматически пересчитываемых аггрегатных постоянных таблиц
3. С помощью специального значения timestamp
4. Проектирование входящих таблиц так, чтобы в них только добавлялась, но редко изменялась и тем более удалялась информация
5. С помощью анти-фантомной блокировки, сужающей круг блокирующихся записей, если СУБД это умеет делать и присутствует подходящий уникальный индекс
6. Тщательным продумыванием применения наиболее подходящих для разных задач уровней транзакций
7. Проектированием "коротких" транзакций
8. Созданием таблиц-буферов
9. Созданием параллейных потоков с помощью событий и агентов расписаний.


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

Что до параллельных потоков и их координации с помощью событий, уважаемый ASCRUS видимо плохо представлячет масштаб этой задачи. Задача - что-то типа BEA Tuxedo написать, грубо-то говоря. Беремся за такую задачу, или ну его нафиг? Я лично не берусь, ибо ресурсов и бюджета у меня на такое не хватит. Если у вас хватит - рад за вас. Иначе получится некий полиатив.

Тщательной продумывание транзакций - просто "здоровый подход" к решению любой задачи. В том числе и данной.

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

ASCRUS

Ничего себе чепуха. Вот обьясните мне непонимающему что будет в следующей ситуации:
1. Есть Table1 и связанная с ней по FOREIGN KEY Table2.
2. Транзакция A начала добавлять записи в Table2, ссылаясь на родителей, уже существующих в Table1
3. Чуть позжее транзакция B начала выполнять запрос:
DELETE FROM Table
WHERE Table1_id NOT IN (SELECT Table1_id FROM Table2);
4. Пока транзакция A продолжала возиться, транзакция B выполнила COMMIT -ведь Оракл ничего не блокирует и подзапрос читатель B не будет ждать писателя A, а просто успешно удалит записи из таблицы Table1, на которые ссылаются добавляемые в этот момент из транзакции A, ведь правда ?
5. Транзакция A выполняет наконец таки COMMIT, делает CHECK ON COMMIT (кстати проверки всегда только на коммите выполняются ?), получает ошибку FOREIGN KEY на несуществующих родителей и откатывается.

Я все правильно понял или у Оракла есть механизм регулирования таких ситуаций ?


Совершенно верно поняли, уважаемый ASCRUS, такой механизм в Оракле конечно есть. В Оракле по умолчанию ограничения целостности проверяются сразу, а не по коммиту. Если уровень изоляции read_commited (по умолчанию), то на шаге 3 ваша транзакция В заснет на блокировке. Соответственно commit она выполнить не сможет. А когда транзакция А выполнит commit, то транзакция В получит отлуп "ORA-02292:integrity constraint ... violated - child record found".

Естественно в Оракле constraint может проверяться не сразу, а по commit'у. Последний в оракле называется deffered. Кроме того он может быть "on delete set null" или "on delete cascade". Играясь с уровнями изоляции транзакций, разными типами constraint'ов, и select ... for update nowait я могу добиться ЛЮБОГО разумного (и иногда неразумного) поведения в данной ситуации. Скажите какое "разумное" поведение в данной ситуации вас устраивает, а я вам скажу как это сделать в Оракле с использованием стандартных механизмов данной СУБД.
24 сен 04, 20:35    [986792]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
onstat
Guest
Yo!

итак я утверждаю что реализация SMB задачи "онлаин казино" по описанаму вами алгоритму где 100 онлаин клиентов будет на оракле дешевле, надежней, более маштабируема и прочее. аргументы:


Yo!


OK, считаем тот алгоритм не удачным ! предложите другой, вы профи с 13 летним стажем для вас это не должно составить труда. задача "онлайн казино" - есть баланс, есть движение по счетам, есть длинные отчеты.



Опа ........

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

По oracle никакого решения пока представлено вообще небыло.

Когда ASCRUS предлагал решение, задача была очень общей,
теперь мы ее конкретизируем и расставим все точки на i.


Предлагаю Отчеты
Кличестово(сумма) фишек в банке?
Количество(сумма) фишек в игре(размер ставок на текущий момент).
Количество (сумма) фишек выигранных игроками?
количество (сумма) фишек проигранных игроками?

Как будем идентифицировать играков и их ставки, если будем?

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

Транзакции предлагаю грузить через sqlldr паралельно в 10-50 сессий.
Отчеты формировать паралельно(одновременно) через sqlplus одновременно с загрузкой.

количество транзакций ~10 000 000 .

Жаль я незнаю названия соответствующих утилит для Sybase.

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

Согласны ?

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

количество транзакций ~10 000 000 .




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


нет это слишком просто, такое я на mysql гораздо эфективней реализую.

2ASCRUS
у нас стремительный 21 век и передовые технологиепусть будет система расчета риска и прогнозирования. берем наших юзеров и раскладываем на тучу профайлов. типа страна, диапозон даты регистрации, текущий баланс, кол-во выйграных партий, и т.п. это дело анализируем и получаем что-то типа англичане с карточкой маэстро в bank of amercica играющие в преферанс от 3х до 5 лет, зарабытывающие хоть в одной игре 50 очей в пуле имеют высокий шанс увеличить свой текущий баланс. расставляем грузы и в результате у нас некая система которая прогнозирует выйгрыши и если прогноз зашкаливает некую отметку мы сигнализуруем. естественно подробности алгоритма нам не важны главное что мы знаем что оно предположительно расчитывается не менее 5 минут и для расчета ему нужен лог выйгрышей и текущий баланс. мы ставим этот алгоритм в джоб раз в 10 минут чтоб вовремя сигнализировать (прогонять такое во время каждой транзакции не реально).

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

ЗЫ. не нравится казино (я там тоже небыл) предложите сферу деятельности я легко поменяю персонажи.
ЗЗЫ. мне казалось что по меркам штатов SMB это оборот в $10 лимонов, а 50 юзеров это ниша фокспро. но готов поверить наслово что это не так :)
24 сен 04, 22:30    [986951]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
я и ёжик

Зл0й


Например в случае serializable СУБД нам гарантирует что все данные которые мы читаем, будут "по состоянию на время начала читающей транзакции".

Это не так, в случае serializable СУБД нам гарантирует, что в результате выполнения некоторого набора транзакций мы получим результат который соответствует некоторому последовательному выполнению этих транзакций.
В случае чисто-блокировочного механизма реализации менеджера транзакций, все данные которые мы читаем в Serializable будут скорее "по состоянию на момент КОНЦА читающей транзакции".


Я не уточнил, что имел ввиду поведение Оракла, а не поведение предписанное ANSI-стандартом, наблюдаемое в СУБД-блокировщиках. Согласно ANSI-стандарту у транзакций должна быть иллюзия их последовательного выполнения. Если транзакции друг другу мешают, то одна работает а остальные её ждут. Достигается это с помощью блокировки. В Оракле иллюзии последовательного выполнения нет. То есть, в Оракле, если обе сессии serializable:

время: сессия: событие
-------------------------------
T0: S0: select max(id) into :s0_var from my_table --s0_var := 25
T0: S1: select max(id) into :s1_var from my_table --s1_var := 25
-------------------------------
T1: S0: insert into my_table values(s0_var, 'session 0'); commit; --отработает нормально
T1: S1: insert into my_table values(s1_var, 'session 1') --вернет ошибку ORA-00001: unique constraint ... violated

Иллюзия того что сессии работают последовательно нарушена. Согласно ANSI-стандату она должна быть. В СУБД-блокировщиках она достигается путем блокирующего чтения, в ущерб масштабируемости. В Оракле, если захочу, я тоже могу иметь блокирующее чтение с помошью select ... for update и достигну того же результата что и блокировщик. А могу и не иметь, если не хочу. Могу например использовать для генерации id такую штуку как sequence. Масштабироваться будет заметно лучше чем selec max(id)+1 с блокировкой.
24 сен 04, 22:41    [986957]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить