Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 9 10 [11] 12 13   вперед  Ctrl
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
Yo!! - я что-то рассказывал, но видимо нежоходчиво.
сам виноват
а вот то, что ниже - это постановка задачи?
Если да, то я теперь не удивляюсь, что звонит "партнер", и говорит, мы вот систему сделали телеканалу, а она "легла"...
Я спрашиваю - что значит "легла"?
А, говорят, простой запрос, оказывается, около 20 минут.
Встречный вопрос - а сколько должно быть? Какие объективные показатели? Ну и ряд других вопросов.
Ни на один ответа не получил
Но услышал, что они уже не первый год в отрасли.
О как.
После этого, Yo!!, вы просто ангел и лапочка.
Успехов, я жрать отвалил.
Yo!! - составите техническое задание, сделаем вам систему. Только вопрос с ценой обсудим сперва - задаром пусть торвальдс работает.
6 окт 05, 18:23    [1946167]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
и пока не ушел - у вас, Yo!!, базоцентричный взгляд на мир. То есть для вас база - это все.
Вот даже ваша "постановка задачи" это показывает.
И это типично не только для ораклоидов.
Но есть и другой взгляд, где база это сервис.
И когда решаются бизнес-проблемы в рамках информационной системы, то перед формируется набор задач, которые сервис "база" должен будет выполнять.
Вот в рамках общей архитектуры системы и будут разрабатываться всячиские архитектурные решения.
Короче, почитайте TOGAF (http://www.opengroup.org/architecture/togaf/) что ли, для начала.
6 окт 05, 18:27    [1946193]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
автор
Yo!! - составите техническое задание, сделаем вам систему. Только вопрос с ценой обсудим сперва - задаром пусть торвальдс работает.

как говорится слив защитан. платить за что вы на мои деньги будете изобретать очередной велосипед согласитесь глупо. а этих изобретений я уже насмотрелся, последний изобретатель был ASCRUS, ваш велосипед лучше ? тогда внимательно почитаейте тут
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=109801&pg=5#977105

и мы ждем схематического описание, но пока, извините, я за ваш велосипед и ломаного гроша не дам.
6 окт 05, 18:43    [1946246]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Вспомни ASCRUS, он тут и появится :) А в чем проблема то, уважаемый Yo!! ? В описанном примере по самой постановке задачи в транзакциях идет только добавление и нет узменения и удаления. Можно без TIMESTAMP, можно последний закомиченный INCREMENT получить и так же в условиях выборки спокойно OLAP запрос отфильтровать. Дебет и кредет сойдутся, потому что они по любому будут идти в одной транзакции, не так ли ? Проблем с блокировками в ASA не наблюдается (типа всякий экскалаций, блокирования страниц или ресурсоемкости) - соотвествующе я могу смело включить уровень изоляции SERIALIZABLE - будут четко заблокированы SHARED-блокировками только участвующие в отчете записи, т.е. все закомиченные на момент начала построения отчета. Новые записи будут продолжать успешно добавляться и даже коммититься - никто им мешать не будет, они все равно не попадают под условие OLAP запроса. На а насчет измений и удалений записей - а Вы когда нибудь видели биллинговые или АБС системы, в которых записи изменяются ? Вообще то при правильной архитектуре они всегда добавляются, о чем Вам и пытался рассказать ggv. Соответствующе я полностью согласен с его мнением - единственная трабла блокировочников, про которую так орут Ораклисты - это проблемы с изменяемыми и удаляемыми записями, что на поверку оказывается очень редким явлением в задачах таких крупных масштабов. Так об чем тогда собственно говоря речь идет, если Оракл запросто так своей версионностью сжирает ресурсы и тормозит там, где и тормозить не нужно и даже не имеет честного SERIALIZABLE, а только SNAPSHOT, в отличие от того же Юкона и следом за ним выходящей ASA10, которые будут иметь оба вида уровня изоляции ?
6 окт 05, 19:22    [1946356]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
Мне кажется тут еще раз перечислить минусы того подхода лишнее. помоему их достаточно четко озвучили, подробно расписали и сделали выводы. если у вас есть что то новое по этому "решению" (например Можно без TIMESTAMP, можно последний закомиченный INCREMENT получить) то было бы интересно услышать. я не вижу способа без timestamp или блокировки, последний закомиченый может быть после начала расчета.

автор
соотвествующе я могу смело включить уровень изоляции SERIALIZABLE - будут четко заблокированы SHARED-блокировками только участвующие в отчете записи, т.е. все закомиченные на момент начала построения отчета. Новые записи будут продолжать успешно добавляться и даже коммититься - никто им мешать не будет, они все равно не попадают под условие OLAP запроса.


