Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru) 188
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)" Выпуск 188 (3 мая 2008 г.)Новым посетителям сайта Сайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения
состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.
Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается сейчас после решения 57-ти задач первого этапа. При подсчете рейтинга каждого участника отбрасывается один самый худший показатель среди всех решенных им упражнений. Демонстрация плана выполнения запроса и сравнительная оценка эффективности решений поможет вам освоить принципы оптимизации запросов, которые пригодятся на третьем рейтинговом этапе, который начинается после 138 задачи.Имеется возможность получить сертификат по SQL DML при выполнении определенного количества заданий. Новости сайта§ Два дня перед праздниками сайт работал со сбоями. Это было связано с DDOS атаками на сервер. Поскольку одного непрерывного интервала простоя не было, я не выполняю общей компенсации времени. Просьба обращаться, если кто-то потерял в рейтинге из-за сбоев; будем решать вопрос в индивидуальном порядке. § Инфляция заставляет нас поднять цену сертификата. Вероятно, после грядущих праздников, т.е. к следующей рассылке, стоимость сертификата станет 960 рублей (в евро цена останется прежней). § Изменения среди лидеров (решенные за неделю задачи третьего этапа): § Новые лица в ТОР 100 и вернувшиеся туда: § Продвинулись в рейтинге: § Продвижение ближайших претендентов на попадание в ТОР 100: § На этой неделе сертифицированы: § Число подписчиков - 3781 Число участников рейтинга - 16095 Число участников второго этапа - 1344 Число участников третьего этапа - 31 Сертифицировано на сайте - 270 Лучшие результаты (ТОР 20)
Лучшие результаты за неделю
Изучаем SQLПонимание разницы между владельцами и схемами в SQL SeverKathi Kellenberger (оригинал: Understanding the Difference between Owners and Schemas in SQL Server )Перевод Моисеенко С.И. Сервер SQL 2005 вводит понятие схем в противоположность владельцам объектов, имевшихся в предыдущих версиях. Эта статья объяснит различия между этими двумя понятиями, и, мы надеемся, несколько прояснит непонимание, которое все еще существует в представлениях о схеме. Владельцы объектовЧтобы понять различие между владельцами и схемой, давайте посвятим некоторое время рассмотрению понятия собственности объекта. Когда объект создается в SQL Server 2000 или более ранних версиях, он должен иметь владельца. Чаще всего владельцем является "dbo", также известный как владелец базы данных. Допустимо, что объект может принадлежать любой учетной записи пользователя в базе данных. Способ определить владельца можно узнать, если посмотреть на полностью квалифицированное название объекта, которое Вы можете видеть в списке таблиц, используя SQL Server Enterprise Manager или Management Studio. Например, название таблицы с именем orders, принадлежащей dbo, есть dbo.orders. Если владение таблицей будет передано пользователю abc, то таблицу будут теперь называть abc.orders. Как объект получает его владельца? Это зависит от пользователя, который создал данный объект. Такая возможность имеется также у участника роли db_owner, который может создать объект, принадлежащий любому пользователю в базе данных. По умолчанию пользовательская учетная запись, которая создает объект (эта учетная запись должна иметь разрешение CREATE TABLE), будет также владеть объектом. Только учетные записи пользователя, принадлежащие роли db_owner могут создать объекты, принадлежащие dbo. Затем, при определенных обстоятельствах, владелец может даже перестать быть фактической учетной записью пользователя, но не dbo. Смотрите Understanding Object Ownership, где подробно обсуждается эта проблема. Использование dbo в качестве владельца всех объектов базы данных может упростить управление объектами. Вы будете всегда иметь пользователя dbo в базе данных. Пользователи в базе данных будут в состоянии получить доступ к любому объекту, принадлежащему dbo, не уточняя владельца до тех пор, пока пользователь имеет соответствующие разрешения. Если объект принадлежит учетной записи, которая не является dbo, собственность необходимо передать другому пользователю, если исходная учетная запись должна быть удалена. Например, если не-dbo пользователь базы данных с именем "ted" создает таблицу sales, она будет называться ted.sales. Для других пользователей, за исключением Тэда, чтобы увидеть таблицу, следует использовать полностью квалифицированное имя. Если Тэд уходит из компании или отдела, и его учетная запись должна быть удалена из базы данных, владение этой таблицей должно быть передано учетной записи другого пользователя с помощью хранимой процедуры sp_changeobjectowner прежде, чем учетная запись Тэда может быть удалена. Если таблица использовалась в приложениях или ссылки на нее имелись в каких-нибудь определениях, например, хранимых процедур, то изменение владельца нарушает весь код. Если бы dbo был владельцем таблицы изначально, то не было бы никакой проблемы при удалении учетной записи Тэда. Код тогда мог бы не использовать полностью квалифицированное имя, хотя и есть небольшой прирост производительности при использовании квалифицированных имен, что общепринято считается лучшим методом. СхемыМне нравится думать о схемах как о контейнерах для размещения объектов. Если Вы посмотрите на учебную базу данных AdventureWorks (иллюстрация 1), то увидите, что таблицы распределены по разделам или функциям, например, "HumanResources" или "Production". Это напоминает прежнюю концепцию владельца, но имеет много преимуществ по сравнению с ней. Прежде всего, так как объекты не привязаны ни к каким учетным записям пользователя, Вы не должны беспокоиться об изменении владельца объектов при удалении учетных записей. Другое преимущество состоит в том, что схемы могут использоваться для упрощения управления разрешениями на таблицы и другие объекты. Схема имеет владельца, но владелец не привязан к названию. Поэтому, если учетная запись владеет схемой, и эта учетная запись должна быть удалена из базы данных, владелец схемы может быть изменен без изменения кода. Если Вы не желаете организовать объекты вашей базы данных в схемы, под руками всегда есть схема dbo. 
Иллюстрация 1: Таблицы AdventureWorks со схемами. Пусть, например, служащие в рамках отдела Widgets - члены одной сетевой группы безопасности WidgetEmp. Менеджеры каждого отдела - члены дополнительной группы, WidgetManagers. Мы создаем схему с именем Widgets, и много таблиц, представлений и хранимых процедур содержатся в схеме Widgets. Чтобы управлять доступом к объектам, мы могли бы добавить сетевые группы WidgetEmp и WidgetManagers в SQL Server и базу данных. Поскольку нас интересует управление доступом к таблицам, группе WidgetEmp дано разрешение execute (выполнение) на все хранимые процедуры в схеме Widgets. Группе WidgetManagers также дано разрешение select на все таблицы и представления. Главное здесь состоит в том, что Вам больше не нужно помнить о предоставлении разрешения всякий раз, когда создается новая хранимая процедура, таблица или представление, пока все это делается в схеме Widgets. Чтобы предоставить разрешения на все хранимые процедуры в пределах схемы, выполните следующие действия: Я всегда хотел иметь роль базы данных с разрешениями на выполнение всех хранимых процедур. Что-то подобное роли db_datareader. Теперь Вы можете предоставить разрешение на выполнение всех хранимых процедур в пределах схемы, чтобы достичь желаемого результата (см. иллюстрацию 2). Я не знаю, почему не существует такой роли, но, по крайней мере, теперь есть простой способ сделать это. Даже если Вы не получаете выгоды из схем в вашей базе данных, Вы можете дать разрешение на выполнение хранимых процедур в схеме dbo, чтобы достичь того же самого результата. 
Иллюстрация 2: Предоставление разрешений на выполнение всех хранимых процедур в схеме. Одну важную вещь следует иметь в виду, если вы хотите использовать схемы в своих интересах. А именно, организацию схемы нужно разрабатывать в начале проектирования базы данных. Позднее изменение проекта схемы может вызвать многочисленные изменения кода. Модернизация вашей базы данныхЧто случится, если вы переносите базу данных с SQL Server 2000 на 2005? При обновлении базы данных с 2000 на 2005, для каждого пользователя в базе данных создается схема. Вы можете даже не заметить этого, пока Вы не попытаетесь удалить одну из пользовательских учетных записей. Здесь Вы получите сообщение об ошибке: "The database principal owns a schema in the database, and cannot be removed" (руководитель базы данных владеет схемой в базе данных и не может быть удален). Чтобы разрешить эту проблему, сначала нужно лишь удалить схему, пока она пустая. Если схема не пуста, Вы должны будете решить, удалять ли сначала объекты или передать схему другому владельцу. ЗаключениеХотя поначалу понятие схем кажется запутанным, оно имеет много преимуществ, если вы разберетесь с этим. Думайте о схеме только как о контейнере объектов, чтобы организовать их и упростить предоставление разрешений по сравнению с более ранним понятием владельца. Наиболее важно заняться организацией схемы в самом начале процесса проектирования, чтобы впоследствии избежать проблем с изменением кода. Наконец, предоставляя в схеме разрешение на выполнение учетной записи или роли базы данных, мы теперь имеем гарантию, что пользователи смогут всегда выполнять новые хранимые процедуры. 05-10-2007 Полезная информация§ Все статьи, публикуемые в рассылке, затем выкладываются на сайте Книги и статьи по SQL. § Желающих поспособствовать популяризации сайта прошу проголосовать/поставить закладку в социальных сетях: КонтактыПо всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77[@]yandex.ru. Вы также можете предложить свои задачи для публикации на сайте. |
| В избранное | ||
