Обсуждение:SQL

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Пожалуйста, добавляйте новые темы снизу


pl\sql основан на JavaScript, а TSQL на VBScript??? Звучит довольно странно. Когда появились пл и транзакт ни о каких скриптовых языках даже речи не шло. Bibikoff 20:09, 14 июня 2007 (UTC)[ответить]

Да, я добавил непроверенную инфу, надеясь, что народ ее уточнит. Точно помню, что на лекциях нам говорили про какие-то такие аналогии. — Vano 13:26, 15 июня 2007 (UTC)[ответить]
PL/SQL основан на ADA. Источник: Pete Finnigan, Principal Consultant - How to unwrap PL/SQL.
К сожалению по сылке файла уже нет, но зато его содержимое есть в кеше гугла. Цитата со страницы 6: PL/SQL is based on ADA. --Hayk 14:33, 15 июня 2007 (UTC)[ответить]
«Основан Сатаной на языке Ада» %D %D %D --A.I. 15:39, 15 июня 2007 (UTC)[ответить]

Стандарты и уровни[править код]

Требуется написать пару абзацев о уровнях — core level, entry level и ещё какой-то — относительно стандартов SQL — Эта реплика добавлена участником CYCC (ов) 01:42, 6 октября 2008 (UTC)[ответить]

уже не нужно --CYCC 20:20, 16 октября 2008 (UTC)[ответить]

Стиль написания неэнциклопедичен[править код]

В данном виде статья напоминает скорее введение к диссертации, либо лекцию для студентов третьего-четвертого курса. Следует изложить материал более популярно, снабдить наглядными примерами. Посмотрите хотя бы на аналогичный текст в немецкой части - http://de.wikipedia.org/wiki/SQL (особенно начало статьи) Там люди не постеснялись "опуститься" до понятного изложения. Дело в том, что если читатель - специалист в данном вопросе, то ему и читать эту статью не надо. А расчет должен быть на тех, кто хочет разобраться в вопросе хотя бы в первом приближении.

Самое главное при изложении - это отсутствие боязни быть понятыми неспециалистами. Flingern 22:19, 27 марта 2009 (UTC)[ответить]

    • Решил исправить ситуацию. Ввёл новый раздел «Введение» для общего знакомства с предметом. Раздел «История» должен идти позже (если не в самом конце). Надо бы и сами операторы привести… --OZH 11:11, 19 марта 2010 (UTC)[ответить]
      • И по-прежнему местами очень невнятно. Например, раздел "дефекты SQL с точки зрения реляционной теории[6]". Вот что означает строчка "строки-дубликаты"? Плохо, что они присутствуют? Плохо, что они остутствуют? Плохо, что они возможны? Плохо, что они невозможны? То же самое касается и остальных пунктов. Перечислены, а дальше хоть трава не расти, пусть каждый понимает, как ему удобно? 46.0.194.56

ссылки на уроки sql запросов[править код]

По какой причине были удалены такие ссылки? --178.121.107.252 07:47, 24 июня 2012 (UTC)[ответить]

Про запросы, конструкции и реляционные операторы[править код]

Коллега Fedor Babkin предложил мне прокомментировать отмену следующего фрагмента:

Операторы SQL вместе с такими конструкциями языка SQL, как FROM, WHERE и так далее, позволяют составлять запросы на языке SQL для извлечения нужной информации из баз данных. SQL-запросы могут быть как простыми (например, с одним оператором SELECT и минимальными фильтрами), так и сложными, составленными из подзапросов или реляционных операторов.

Начнём с самого очевидного. Преамбула определяет SQL как «язык структурированных запросов» — язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей системой управления базами данных. В связи с этим фраза «Операторы SQL <...> позволяют составлять запросы на языке SQL для извлечения нужной информации из баз данных» представлется просто триумфом капитана Очевидность. Причём, двойным триумфом, поскольку фраза вида «операторы языка X позволяют что-то составлять на языке X» — это просто-таки проверка капитана Очевидность на профпригодность.

Далее, в цитате используется крайне смутная, неточная терминология, например: «Операторы SQL вместе с такими конструкциями языка SQL, как FROM, WHERE...». Операторы SQL — это тоже конструкции языка. Да все элементы языка, как атомарные, так и выражения, — это «конструкции» языка. Здесь видно, что пишущий не знает, как правильно назвать FROM, WHERE и т.п. Подскажу. Поскольку SQL специально придумывали не как алгебраический язык, а как псевдо-естественный язык, близкий к английскому (недаром он назывался сначала «Structured English Query Language»), то и в спецификации SQL унаследовал лингвистическую терминологию, в которой в общей фразе (statement) есть предложения (clauses). Эти придаточные предложения («клаузы» в русской лингвистике), так и называются в стандарте SQL: FROM clause, WHERE clause, GROUP BY clause и т.д. При этом, например, оператор SELECT в своём составе содержит клаузу (предложение) SELECT, и это совершенно не одно и то же. Термина «фильтр» в стандарте SQL нет, это специфичный для профессионалов жаргон, который очевидно незнаком и непонятен такому читателю, которому нужно разъяснять, что «операторы SQL позволяют составлять запросы на языке SQL». Сочетание в одной и той же фразе абсолютно очевидной информации с узким профессиональным жаргоном — стилистически крайне неудачное решение, при котором неясно, для кого такая фраза вообще предназначена.

Понятие «простого» и «сложного» запроса нигде не регламентировано и строго не определено, оно, скорее, относится к опыту программиста. То, что для одного «простой» запрос, для другого «сложный». «Минимальность» фильтра — из той же оперы. Фильтры с LIKE можно считать простыми или нет? Или речь только про сравнение с константами? Если сравнение с константами считается «простым», я приглашаю желающих погрузиться в чарующий мир мноогообразных форматов даты, которые могут по разному трактоваться людьми разных национальностей и по разному обрабатываться в системах, в которых есть региональные настройки клиента и языковые настройки сервера. Сочетание всего этого друг с другом приводит к непредсказуемым ошибками и непредсказумой работоспособности систем. Сделать так, чтобы константа даты обрабатывалась гарантированно правильно, нужно ещё уметь, и для некоторых это оказывается бОльшей проблемой, чем написать запрос с десятью джойнами и пятью коррелированными подзапросами.

Фраза про реляционные операторы в принципе некорректна. Я сейчас не скажу ничего нового для специалистов, но в SQL вообще нет реляционных операторов. В стандарте SQL нет ни слова про отношения, реляционную модель, реляционную алгебру, реляционное исчисление. Это не случайность, так сделано сознательно. Проектировала этот язык пара чуваков, которые руководствовались своим собственным пониманием РМД и своими собственными целями. Им было не нужно, чтобы под ногами путались всякие Кодды и прочие специалисты по РМД со своими раздражающими замечениями. Поэтому в SQL приходится аккуратно реализовывать аналоги реляционных операций, помятуя, например, про то, что РМД основана на множествах, а SQL — на мультимножествах, что РМД основана на обычной булевой логике, а SQL — на трёхзначной логике, которая, к тому же, всё равно полностью не реализована. Евгений Мирошниченко 11:37, 18 июня 2017 (UTC)[ответить]

Wiki - учебник[править код]

Есть ли он? (Как не быть)... Где же ссылка?

Oleg Ostapchuk (обс.) 20:05, 4 декабря 2018 (UTC)[ответить]

SQL = Structured Query Language?[править код]

Алан Бьюли в "Изучаем SQL" пишет: "И последнее замечание: SQL не акроним (хотя многие настаивают, что это сокращение от Structured Query Language". Правда, доказательств не приводит — Эта реплика добавлена с IP 109.197.195.76 (о) 15 февраля 2022 (UTC)

Это, видимо, лишь нелестно характеризует интеллект этого Алана Бьюли (кстати, кто это?) Евгений Мирошниченко 13:58, 15 февраля 2022 (UTC)[ответить]