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

Я буду искренне рад всем замечаниям, дополнениям и поправкам к вышеобозначенной статье. Как бы это ни было банально, но "одна голова хорошо, а 1157 еще лучше..."

Всем спасибо!

Написано: 10.1.2003,22:32 Oleg

Не забудь про SELECT FOR UPDATE!

Написано: 11.1.2003,13 : 06 simanyay

Так держать! Молодец!

Написано: 13.1.2003,06:37 Vit

Несколько пожеланий.

1) Попробуй сначала объяснить работу SQL на одной таблице не вдаваясь во взаимосвязи, уверен, что  половина читателей, не искушенных в БД, дойдя до 4х таблиц и непонятной схемы со стрелками читать бросят. В общем я бы сначала разобрал как работают Select, Update, Insert, Delete на одиночной таблице, показал как строятся части Set, Where, Order, Group, а лишь затем рисовал 2 (не 4!) таблицы с взаимоотношениями и показывал как делать квери на нескольких таблицах, Join и т.п. Да, ты будешь повторятся и Select будет рассмотрем в 2х разных местах, но это будет намного легче. Далее, для рассмотрения взаимоотношений достаточно 2х таблиц - приводи только 2 используемые и рассматривай их (да, я знаю что взаимоотношения будут нужны разные, но в каждом случае надо будет привести свой пример из 2х таблиц)...

2) Не стоит приводить отрывки из стандартного хэлпа с перлами типа

Цитата

SELECT [DISTINCT  | ALL] {* | <значение1> [, <значение2> …]}   FROM <таблица1> [, <таблица2> …]       [WHERE <условия поиска>]       [GROUP BY столбец  [COLLATE collation] [, столбец1 [COLLATE collation]…]]       [HAVING <условие_поиска>]       [UNION <оператор_select>]       [PLAN <план_выполнения_зпроса>]       [ORDER BY <список_столбцов>]

Новичёк в этом ничего не поймёт, а опытный и сам разберётся, просто приведи вместо этого 5-6 примеров, собственно как ты и начал делать, а вот если уж так хочется эту муть вставить, то вставь после разбора примеров, как итоговую схему синтаксиса. Лично меня уже достали хэлпы по SQL в которых на каждый топик лежит по такой схеме и ни одного примера как это реально сделать.

3) По-больше примеров! ВСЕ руководства и хэлпы по SQL, словно сговорившись, пишутся с исключительно малым количеством примеров. До сих пор под час я просматриваю десяток книг и пол сотни сайтов чтобы найти  в общем-то простой пример использования той или иной возможности SQL, о которой во всех источниках напиано что-то, типа "[Operator <option>,{request}]".

4) А вообще мне нравится, за исключением этих пожеланий - изложение чёткое и простое.

PS. Мой топик можно будет в будущем стереть чтобы не портить изложение.

Написано: 13.1.2003,06:52 Pegas

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

Написано: 13.1.2003,06:58   Pegas

По поводу:

Цитата  

2) Не стоит приводить отрывки из стандартного хэлпа с перлами типа

Цитата

SELECT [DISTINCT  | ALL] {* | <значение1> [, <значение2> …]}  FROM <таблица1> [, <таблица2> …]      [WHERE <условия поиска>]      [GROUP BY столбец  [COLLATE collation] [, столбец1 [COLLATE collation]…]]      [HAVING <условие_поиска>]      [UNION <оператор_select>]      [PLAN <план_выполнения_зпроса>]      [ORDER BY <список_столбцов>]

Новичёк в этом ничего не поймёт, а опытный и сам разберётся, просто приведи вместо этого 5-6 примеров, собственно как ты и начал делать, а вот если уж так хочется эту муть вставить, то вставь после разбора примеров, как итоговую схему синтаксиса. Лично меня уже достали хэлпы по SQL в которых на каждый топик лежит по такой схеме и ни одного примера как это реально сделать.



понимаешь, Vit, я специально так делаю. Если использовать такие "перлы" наряду с богатыми и полными примерами, то у начинающего программиста, на подсознательном уровне будет вестись запоминание этих "перлов".

он будет невольно сравнивать эти блоки:

Цитата

SELECT {* | <значение1> [, <значение2> …]}   FROM <таблица1> [, <таблица2> …] с    SELECT *    FROM Tovar и    SELECT ID, NameTovar, Unit, Price    FROM Tovar

и как говорил один мой хороший знакомый, "вот тут и начнется процесс постепенного осмысления"

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

Написано: 13.1.2003,07 : 05 Vit