вспоминаем ту задачку - есть "движения денег по счетам" и баланс (если вы не против мы не будем раз баланс по проводкам считать) баланс обновляется тригером ... и как вы планируете апдейтить баланс когда на нем висят SHARED блокировки до конца построения отчета ?


ЗЫ. шутку про "тормознутый" оракл непонял, но чур не будем на это отвлекатся ;)
6 окт 05, 20:01    [1946433]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ASCRUS
Member

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

После начала расчета чего - входящих данных ?

Yo!!

вспоминаем ту задачку - есть "движения денег по счетам" и баланс (если вы не против мы не будем раз баланс по проводкам считать) баланс обновляется тригером ... и как вы планируете апдейтить баланс когда на нем висят SHARED блокировки до конца построения отчета ?

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

Yo!!
ЗЫ. шутку про "тормознутый" оракл непонял, но чур не будем на это отвлекатся ;)

Да шутка действительно классная. У нас только что человек вернулся с курсов Oracle DBA2. Глаза осоловевшие, литературы привез много, знаний тоже приобрел немало. Первым делом свой биллинг бросился на ASA проверять (он у нас сисадмин). Месяц его не было - работает как часы. Зато вот на курсах он просто обкурился - говорит пока дождешься, чтобы этот Оракл чего то сделал, раза 3 сходишь покурить. Новая БД 1 час создается. На нехилом серваке. А у него биллинг на ASA9 под P3 256 RAM W2003 крутиться и еще там куча других сервисов работают. Вот после его слов я понял, почему ораклисты там много на SQL.RU общаются - ждут, пока пустая БД создасться :) Шутка конечно, но с большой долей истины :)
7 окт 05, 06:33    [1946914]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Калина
Member

Откуда: Moskau
Сообщений: 2649
автор
Да шутка действительно классная. У нас только что человек вернулся с курсов Oracle DBA2. Глаза осоловевшие, литературы привез много, знаний тоже приобрел немало. Первым делом свой биллинг бросился на ASA проверять (он у нас сисадмин). Месяц его не было - работает как часы. Зато вот на курсах он просто обкурился - говорит пока дождешься, чтобы этот Оракл чего то сделал, раза 3 сходишь покурить. Новая БД 1 час создается. На нехилом серваке. А у него биллинг на ASA9 под P3 256 RAM W2003 крутиться и еще там куча других сервисов работают. Вот после его слов я понял, почему ораклисты там много на SQL.RU общаются - ждут, пока пустая БД создасться :) Шутка конечно, но с большой долей истины :)

