Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru) 98
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)" Выпуск 98 (29 июля 2006 г.)
Новым посетителям сайта
Сайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.
Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается сейчас после решения 58-ти задач первого этапа. При подсчете рейтинга каждого
участника отбрасывается один самый худший показатель среди всех решенных им упражнений.
Демонстрация плана выполнения запроса и сравнительная оценка эффективности решений поможет вам освоить принципы оптимизации запросов.
Имеется возможность получить сертификат по SQL DML при выполнении определенного количества заданий.
Новости сайта
§ Выставлена еще одна новая задача - 92-я. Сложность 2 балла, автор - paparome. Будут еще на всех этапах :-). Еще не все лидеры решили 2 добавленные за последнее время задачи, что внесло изменение в TOP 10. Помимо некоторых перестановок, появилось новое лицо (на мой взгляд, вполне заслуженно) - vlksm (задач 137,время 22.534). Вернулся в десятку и наш модератор Fiolent (137, 49.244).
§ Новый человек появился и в сотне - alex_v (110, 9.261). Сотня уплотняется, и я уже подумываю о том, чтобы анализировать шансы претендентов.
§ Сохранили шансы попасть в ТОР 10: Dizil (136, 3.829) =Maxim= (121, 12.031)
§ Продолжили свое восхождение к вершине: ba (122, 41.175) FanOfBeer (121, 78.537) T! (115, 45.140) Ocean (109, 28.059)
§ На этой неделе сертифицированы: зфмуд1973 (A06006755) [BK] (г.Аксу, Казахстан) FanOfBeer (B06008465) [AR] (ст.Выселки, Краснодарский край, Россия ) Vaganov (A06011298) [BK] (г.Новороссийск, Россия) pаparome (B06006028) [AR] (г.Москва, Россия )
Рассуждение, которое приводит к таблицам MUCK, если взять его логическое заключение, должно сводить или "обобщать" каждую сущность в базе данных к "Вещи" (Thing). Таблица Thing имела бы ключ (им, естественно, будет столбец IDENTITY), и несколько других обобщенных атрибутов типа Name (название), Type (тип) и description (описание) и т.д ...:
CREATE TABLE Thing ( PKey bigint IDENTITY(1,1) --Лучше использовать bigint, поскольку ожидается --множество строк в этой детке... , ThingType int , Attribute1 varchar(8000) -- Мы не можем обеспечить никакой целостности домена, поэтому --
должны смириться с тем, что я называю подходом "кучи мусора". , Attribute1Type int , Attribute2 varchar(8000) , Attribute2Type int , и т.д....)
Поздравляю вас, теперь мы разработали прямой путь обратно к управлению данными в электронной таблице, хотя и с одним удобством в виде языка запросов. О, постойте..., было бы еще лучше использовать столбец IDENTITY и строку XML, это способ, при которым нам не понадобится определять в БД более одной таблицы с двумя столбцами, и мы вообще не будем беспокоиться о такой вещи как целостность данных; "не лучше ли вести всю обработку средствами приложения?" Теперь это то, что я называю гибким проектом
базы данных! (OK, прошу прощения за сарказм, это для тех, кто не подумал: "Да! Можно сэкономить время и прекратить читать".) Да, я лично имел дело с людьми, которые думали, что такие варианты не только жизнеспособны, но и предпочтительней нормализованной базы данных.
Кое-кто скажет, что эти примеры неправдоподобны, и что никакой разумный человек не пошел бы так далеко. Но где точно находится граница, когда Вы знаете, что зашли слишком далеко? Когда Вы отказываетесь от фундаментальных принципов, на которых основан хороший проект базы данных, какие принципы Вы используете для приложения ваши сил? Различие между MUCK и таблицей "Thing" одного порядка, не по виду, а по тому, что обе они неправильны. Теперь, прежде чем Вы скажите, что "нет никакого 'правильного'
способа спроектировать базу данных"; правдой является то, что заданный ряд довольно сложных требований, два компетентных человека могли бы реализовать, на первый взгляд, в различных проектах базы данных, но будьте уверены, что разнообразие неправильных проектов, в которых неосведомленность видна повсюду, фактически безгранично!
Обобщение - хорошая вещь в правильном контексте, но это - инструмент, и он не должен использоваться без разбора. Обобщение может оказаться очень полезным в мире объектно-ориентированного (OO) программирования, где Вы сосредоточены на том, что вещи делают или как они действуют. Если две вещи действуют одним и тем же способом, они могут быть объединены в едином классе. Даже если они значительно отличаются, они могли бы унаследовать их общие характеристики от родительского класса, опираясь на подклассы,
чтобы обеспечить их уникальное поведение. В мире проектирования реляционных баз данных мы, действительно, не заботимся сильно о том, как вещи действуют, мы заботимся о том, каковы они есть. В этом контексте, обобщение очень редко оказывается полезным. В мире OO программирования обобщение позволяет улучшить повторное использование кода, модульность, и возможность поддержки. Напротив, обобщение в базе данных приводит к двусмысленности, или потере смысла. Я подозреваю, что эта практика приобрела свое начало от
тех OO программистов, которые по ошибке думают, что таблица является аналогом класса, когда в действительности таблица - это переменная. Проницательные читатели распознают эту ошибку, которую Дейт назвал "Первой Большой Грубой Ошибкой", но это еще одна тема для другого времени...
Будьте осмотрительны, чтобы не обобщить вашу базу данных до крайности, встраивая в нее такую большую гибкость, что ваша система превратится в хаос (хаос, как предел гибкости). Помните, что основным мотивом использования базы данных является не "сохранение данных"; это может быть сделано более эффективно системами на основе файлов. Назначение реляционной базы данных состоит в том, чтобы предписать правила, которые управляют созданием, поддержанием и использованием данных; другими словами, база
данных предписывает правила, которые придают данным смысл. Без этих правил ваши данные становятся бессмысленным нагромождением единиц и нулей. В проекте базы данных, прежде всего, должна рассматриваться логическая непротиворечивость; все остальные вопросы вторичны. В конце концов, что именно является базой данных? Хью Дарвен (Hugh Darwen ) предложил наиболее полезное определение базы данных из всех, которые я встречал:
"База данных - это ряд аксиом. Ответ на запрос - это теорема. Процесс получения теоремы из аксиом - это доказательство. Доказательство строится посредством манипуляции символами согласно принятым математическим правилам. Доказательство (то есть результат запроса) так же непротиворечиво, как и правило."
Другими словами, Вы должны сосредоточиться на логической непротиворечивости вашего проекта базы данных, если хотите получать правильные ответы на запросы к базе данных. Если Вас интересуют просто ответы, то не стоит морочить себе голову всем этим "теоретическим" материалом.
24/03/2006
Полезная информация
§ Все статьи, публикуемые в рассылке, затем выкладываются на сайте Книги и статьи по SQL.
§ Поступила в продажу книга SQL. Задачи и решения, посвященная анализу ошибок, допускаемых при решении задач первого этапа. На сайте издательства Питер можно сделать заказ и познакомиться с содержанием.
Контакты
По всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77@yandex.ru. Вы также можете предложить свои задачи для публикации на сайте.