Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#259<< #260 |
СОДЕРЖАНИЕ
Деревья в поддерживающих стандарты SQL базах данных
По материалам статьи Eugene Lepekhin:
Trees in SQL databases Статья рассказывает о том, как улучшить производительность деревьев в SQL. Введение
Рано или поздно в своём проекте баз данных Вы столкнетесь с необходимостью хранения
иерархической информации. Например: структура предприятия, категории товаров, каталог
изделий или папок с документами; всё это хорошие примеры иерархических структур.
Конечно же, можно реализовать их хранение в виде самосвязанной таблицы. Проблемы начнутся,
когда нужно будет создавать запросы к иерархическим данным. Например: "Что, если мы
имеем дело со структурой предприятия, и хотим узнать, сколько служащих подчиняются
менеджеру X?". Такие решения подобных проблем уже были описаны. Например, можно посмотреть
книгу и статьи Joe Celko, в которых есть подробные описания таких решений. Идея Предположим, что мы имеем следующую таблицу:
Где: NodeId - первичный ключ, ParentId - внешний ключ и NodeName - некоторое дополнительное
поле. Чтобы упростить последующие примеры, давайте предположим, что NodeName имеет
ограничение уникальности.
Создадим ещё одну таблицу, имеющую две связи с таблицей Node:
В этой таблице NodeId и ParentId - внешние ключи, ссылающиеся на таблицу Node. Запрос 1:
Получился простой и понятный запрос, не правда ли? Запрос 2:
Этот запрос не менее простой, как и предыдущий. Обратите внимание, что эти два запроса выдают результат в обратном порядке записей таблицы Tree. Реализация Перед тем, как двигаться дальше, автор хотел бы сделать два примечания.
№ 2: Самыми распространёнными задачами, являются задачи, использующие поддеревья узла или путь к узлу от корня, включая сам этот узел. Так что было бы полезно иметь в таблице Tree непосредственно и сам узел в качестве собственного предка с уровнем 0.
Можно реализовать описанный инвариант в виде хранимой процедуры или в виде триггеров.
Автор предпочитает делать это в одном триггере.
После этого можно добавить список всех предков вставленного узла. Имея ввиду, что родитель каждого вставляемого узла уже имеет список всех своих предков, поэтому мы можем использовать их за основу. Но мы должны заменить NodeId родителя на id нового узла и увеличить уровень.
Таким образом, код триггера будет иметь следующий вид:
Теперь пришло время продумать триггер на UPDATE, который позаботится о родителе изменяемого
узла. Цель триггера на UPDATE состоит в том, чтобы удалить все устаревшие записи в
таблице Tree и заменить их новыми. Чтобы минимизировать изменения, совершаемые этим
триггером, давайте повторно использовать ту информацию, которая уже имеется в таблице
Tree, аналогично тому способу, который мы использовали в триггере на вставку записи.
Но разве нельзя просто изменить родителя узла?
Туда мы вставляем первичные ключи всех потомков и уровни каждого из них относительно изменяемых узлов. Условие, что t.Level > 0, позволяет исключать изменяемый узел из вставки в таблицу @child.
Второй шаг удаляет все устаревшие строки у всех потомков:
Условие, что t.Level > 0, исключает удаление изменяемых узлов.
Следующие два шага заполняют таблицу Tree новой информацией. Соответственно, это будет так:
Всё это делается так же, как мы это делали в триггере на вставку.
Может показаться странным, что тут не используются какие-либо соединения с таблицей
child. Но эта инструкция - именно то, что нам здесь нужно, потому что мы собираемся
повторить информацию о предке для каждого детишки. Также обратите внимание на то, как
мы добавляем уровень детишек, хранящийся в таблице @child, который скорее всего только 1.
Как Вы можете видеть, это будет работать только если изменялся ParentId, и все другие изменения таблицы Node будут отфильтрованы самым первым оператором в условии. Ограничения использования Если Вы собираетесь одновременно вставлять или изменять более одного узла, убедитесь, что Вы не делаете это более чем для одного уровня дерева. С практической точки зрения это - не сильное ограничение. Дополнительные шаги Для завершения функциональности, нужно иметь возможность полностью очищать таблицу Tree и заполнять её заново. Хорошая идея, написать для этого хранимую процедуру, но автор не собирается портить Вам удовольствие создать её самостоятельно. Примеры Вы можете загрузить по указанной ниже ссылке необходимый SQL-код, который поможет создать обе таблицы и триггеры, а также команды для заполнения тестовыми данными таблицы Node. В загружаемом файле также содержатся запросы 1 и 2 и скрипт для изменения родителя узла.
Почему нежелательно использовать компрессию файлов баз данных и журналов SQL Server
По материалам статьи Ken Henderson:
Why you shouldn't compress SQL Server data and log files
Наиболее опытные SQL Server DBA знают, что не стоит использовать автоматическое
сжатие файлов данных и журналов, но я могу поспорить, что лишь немногие из них знают,
почему это является таким уж плохим решением. Основным ответом на этот вопрос может
быть "снижение производительности", и это правильно, но предположение о том, что
производительность снижается из-за сжатия \ декомпрессии данных, это только отчасти
правильное утверждение. Есть еще более важная причина. Руководство по работе с Microsoft SQL Server 2000 Analysis Services (продолжение)
По материалам статьи Carl Rabeler и Dave Wickert, Microsoft Corporation:
Microsoft SQL Server 2000 Analysis Services Operations Guide Содержание
Введение Ограничение Very Large Dimension Memory (VLDM) Very Large Dimension Memory (VLDM) Threshold32-битная версия Analysis Services (64-битная не использует VLDM) пытается предотвратить использование большими измерениями всего доступного адресного пространства виртуальной памяти с помощью загрузки каждого очень большого измерения в пространство своего собственного процесса со своим адресным пространством виртуальной памяти. Очень большое измерение - это такое измерение, которое превышает значение параметра VLDMThreshold в реестре. Значение порога VLDM по умолчанию равно 64 мегабайтам. Хотя использование отдельного адресного пространства для каждого измерения, которое превышает порог VLDM, действительно сохраняет адресное пространство виртуальной памяти в главном процессе, общая производительность все равно снижается, когда одно или больше измерений превышают порог VLDM. Загрузка всех измерений в пространство главного процесса (когда это возможно) дает лучшую производительность, но Вы должны убедиться, что в наличии имеется достаточный объем адресного пространства виртуальной памяти для выполнения следующего: - Загрузка всех измерений в память при запуске. - Загрузка всех измерений, которые обрабатываются в нескольких параллельных или в одной транзакции, в память во время обработки (они называются скрытыми измерениями). Analysis Services использует существующую версию каждого измерения для выполнения пользовательских запросов, пока транзакция не будет завершена. Чтобы уменьшить объем памяти, требующийся для скрытых измерений, необходимо обрабатывать измерения отдельными транзакциями. Если Вы выберите Process the Database или Process All Dimensions in Analysis Manager, то измерения будут обрабатываться в одной транзакции и потребуют большой объем памяти для загрузки каждого измерения в память дважды (первый раз при загрузке, и потом еще раз во время обработки). - Хранение копий измерений при необходимости. Смотрите "Копии измерений" далее в этой статье. - Выполнение всей обработки без использования временных файлов. Смотрите "Буфер обработки" далее в этой статье. И не следует использовать VLDM только для того, чтобы получить буфер обработки большего размера. Обработка - это разовая, в худшем случае, периодическая операция. Использование же VLDM - это постоянная нагрузка, приводящая к пониженной производительности и повышенной сложности (больше процессов, больше переключений контекста, и т.д.). - Создание и использование достаточно большого кэша результатов запроса. Смотрите "Кэш результатов запроса" далее в этой статье. Если для Analysis Services не хватает адресного пространства виртуальной памяти в общем адресном пространстве, то установите порог VLDM так, чтобы в отдельные адресные пространства загружались только самые большие измерения. Для дополнительной информации о том, как Analysis Services использует доступную память, и о том, как рассчитать ее необходимый объем, смотрите "Управление свободным пространством и производительностью" далее в этой статье. Если Analysis Services имеет достаточный объем адресного пространства виртуальной памяти в пространстве главного процесса, то отключите VLDM, изменив имя файла msmdvldm.exe в папке Bin на любое другое (например, msmdvldm-disabled.exe). Когда запустится служба стартует и не найдет исполнимый файл VLDM, то она отключит VLDM. VLDM автоматически отключается на 64-битных системах. Отключение VLDM гарантирует, что все измерения загружаются в пространство главного процесса. Учитывая снижение производительности и ограничения при использовании VLDM наилучшей практикой считается, что если Ваше приложение достаточно велико для использования VLDM, то Вам следует оценить, не лучше ли в этом случае использовать SQL Server 2000 64-битной версии для увеличения производительности. Это важно: в общем случае, Вам следует рассмотреть возможность использования 64-битной версии Analysis Services, если: - Ваше BI приложение включает большие измерения или большое количество свойств. - В одном экземпляре Analysis Services находится большое количество баз данных и кубов. - Вам нужно выполнять большое количество запросов во время одновременной обработки разделов. - Вы не можете увеличить размер буфера обработки, чтобы исключить использование временных файлов на диске во время обработки. Для дополнительной информации зайдите на сайт Technet Web (http://www.microsoft.com/technet) и посмотрите статью "Microsoft SQL Server 2000 (64-bit) Analysis Services: Why Migrate, and What to Expect If You Do". На заметку: Когда порог VLDM используется для больших измерений, Analysis Services создает скрытые измерения для этих больших измерений во время обработки в главном адресном пространстве. Таким образом, даже если Вы используете VLDM, большие измерения все-таки создают ощутимое влияние на виртуальное адресное пространство главного процесса. ПРОДОЛЖЕНИЕ СЛЕДУЕТ Статьи на русском языке
Surrogate key generation in SSIS Самые популярные темы недели
Кто на чем пишет клиентов под SQL Server?
SQL2005: использование НЕ NETBIOS имен серверов при репликации |
Вопросы, предложения, коментарии, замечания, критику и т.п. оставляйте Виталию Степаненко и Александру Гладченко в форуме: Обсуждение рассылки
|
Subscribe.Ru
Поддержка подписчиков Другие рассылки этой тематики Другие рассылки этого автора |
Подписан адрес:
Код этой рассылки: comp.soft.winsoft.sqlhelpyouself |
Отписаться
Вспомнить пароль |
В избранное | ||