Кривые руки?
Щас проверил, начиная с уcтановки Oracle и заканчивая созданием базы
Начало 8-33
Зкончено 9-37
Oracle 9.2.0.6-64 RHEL 4 AS-64
7 окт 05, 09:41    [1947163]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
Во бред Yo несет
Ну да ладно, по пунктам, надо же некомпетенцию "выправлять"
Yo, зря вы биллинг взялиЮ оракла тут явно в проигрыше, да и ситуацию я хорошо знаю
Ну для начала бред из "постановки задачи" вашей удивительной.
Совсем не факт, что сведения о клиентах будут хранится в таблице.
Скорее всего, что совсем не в RDBMS будут.
Есть, во всяком случае, много причин не хранить их там.
Это уже показывает вашу некомпетентность.
По прайсам - вот они, скорее всего, будут во множестве связанных таблиц, тоже не хочется вдаваться в подробности, но факт, что вы не компетенты в вопросе.
И с огромной вероятностью прайсы только добавляются, чтобы иметь возможность делать подсчеты по событиям, используя прайсы того периода времени.
Ну и сами звонки. Есть логика обработки данных из пакетов о звонках, и есть mediation система, которая делает некоторые трансформации данных о звонках.
В грубом приближении, следующая цепочка шагов:
просто внести данные как есть - одна таблица, добавление;
внести информацию о звонке после трансформации (это может быть информация, на основе нескольких пакетов о звонке, а не одного, некоего рода "агрегация") - еще одна таблица, добавление;
выяснить кто платит за звонок нам и кому платим за звонок мы - еще одна таблица добавление;
выяснить, сколько должны заплатить нам и сколько должны заплатить мы - еще одна таблица добавление.
Причин у такого разбиения несколько, и они сильно опираются на требования бизнес логики, поэтому я вас, балбеса, и отправлял читать умную вещь.
OLTP транзакции работают с пакетами, поступающими из очередей, кол-во обработчиков очереди известно, длительность одной транзакции известна, кол-во конкурентных транзакций известно, дительность одной транзакции при работе всех конкурентных известно.
Таблицы упорядочены на диске по нескольким измерениям (полям), таким как период времени (величина периода зависит от "мощности" оператора), географический регион (может выражатся - в моем случае так было - гейтом) и вполне возможно по другим полям (уточнять не буду - сильно бизнес зависимо - читайте TOGAF)
Выборка по одним и/или нескольким этим полям будет осуществлятся за одно дисковое чтение и без последующецй сортировки (читайте про уникальную техноглогию MDC таблиц)
Само собой, что опираясь на бизнес требования (опять они) будут использоватся агрегатирующие, или суммирующие таблицы, тоже упорядоченые физически на диске по нескольким полям со всеми вытекающими.
Далее самое интересное - вы так таки и не сказали, какие отчеты надо строить. Но вы некомпетентны, это факт, вы и не могли сказать. Это опять таки сильно зависит от бизнес требований. Ну, навскидку, по памяти, траффик за год, квартал, месяц, неделю, день, кол-во звонков за эти же периоды, и собственно биллинг - создание invoices опять же за период времени.
Ежу понятно (Yo не еж, ему не понятно) что никаких конфликтов с текущими транзакциями по обработке поступающих пакетов нет. Где могут быть конфликты - так это в маленькой области памяти, где собственно и идет вставка текущих звонков во все эти таблицы.
Но здесь вопрос - ЧТО можно получить из этой области памяти? Какая информация нужна бизнесу за малый период назад от текущего времени? Да никакой - стопудово.
И Yo этого признать не может. Гораздо более интересный вопрос, сколько пакетов стоят в очереди на обработку - он покажет, насколько эффективно справляется выделенное кол-во обработчиков с текущим потоком пакетов - но это уже к менеджеру ояередей, а не к базе.
Ну допустим, таки надо получить какю-то информацию за этот коротки промежуток времени назад. При "классическом" блокировочном подходе этот запрос выполнится за абсолютно вычисляемый промежуток времени - очень близкий ко времени выполнения одной наиболее длинной транзакции по внесению информации в условиях известного кол-ва конкурентных транзакций - как только последняя транзакция закомитится, запрос выполнится. Время вычисляемо и на практике очень мало. В учловиях db2 это может быть и не так - поскольку не будет блокировки читателя операциями insert, то запрос не будет ждать коммит последней транзакции вносящей данные в интересуемый промежуток времени current_timestamp - X, а вернет все закомиченные данные на момент запуска.
В результате можно или немного подождать, но получить запрос с данными, бывшими в обработке на момент начала запроса, или не ждать, но получить данные без данных, бывших в обработке на момент начала запроса. Поскольку запрос и так никому не нужен, то решить, что интереснее, я не могу. Насколько я понимаю, в версионнике основной способ работы будет второй.

Есть другие, гораздо более интересные с точки зрения построения транзакций ситуации, но Yo в силу некомпетентности в вопросе не способен их озвучить. Я мог бы начать, но может не сейчас? Не всем интересно.
Про что такое менеджер очередей с XA я упущу, тоже надолго говорить. Ну и все равно фиксация бизнес требований первична, от этого зависит все, и количетсво очередей, и кол-во шагов обработки, и обработка случаев, типа перерасчета в прошлом, и так далее.

Уважаемый дилетант и теоретик Yo - не пошли бы вы, ну хоть почитать, что нибудь, вместо того, чтобы демонстрировать некомпетентность?
Системы на блокировочниках работают и решают бизнес задачи, и зачастую лучше версионников - поэтому их и покупают.
А такие как вы дилетанты только вопят не по делу.
Разрешите на ваш последующий бред не отвечать, если у кого-нибудь заинтересовавшегося будут конкретные вопросы, то можно и поговорить.
7 окт 05, 09:46    [1947181]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ЛП
Guest
Калина
Щас проверил, начиная с уcтановки Oracle и заканчивая созданием базы
Начало 8-33
Зкончено 9-37

Описка? Или действительно больше часа инсталяция + создание базы?
А в какой пропорции? Сколько на инсталл, и сколько на базу?
7 окт 05, 09:48    [1947189]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Калина
Member

