man_555Почему не стоит строить хранилище данных на базе MS SQL Server 200x? Очень много слышал и слышал как гнутся пальчики в сторону Sybase и Oracle, но почему никто вразумительно объяснить не мог.

Присоединяйтесь, если интересна дискуссия.
дык, в mssql2k нету элементарных вещей типа нормального партионинга, materialized view т.п. без которых DWH строить затруднительно, а mssql2k5 только появился.

RENaissance
To Yo.!!
Откуда Вы взяли, что в MSSQL2000 нет секционированных и материализованных представлений??? Рекомендую Вам более внимательно почитать
BOL.


не первый год замужем :)

partitioningсекционирование позволяет большие структуры базы данных (таблицы, индексы) разбить на меньшие кусочки. Оракл предлагает несколько методов для различных сценариев:
- Range partioning
- Hash partitioning
- List partitioning
- range-hash and range-list composite partitioning

также существует 3 типа partitioned indexes:
- local index, т.е. индекс на партицию.
- global partitioned index, такой индкс разбивается на секции по другим правилам нежели сама таблица.
- global non-partitioned index, такой индекс не разбивается на секции хотя таблица разбита.
- всевозможные комбинации partitioned и non-partitioned с таблицами. partitioned таблица может иметь partitioned и non-partitioned index также как и non-partitioned с таблица может иметь partitioned и non-partitioned index.

MSSQL2K не поддерживает секционирование в том смысле как его понимает индустрия. вместо таблиц он использует partitioned views. partitioned views соединяет секции горизонтально из таблиц на разных серверах. Диапозоны для каждой секции прописываются в CHECK констреинте, а view использует UNION ALL чтоб склеить секции в единый результрующий набор.

В MSSQL2K два типа partitioned views - local partitioned view и distributed partitioned view. локальный - все таблицы-партиции находятся на одном инстансе, дистрибутед - как минимум одна таблица вынесена на другой инстанс.

Когда оракл импользует глобальный индекс в OLPT задаче, он обращается к одному индексу чтоб выяснть на которой партиции находится запись, не важно какой метод применялся для секционирования. У MSSQL2K если в запросе не прописано которую партицию использовать серверу приходится просматривать все партиции. Это делает затруднительным использывание партиций в real-world OLTP задачах, ведь когда используются дистрибутед партиции - серверу необходимо прочесать все инстансы.

2man_555
матвью это чуток другое, у сиквела есть indexed view, так сказать слабое подобие левой руки:
http://triffids.googlepages.com/MSSQL2005_ORACLE10g_compare.pdf
In MSSQL 2000 the materialized views have been limited in the means of data types and functions available.
MSSQL 2005 still has a significant list of restricted functions and aggregations. The Indexed View in MSSQL still has a lot of limitations as compared with the Oracle one. For example, the Indexed View definition could not contain the following very useful aggregations, functions and options, namely derived table (sub query in FROM list), reference to another view, DISTINCT, EXISTS, NOT EXISTS, self-join, expressions on aggregate results (e.g. SUM(x)+SUM(x)), STDEV, STDEVP, VAR, VARP, AVG, Subquery, SUM on nullable expressions and UNION.

2AAron

а можно поинтересоватся, что общего вы нашли у DWH и TPC-H ? ;)

man_555
Да, видимо я плохо учил уроки в школе... для увеличения производительности? Насколько мне помнится есть два подхода: кэшировать и индексировать.

Но как бы то ни было, что тогда под собой подразумевает представление? Таблицу фактов или измерение (dimension)?
подозрительная у вас была школа
Kyte
Материализованные представления — средство повышения производительности для
хранилищ данных и систем поддержки принятия решений, которое многократно уско-
ряет выполнение запросов, обращающихся к большому количеству (сотням тысяч или
миллионам) записей. Говоря упрощенно, они позволяют за секунды (и даже доли се-
кунд) выполнять запросы к терабайтам данных. Это достигается за счет прозрачного ис-
пользования заранее вычисленных итоговых данных и результатов соединений таблиц.
Предварительно вычисленные итоговые данные обычно имеют очень небольшой объем
по сравнению с исходными данными.
Предположим, в компании имеется база данных продаж, в которую загружены све-
дения о миллионах заказов, и необходимо проанализировать продажи по регионам (весь-
ма типичный запрос). Будут просмотрены все записи, данные — агрегированы по реги-
онам с выполнением необходимых вычислений. С помощью материализованного
представления можно сохранить итоговые данные продаж по регионам и обеспечить
автоматическую поддержку этих данных системой. При наличии десяти регионов про-
даж итоговые данные будут состоять из десяти записей, так что мы будем обращаться
не к миллиону фактических записей, а только к десяти. Более того, при выполнении
несколько измененного запроса, например об объеме продаж по определенному регио-
ну, ответ на него тоже можно получить по этому материализованному представлению.

man_555
а Вы пальцы гнёте или просто повторяете то, что уже другие сказали? ПОВЫШЕНИЕ ПРОИЗВОДИТЕЛЬНОСТИ. Индексация в ХД не хуже с этим справляется.

да ? а подумать головой ? ну совсем чуток !
сильно тебе индекс поможет на запросе типа "итоговые данные продаж по регионам " по табличке в пару милиардов записей ?

ЗЫ. а у mssql и с индексами беда.

2SeaGate

Type of index Oracle Database 10g/SQL Server 2005
B-tree indexes Yes / Yes
B-tree cluster indexes Yes / No
Hash cluster indexes Yes / No
Reverse key indexes Yes / No
Bitmap indexes Yes / No
Bitmap join indexes Yes / No
Function-based indexes Yes / No
Domain indexes Yes / No
Index-organized tables Yes / Yes (clustered indexes)

man_555Если такое требуется пользователям, то не проще ли будет создать новую таблицу и не нагружать ХД на поддержку всех MV? По крайней мере для того, чтобы ручками вносить изменения в ХД нужны веские основания.

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

man_555Сомнительно, что для миллиарда записей не используется нечто вроде фабрики данных.

wtf ? витрина что-ли ?

man_555
Ну почему "жевачка"? Только обоснованно.
от того, что вы сделаете такую табличку оптимизатор не станет ее использовать для оптимизации планов.
вгот книжечка
http://anatolix.naumen.ru/Books/KyteOracle?v=kvq
там есть раздел по матвью.

Nikolay KulikovYo!! Красиво поешь. Только DW workload достаточно предсказуемый и хорошо вписывается в MPP архитектуру разделяй и властвуй, которую Oracle не любит.

шутить изволите ?
This white paper describes how Oracle's parallel technology fully exploits the
power of IBM's HACMP/6000 clusters and RS/6000 MPP technology. December 1996

Nikolay KulikovА большое количество разнородных индексов усложняют жизнь оптимизатору, не будешь же ты в DW каждый запрос тюнить.
индексы осложняющие жизнь оптимизатору ? :) такой фичи в оракле еще не слышал.