Цитата

2) Не стоит приводить отрывки из стандартного хэлпа с перлами типа .... я специально так делаю.

Зря, тогда твоё описание будет мало отличатся от стандартной справки или какого-то спавочника. А здесь ИМХО (посмотри на голосование - все самоучки!), как я понимаю, надо сделать упор именно на простоту и лёгкость изложения, так как справочник мы всё равно не вытянем! Ну если уж никак без этого, то помести его хоть в конец.

PS. Зря надеешься что этот метаязык описания конструкций здесь все знают, я его тоже когда начал SQL изучать не знал, теперь знаю, но изучать примеры на нём было очень-очень не приятно, да и сейча я к нему особой симпатии не испытываю.

Написано: 13.1.2003,07:22 Pegas

Я не собираюсь делать основной упор на метаязык, это скорее будет у меня как дополнение, основной упор будет на примеры, я расчитываю уделить им около 70% всей статьи. Просто чем дальше будет вестись изложение, тем больше будет примеров, и тем меньше будет "перлов". Но просто "втиснутый" в жесткие рамки логики изложения, я как раз-то и вынужден эти метаконструкции помещать в начале, а не в конце. Всю логику этой статьи я построил на принципе "чем дальше, тем понятней", и обещаю, и в дальнейшем его придерживаться.

Написано: 13.1.2003,13:28 U-gene

1)Журнал, где Кодд опубликовал свою статью, называется "Communication of the ACM".
2) Вместо (или вместе) с длинными и неинформативными обозначениями стандартов мможно дать их широкоупотребляющиеся обозначения SQL-89, SQL-92 и SQL3

Написано: 13.1.2003,20:26 Pegas

Цитата

1)Журнал, где Кодд опубликовал свою статью, называется "Communication of the ACM". 2) Вместо (или вместе) с длинными и неинформативными обозначениями стандартов мможно дать их широкоупотребляющиеся обозначения SQL-89, SQL-92 и SQL3

Очень хорошие дополнения. Спасибо.

Написано: 13.1.2003,20:50 Vit

Классно! Если хватит терпения продолжать в том же духе, то получится лучшее пособие по SQL в рунете!

Хорошо, теперь удали все лишние постинги из статьи и закрой тему, чтобы никто писать не мог.

Написано: 13.1.2003,21:12 Pegas

Большое спасибо Vit.

Написано: 13.1.2003,21:40 Admin

Да, просто замечательно  Я уже начал рисовать баннер для рекламы этого замечательного пособия! )) Но вообще, я думаю в будушем надо создавать две темы. В одной само пособие, а в другой теме - обсуждение и задавание вопросов! Имхо, получится очень симпатично!

Написано: 13.1.2003,22 : 07 Pegas

Да, Админ, я тоже над этим задумывался..... жалко только что постинги нельзя перебрасывать.... но что-нибудь придумаю...

P.S. Спасибо за поддержку!  

Хм.. вот собственно и придумал....

Немного дополнил раздел, посвященный оператору сортировки ORDER BY. Дал разъяснения параметрам сортировки ASC и DESC.

+ 2 новых раздела

добавил 5 новых разделов:

Использование BETWEEN
Ключевое слово IN
Использование UPPER
Использование LIKE
Функция CAST


Если у вас будут какие-либо замечания и пожелания, жду с нетерпением.

Спасибо!

Всё замечательно...

Спасибо!

Не хватает описаний по операторам INSERT, DELETE..........
Может я чего то не досмотрел все может быть!!!

Да, я успел пока рассказать только о выборке данных (Data Retrieval). Сейчас чуть-чуть освобожусь, и продолжу. Материал в принципе уже подготовлен, просто необходимо его немного подкорректировать. Ждите, скоро будет.

А почему ничего не сказали об Iner Join, и кстати, а чем то оно будет отличаться от объединения через Where? Или это по сути дела синонимы Если так, то зачем тогда ввели эту возможность, когда вполне можно обойтись и Where?
И еще один вопрос: По сути говорили об объединении таблиц при соотношении 1:1, 1:M, M:1, а чем то принципиально будет отличаться объединение таблиц в соотношении М:М? Или оно так же будет выглядеть, как и 1:М, только добавится условие объединения черех промежуточную таблицу, когда поля этой таблицы не будут находится в списках полей НД (впрочем иногда это и не так, но я рассматриваю самый простой вариант, когда в промежуточной таблице имеется только два поля)

Если Вы еще раз внимательно почитаете статью, то прямым текстом найдете ответы на все эти вопросы.