Откуда: Moskau
Сообщений: 2649
Еще я пью кофе !
Да никаких пропорций, просто так совпало , что я пришел, запустил копирование дистрибутива - прочел тему - запустил установку засек время . База не пустая, база со всеми обектами.
Этол я к разнговору про час создания. Никаких рекордов ставить несобирался.
7 окт 05, 09:57    [1947228]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
2 Yo!!
С точки зрения работы в банке:
Объясните мне на кой хрен создавать отчет, состоящий из нескольких десятков тысяч (или даже сотен) записей в то время, когда эти самые данные меняются?
Пожалуйста объясните потребительскую стоимость этого отчета!
В реальной жизни (тем кто работает в банке) необходимо знать остаток на конкретном счете в конкретный момент времени. С этой процедурой блокировочники справляются в 3 раза эффективней чем версионники.
А все отчеты (типа баланса) строятся на закомиченных данных и которые уже не меняются. И, скажите, зачем мне тут версионность? неужели я в конце банковского для (когда все проводки сделаны) не смогу получить согласованный баланс на конец дня просто выполнив операцию исходящий остаток=остаток на начало дня +- обороты на уровне изоляции UR?
Или думаете если у меня блокировочник, то он позволит сделать черное сальдо на активном счете а красное на пассивном?
Короче - массовый преход всех на Оракл - отменяется.

2 Yo!!
Действительно реально на блокировочнике получить snapshot не удастся если
на табличке проходят и инсерты и делеты и апдейты. Но оно нам и не нужно.
А если тока инсерты - то ради бога!
7 окт 05, 10:05    [1947264]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
gardenman - поправочка маленькая, я в биллинге имел ситуацию update, и часто, и тоже работало, методика есть, но опять надо конкретно описать, что за бизнес задача, что надо сделать, тогда решается и как будем делать.
Все можно посчитать и спроектировать.
7 окт 05, 10:09    [1947279]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
gardenman

Действительно реально на блокировочнике получить snapshot не удастся если
на табличке проходят и инсерты и делеты и апдейты.

ну наконец-то, интересно как мне эту мысль донести до ggv или там клинический случай.
итак поинт в том, что блокировочник не может, поэтому на нем нужно что-то изобретать дополнительно - или запрещать отчеты на не закрытый период или изобретать х@"ню со timestamp. в банке есть понятие банковский день который и спасает блокировочника, а с х@"ней я над ggv поиздеваюсь позже :)
7 окт 05, 10:42    [1947397]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
2ggv
ууу какой вы сегодня серьозный, не надо так напрягатся, а то читая такие опусы сразу вспоминается анекдот.
анекдот
В городе Отребьевске был установлен новый рекорд в книгу Гиннеса.
Местный житель Краснобаев М. У. непрерывно нес х#йню в течение 28 часов
и 23 мин. Что на 18 минут больше его же прежнего рекорда установленного
в прошлом году. На вопрос корреспондента, когда он обнаружил в себе
такую уникальную способность, Краснобаев ответил, что определенные
предпосылки он ощущал еще с самого раннего детства, но окончательно он
поверил в себя лишь пять лет назад на встрече с избирателями, когда
баллотировался в местную городскую думу.


2 раза перечитав опус мое скудное умишко так и не поняло, чтоб получить баланс $ по клиентам вы предлагаете прочесывать милиардные таблички звонков ? очень интересное решение, особливо для карточек с предоплатой, (когда клиент покупает код в ларьке).
7 окт 05, 11:45    [1947801]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Предлагается апдейтить их раз в сутки, в промежутках между апдейтами прибавлять проводки.
7 окт 05, 12:01    [1947897]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
2ASCRUS
вообще-то тригерами обновлять баланс была ваша идея, я прсто вспомнил тот тред. на счет вырианта баланс + сумма по "движение по счетам" за день - это уже гораздо лучше. наверно и маштабируемость получше, но вот эфективность такого решения в сравнении с версиоником (у которого просто поле баланс) не внушает оптимизма (если клиенты в онлайн будут по вашему сайту бродить). да и геморя с timestamp не отменяет.
7 окт 05, 12:07    [1947939]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
Gluk (Kazan)
Предлагается апдейтить их раз в сутки, в промежутках между апдейтами прибавлять проводки.

т.е. что-то типа предложения ASCRUS, баланс + сумма по звонкам за текущий день. и как такое будет работать ведь для каждого звонка (по предоплате) нужно сначала посчитать текущий баланс, а значит каждый раз елозить табличку со звонками ...
дальше это не поможет получить консистентный отчет на текущий день, иначе надо по всей базе расставлять timestamp + хранить версии изменяющихся записей, а потом как-то их подчищать (что-то типа вакум в постгресе)
7 окт 05, 12:27    [1948035]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
2 Yo!!

