Цикл статей по SQL

[Dimka]

Планируется написать ряд статей по SQL. Уже даже приступил.

Вопрос: кто что хочет в этом цикле узнать? Высказывайте сюда пожелания.

План статей следующий:

I. Собственно SQL
1. Введение (о языке, история и т.п.)
2. ЯОД (создание, изменение и удаление различных объектов баз данных, а также описание этих объектов: таблицы, индексы, связи, триггеры, процедуры, представления и т.п.)
3. ЯМД (insert, update, delete и select выражения без сложных примеров)

II. Решение задач построения запросов
1. Метод построения запросов (постановка задачи, общая схема проведения рассуждения, написание запроса, оптимизация)
2. Задачи на фильтрацию (вертикальную и горизонтальную)
3. Задачи на связывание таблиц
4. Задачи на группировку
5. Использование подзапросов
6. Типовые и решения сложных случаев (известные мудрёные запросы)
7. Разбор реальных задач (по просьбам трудящихся )

Параллельно хотелось бы вести обсуждение в этой теме на форуме всего, что будет встречаться в статьях и в жизни.

В качестве средства решения задач предлагаю MS Access (думаю, у подавляющего большинства трудностей с его установкой не возникнет). Для всего, что в Access отсутствует, предлагаю MS SQL Server. Также для упражнений понадобится база данных Northwind (имеется и в Access, и в SQL Server). SQL Server Desktop Engine устанавливается, например, вместе с Visual Studio .NET и с MS Office Developer.

[Spline]

Предлагаю, все примеры и упражнения делать на SQL сервер, а  с Access'ом я думаю можно и самому разобраться, на примере SQL Server.
И пожелание, все абревиатуры, давать на обоих языках, и с расшифровкой.
Например
Язык Манипулирования Данными (ЯМД) - DML
Язык Описания Данных (ЯОД) - DDL.

[Dimka]

можно и так. Мне даже удобнее будет целиком всё на SQL Server делать. Тогда, если есть возможность, следует пользоваться Query Analyzer. Или начиная с Access 2000 можно подключаться к SQL Server, т.к. Desktop Engine таких полезных вещей, как Enterprise Manager, Profiler и Query Analyzer не не содержит.

Но всё ж цель: максимальный охват аудитории, поэтому и к средствам надо относиться вниматель. Я понимаю, что в России можно пока что добыть и поставить что угодно, но в том же Израиле, как я слышал, с этим делом построже.

[Natalie]

Что-то я не поняла... эта тема закрыта??? где этот цикл статей??? и где по нему обсуждение??? подскажите... что-то я заблудилась на сайте...
и вообще если мнение по теме еще актуально, так я бы первые два пункта пропустила вообще. первый - книжек навалом... а второй болталогия... к делу... господа!!!

[Dimka]

Будет продолжение обязательно, просто я был занят.

[Natalie]

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

[Dimka]

Идей у меня достаточно, а приставания не помогут - статьи должны быть качественными, чтобы потом стыдно за них не было. Соответственно чаще раза в 2 недели - месяц их можно не ждать, если я относительно свободен. Последние 2 недели у меня было много работы, поэтому задержка возникла, сейчас отпустило - пишу.

[Natalie]

ок.    жду молча....

[Dimka]

Предложений и вопросов я жду. Однако предложения и вопросы должны иметь одно свойство: не отклоняться от темы SQL, ну а также по SQL Server и Access в той части, в какой эти СУБД будут использованы в статьях, соответственно по диалектам Transact-SQL и JetSQL. Если есть вопросы и предложения отличные - прошу создавать отдельные темы в разделах этого форума "Базы данных" или "Обсуждение/Заказ статей. Переводы".

[x77]

dimka, у меня тут тож в планах цикла статьев по Delphi & Ib. минимум теории, акцент именно на реализацию конкретных задач. первая статья есть, когда "Великий И Ужасный" кончит тормозить и даст линки - выложу. предложений, собственно, немае, просто темки буду пересекаться и может есть смысл как-то кооперироваться, ибо у тебя будет куча всего, чего я касаться не буду. и наоборот. расписывать синтаксис sql-запроса у меня нет желания, а вот, например,  принципы хранения метаданных в РБД - я буду трогать обязательно, типа, как вытащить sql-запросом список внешних ключей, к примеру. короче, ещё раз, это пока не предложение, а смутные мысли вслух, подумай, мож ты более конкретно сформулируешь, думаю, наджо дружить домами

и отдельная тема: надо как-то упорядочивать это всё. по базам грех, например, не ссылаться на материалы Alf'а, но механизма для таких ссылок нет. тупо вбить линк статьи - это не то. надо более конкретно.

грубо говоря. если каждый автор каждый абзац будет в обязательном порядке маркировать неким образом (anchors, хотя-бы), то другие авторы смогут ссылаться на его материал более конкретно. идея бредовая, но ничего лучше пока в голову не лезет.

[Dimka]

x77, аналогично, жду линки на рисунки к статье

Я строю свои статьи на основании статей Alf'а. Т.е. я не объясняю, что такое НФ и с чем его едят, не объясняю методы проектирования БД. Я рассказываю только о SQL, и прямо упоминаю, что для чтения статьи нужно иметь представление о нормализации, уметь читать диаграммы "сущность-связь", иметь общее представление о реляционной алгебре.

Метаданные SQL Server я не описываю: я описываю сам SQL, а не конкретную СУБД (по мере возможностей). Что касается запросов, то их буду отрабатывать на учебной базе Northwind, приложеной как к серверу, так и к Access.

[Dimka]

Объявляю о небольшой перестановке в описанном в самом начале плане. Без ЯМД мне трудно будет давать хранимые процедуры, триггеры и представления, поэтому данный раздел ЯОД пойдёт после ЯМД.

[Гром]

x77, а как ты представляешь сбор абстрактного материала для перекрестных ссылок, без "тупого" вбивания их в текст статьи в нужное место??? БД - не чудо, туда тоже надо вбить, и реализация в абстрактном метсе обычной текстовой ссылки, в виде отдельных полей - неизвестного колличества для статей и перекретсных ссылок - глупее не придумаешь.
Как и анкоры, которые вы сами вставляете в большинство своих статей.  Можно на каждый Enter ставить анкор, но как ты узнаешь сколько их в чужой статье - ИМХО вы с больной головы на здоровую перекладываете, слишком много автоматизации - уже плохо.

dimka, я не торможу - нет времени, очень занят, буду делать как только вылезу!!!

[Dimka]

Гром, всё решается относительными путями. Куда б не переезжал бы сайт, чтобы ни происходило с физическими путями - введённые виртуальные пути должны оставаться неизменными - так можно безболезненно перетаскивать всё множество материала без потери перекрёстных ссылок. А перевод виртуальных в текущие реальные - это задача движка при генерации страницы. Картинки, кстати, тоже хорошо бы в базе хранить. Я в своих статьях реальные ссылки писать не рискую именно потому, чтобы они не загнулись в один прекрасный день. Сопровождать свои статьи (обновлять в них ссылки по мере надобности) у меня желания нет.