Пегас, отличная статья! Сорри за оффтоп, ты бы мог написать полные выходные данные используемой в ней книги Шумакова (Автор-название-год-место издания), нужно очень.

Delphi 3.0 и разработка приложений баз данных

Авторы: Шумаков П.В.
Издательство: "Нолидж"
Переплет: мягкий, год издания: 1999, страниц: 704
ISBN: 5-89251-022-0, формат: 70х100/16

Пора бы уже и продолжение выложить. Или школа закончилась?
Мне вот интересно бы было узнать что такое [PLAN] в

SELECT [DISTINCT | ALL] {* | <значение1> [, <значение2> …]}
FROM <таблица1> [, <таблица2> …]
[WHERE <условия поиска>]
[GROUP BY столбец [COLLATE collation] [, столбец1 [COLLATE collation]…]]
[HAVING <условие_поиска>]
[UNION <оператор_select>]
--> [PLAN <план_выполнения_зпроса>]
[ORDER BY <список_столбцов> [ASC|DESC]]

и как этим пользоваться.
Опять же хотелось бы рассмотреть более сложные примеры запросов. Например такая задача:
Надо сгруппировать записи по полю Code (например), применить агрегатную функцию Count (Code), затем Having (Count>1)? а потом вывести все строки с Code отобранным в Having. У меня в запасе есть и другие задачки.

Да, можно уже и вторую часть готовить А что? Взялся за гуж....

Ок, скоро будет проолжение. Я на днях подправил ошибки в этой статье, и перевел результаты запросов из картинок в таблицы html. В ближайшие две недели будет продоложение.

Да и если есть интересные задачи, то пишите письма с задачами, я обязательно их включу в качестве примеров.

мыло смотрите в низу моих топиков. (кнопка E-mail)

Спасибо.

А что в документации по языку кроме SELECT ничего не должно быть?
а как же INSERT, UPDATE, DELETE в конце концов

Цитата(Pegas @ 14.1.2003, 03:22)

Исходя из рекомендаций Админа, и личного опыта, было решено вынести обсуждение данной статьи в отдельную тему. Я буду искренне рад всем замечаниям, дополнениям и поправкам к вышеобозначенной статье. Как бы это ни было банально, но "одна голова хорошо, а 1157 еще лучше..." Всем спасибо!

И где же эта статья сама собственно. Дайте линк!

Да вообщем-то немного ниже этой - Основы языка SQL

Статья респект.
Жалко только она заморозилась

Пегас, большое спасибо за статью.

Хочется верить, что продолжение всё же будет

Никогда не занималась базами данных, не программированием. Села, прочитала и все поняла. В душе "горит" желание заниматься этим оставшеюся жизнь. Очень очень спасибо

Pegas

спасибо за науку, большой респект!!!!

у меня тут темка для анализа эксперта есть: как сделать максимально эффективную оптимальнейшую связку в куске базы данных в ситуации с хранением таких таблиц как:
адреса,
контактные данные,
клиенты,
подрядчики,
работники

я пока никак не могу впихнуть работников вместе с компаниями в одну обойму - хотя по сути адрес у них один и тот же атрибут и совершенно тождественный по смыслу.
но если делать одну таблицу связку по id_адресам id_объектам - то в таблицу попадут идентификаторы из списка компаний и из списка работников - а они же и там и там целые числа - все перемешается низззя так.....
но все равно хочется впихнуть....неужели я дошел до предела тут?

molodez. sposibo vit

Цитата

Delphi 3.0 и разработка приложений баз данных Авторы: Шумаков П.В. Издательство: "Нолидж" Переплет: мягкий, год издания: 1999, страниц: 704 ISBN: 5-89251-022-0, формат: 70х100/16 Нужно очень

Если еще актуально, есть в электронном варианте.
Добавлено @ 01:40
Статья-то будет еще развиваться? К примеру, update, insert...? Если надо, могу помочь кучей справочников. Соберешь самый полный сабж в Рунете

Пегас, дайте, пожалуйста, описание инструкции INNER JOIN, если можно, то в таком стиле, как вы писали статью (просто и доходчиво). Заранее благодарен.

Если сильно надо, в принципе, я могу накатать...

Ох, хотелось бы чтобы в начале статьи указывался диалект (версия) SQL.
Ибо

Код

temp='C:\tututu\blabla\12726345.dbf'  select f.*,pos.*;       from &_pay f,&atm_pos pos;       where pos.id_pos=val(trim(f.contr_num));       INTO dbf &temp

тоже SQL