А на мой вопрос вы всётаки не ответили. Повторю:

Объясните мне на кой хрен создавать отчет, состоящий из нескольких десятков тысяч (или даже сотен) записей в то время, когда эти самые данные меняются?
Пожалуйста объясните потребительскую стоимость этого отчета!
7 окт 05, 12:33    [1948065]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
Ну если вопросов по существу нет, а скудный умишко Yo (замете, не я это сказал) не позволяет ему понять написанное, то я свалю.
Бредовые фантазии про сканирование таблиц и домысливание того, что я НЕ писал читать не интересно, а понять Yo видимо таки не сможет - ну не приучен человек думать, как упорядочить транзакции, и не слать серваку чего попало.

Ежели вопросы таки будут, то лучше в форум IBM, архитектурного форума пока нет.
Хотя, стоит задуматься - ну пусть ggv нагло лжет, то как же компании строят системы ?
7 окт 05, 12:35    [1948074]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
2gardenman

везде где заказчику предоставляется realtime доступ к системе. у меня клиенты шастают по системе и я не представляю как им можно было бы объяснить, что отчет по сегодняшним транзакциям они смогут получить только завтра.
мне известна только одна сфера где заказчик согласен подождать когда система соизволит закрыть период - бухгалтерия, если вы знаете где еще - удивите меня.
7 окт 05, 12:48    [1948120]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
locky
Member

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

Yo!! wrote:
> 2gardenman
>
> везде где заказчику предоставляется realtime доступ к системе. у меня
> клиенты шастают по системе и я не представляю как им можно было бы
> объяснить, что отчет по сегодняшним транзакциям они смогут получить
> только завтра.
> мне известна только одна сфера где заказчик согласен подождать когда
> система соизволит закрыть период - бухгалтерия, если вы знаете где еще -
> удивите меня.
у меня более-менее реалтайм. заказчики вполне поняли и согласились, что
сводные данные - по состоянию на вчера, зато быстро. по конкретным
счетам (даже относительно небольшому набору счетов) - можно на сейчас....

--
-------------------------
There's no silver bullet!

Posted via ActualForum NNTP Server 1.3

7 окт 05, 12:53    [1948136]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
ggv
Member

Откуда:
Сообщений: 1810
о, пока я не свалил а gardenman здесь - вопрос, я понятно объяснил, или уже потерял способность излагать мысли? отвечать лучше в форум IBM или по почте - я сюда вряд ли недельку загляну.
7 окт 05, 13:10    [1948202]     Ответить | Цитировать Сообщить модератору
 Re: Помогите сделать выбор: solaris 10 x86+oracle10g vs solaris 10 ultraparc+oracle10g  [new]
DimaR
Member

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

А на мой вопрос вы всётаки не ответили. Повторю:

Объясните мне на кой хрен создавать отчет, состоящий из нескольких десятков тысяч (или даже сотен) записей в то время, когда эти самые данные меняются?
Пожалуйста объясните потребительскую стоимость этого отчета!




Ну хотя бы простой пример (очень примитивно)
записи момент времени 1 (commit)
100
200
300

перенос суммы момент времени 2 (возможно куча каких то апдейтов, селектов, инсертов, удалений)

записи момент времени 3 (commit)
100
100
400

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

Может я где то ошибаюсь
7 окт 05, 13:24    [1948260]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
ggv
о, пока я не свалил а gardenman здесь - вопрос, я понятно объяснил, или уже потерял способность излагать мысли?

нет-нет ваша способность нести х#йню часами на высоте, не сомневайтесь :)

2All
давайте сначало определимся с технической частью, чтоб не возвращатся - "Действительно реально на блокировочнике получить snapshot не удастся если на табличке проходят и инсерты и делеты и апдейты." и никаким "правильными" проэктированиями балансы в отчете на текщий момент (без серьзного коимпромиса с перфоменсом) не получить.
и после этого можно обсудить в каких сферах такие отчеты необходимы, ОК ?
7 окт 05, 13:34    [1948308]     Ответить | Цитировать Сообщить модератору
 Re: Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i  [new]
Yo!!
Guest
2DimaR
чтоб получить сумму 600 вы дожны наложить shared блокировку чтоб пока вы складываете данные не изменялись (чтоб отчет консистентный получился). shared блокировка остановит всю тучу инсертов и обновлений на время всей читающей транзакции (IL serializable)
7 окт 05, 13:39    [1948337]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 9 10 [11] 12 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить