YuraIII,

Oracle vs MSSQL: http://triffids.googlepages.com/oraclevsyukon

kdv В т.ч. на "Performance and Scalability".

гы, в связи с выходом 2008 похоже обновили раздел. ну что же, виден хороший прогресс: убрали откровенное вранье, остался стандартный маркетинговый булшит. до этого обновления они утверждали, что мсскл быстрей в tpc-c сравнивая системы на итаниумах из разных поколений. надеюсь get the fuck в прошлом.

pkarklin
И чем Вас так, собственно BI не устраивает?! ;) В MS SQL эти "инструменты" включены в коробку за стоимость лицензий
по большому счету в мс нет аналога БИ продукта от оракл, есть набор инструментов из которых можно собрать что-то. сравнивать набор с продуктом не корректно. а цена, да, у оракла серьезные вещи на БИ вообще космические цены.

к стате о булшите, смотрю первое же утверждение
microsoftSQL Server is in the leader’s quadrant in Gartner’s Magic Quadrant for BI
http://www.microstrategy.com/Company/GartnerQuadrant.asp

картинка

pkarklin
Дык вот и говорил я уже не раз по поводу этой статьи, что не все тут так гладко. Например, в MS SQL FBI может быть заменен индексом по вычисляемому полю.

хм ... а в этом есть смысл ?
MSDN Creating Indexes on Persisted Computed Columns

You can create an index on a computed column that is defined with a deterministic, but imprecise, expression if the column is marked PERSISTED in the CREATE TABLE or ALTER TABLE statement. This means that the Database Engine stores the computed values in the table, and updates them when any other columns on which the computed column depends are updated. The Database Engine uses these persisted values when it creates an index on the column, and when the index is referenced in a query.
чем оно лучше обычного поля заполняемого тригером + обычный индекс ?

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


согласен, особливо когда не вьезжаешь о чем собственно речь - конечно одинаковы.

locky
А чем обычное поле+триггер+индекс хуже FBI?

тем что требует в 2 раза больше места.

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

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

pkarklin
Ну, фу... То мы на tpc меряемся в рамках Enterprise редакций, то на XE экономим.

да не проблема, давай энтепрйз - для DWH 2Тб хранилище обойдется сильно дороже 1.5Тб, может и в разы из-за бэкапов.

pkarklinВо... Поэтому сейчас говорить о стоимости лицензии уровня ЕЕ, при наличии многоядерников по сравнению со стоимость какой-нить EVA 8100 на озвученную пару ТБ смешно. ;)
не смешно, а нет смысла, в ынтрепрайзе ценник мало связан с прайслистом, скидка более 50% скорее правило.

locky
а зачем вам индекс по UPPER()?

чтоб по mcdonalds находить McDonalds ...

locky
а case insensitive collation поставить не судьба?
на всю базу !?

locky
можно - только на нужное поле
гы, а вот так в оракле нельзя.

pkarklin
Ну, эт если тока у Oracle, скидка 50%, после накрутки еще 100% ибо, как оказывается, необходимые фичи за совершенно отдельные денюжки.
и отдельные скидки ... открой tpc.org - я не вижу принципиальной разницы в прайсах за софт в больших конфигураций, в пределах 50% разброс, что составляет несущественные доли от стоимости дисковых подсистем.

interestingHint - index range scan.

Что бы дать понять, что я в теме.
неа
мимо темы:
Reverse Key IndexesMany database tables have primary or unique keys based on a sequence. These keys are usually indexed by b-tree indexes which, by nature, store the indexed values in order. This behavior of sequential storage gives this type of index the name of “monotonic” or “right-growing” index. These types of indexes can become performance bottlenecks on high-volume transactional systems because of serialization that occurs when inserting values into the leaf-blocks of these indexes.

To avoid this serialization, reverse-key indexes can be used. A reverse-key index stores indexed values in reverse-bit order. So, where the values (234, 235, 236) are stored sequentially and contiguously in a normal b-tree index, they are stored out of sequence and non-adjacent (236, 234, 235) for the reverse-key index (see Table 2-3). Over a larger set, this reversing of the key distributes the indexed values across the leaf-node blocks of the index, thereby eliminating the serialization on sequential inserts.