Это сообщение отредактировал(а) bas - 2.8.2005, 15:09

Всем добрый день.

Статья очень хорошая, написана грамотным и понятным языком.
Очень хотелось бы продолжения.
И увы - но картинки с результатами работы запросов у меня не отображаются. =(
Надеюсь все изменится, если снова запостят книгу, уже с HTML талибцами.

Заранее спасибо и огромный респект.

Если кто-то захочет попрактиковаться или поэксперементировать с запросами SQL из статья автора, то можете воспользоваться вот этим кодод для MySQL, воссоздающим базу данных автора.
Если модератор не против, то я хочу разместить этот код здесь.

Статья однозначно супер!!!

Цитата(Ruselus @ 9.8.2005, 06:15)

И увы - но картинки с результатами работы запросов у меня не отображаются.

Сходите на сайт автора http://pegas.vingrad.ru/pegas/article/db/base_sql.htm
Добавлено @ 15:38

Цитата(Pegas @ 22.5.2005, 13:47)

Дописал я статью, все картники заменил на html таблицы, и про INNER JOIN тоже написал. Толкьо все никак не подберу времени перемесить статью в FAQ. Сегодня ночью перенесу.

Автор, и хде усё енто есть ?
Наверное заняты?

Это сообщение отредактировал(а) Иль - 5.10.2005, 17:53

Автор, опечатка (см первую часть статьи на вашем сайте)!
Для запроса

Код

SELECT *  FROM Sale  ORDER BY Date_sale, Sum_sale

приведена таблица для запроса без Sum_sale

Код

SELECT *  FROM Sale  ORDER BY Date_sale

Еще опечатка.

Код

SELECT S.*, T.NameTovar  FROM Sale S, Tovar T  WHERE (S.Tovar_ID = T.ID) AND (S.Date_Sale = '12.01.2003.')

Выражение не работает из-за опечатки. Удалите точку в конце '12.01.2003.'
Добавлено @ 18:43
И в сразу следующем выражении такая же опечатка, + результаты по нижней строке не сходятся (лень разбираться), там Рубашка и 50 надо заменить на Колбаса и 7. Также в этом результате вставлен не существующий в таблицах того запроса столбец Waybill_ID. Правда этот Waybill_ID потом еще много где невтему встречается, думаю у автора так сервер работает, показывая внешние (связанные) ключи (и это очень хорошо)

Для этого запроса

Код

SELECT *  FROM Sale S  WHERE S.Number_Sale NOT IN (1000, 3000, 1500, 2000, 750)

У меня таблица раза в полтора больше получалась, хотя играл с разными значениями, все работает

В запросе

Код

SELECT S.ID, S.Sum_sale, S.Number_sale, S.Date_sale, T.NameTovar  FROM Tovar T, Sale S  WHERE T.ID = S.Tovar_ID AND S.Tovar_ID IN ( SELECT Tovar_ID FROM Sale WHERE Sum_Sale = ( SELECT MAX (Sum_Sale) FROM SALE)) ORDER BY S.Sum_Sale DESC

Результат получился похожим, но в полтора раза меньше

В общем еще результата 3 не совпало в районе "вложенных" запросов, но уже потерял интерес разбираться почему так...

Опечатка в заголовке таблицы Таблица факультетов (Facult) . На самом деле в запросах везде Fakult.

Вот еще опечатка. В предложении

Код

SELECT *  FROM Students S LEFT JO IN Fakult F ON F.ID = S.F_ID

JO IN пишется без пробела

Это сообщение отредактировал(а) Иль - 5.10.2005, 20:34

Уф, ну вот и все. Проверил все SQL выражения из статьи.
Добавлено @ 20:47
Елки! Чуть не забыл! Проверял конечно отсюда http://pegas.vingrad.ru/pegas/article/db/base_sql.htm , тк там есть таблицы результатов

Спасибо за подробнейший рассказ... все бы продукты так бы разжевывались - в стране одни профи были бы

Это сообщение отредактировал(а) RainMan - 27.11.2005, 11:32

Небольшой вопрос по примеру:

Пример: Выдать количество проданных товаров на каждую дату

Причем тут DISTINCT и таблица Tovar?
Такое решение правильное:


p.s. пособие отличное, только вот картинки не отображаются.

Medved, 
А где статья то?
Тут нету!   

Она здесь.

LSD, 
спасибо.
только посмотрите верстку, в лисе последняя таблица не отображается. Вместо идет текст html.

а где окончание статьи???

после этого хтмл-текста больше ничего нет....