Чому SQL називається мовою, що базується на стосунках / функціональній?

Ми дізнаємося, що більшість мов класифікуються як будь-яка з двох, "заснована на стосунках" або "високий рівень". Я ніколи раніше не використовував SQL, але, читаючи його синтаксис, це здається більше схожим на синтаксис імперативного / високого рівня, ніж на функціональний / на основі відношень (Lisp, Haskell) ??

Або може бути так, що моє тлумачення лекційних записок мого професора є неправильним ... але воно, безумовно, перераховує SQL як одну з мов, що ґрунтуються на стосунках (на відміну від високого рівня), і вона прирівнюється до функціональних відносин ... чи, можливо, я не розумію, чому той факт, що SQL має відношення до реляційних баз даних, робить функціональну мову таким, яким він повинен бути реалізований? (і чому "класифікація на основі відносин" при класифікації мов програмування порівнюється з "функціональною"?)

Спасибі :)

Ми дізнаємося, що більшість мов класифікуються як будь-яка з двох, "заснована на стосунках" або "високий рівень".

Ці поняття є ортогональними. "На основі відносин" означає, що семантика мови базується на концепції відношення, тобто асоціації "багато-багато" між двома наборами (відносини є математичною основою за таблицями SQL). "Високий рівень" означає, що мова містить безліч абстракцій, які приховують значну частину основних технічних деталей (таких як місця пам'яті, регістри процесора, доступ до диска, бітові операції тощо). SQL, безумовно, заснований на відносинах, оскільки його основна мета полягає в описі реляційних даних та операцій над ним. SQL також досить високий рівень; він не надає жодних засобів для доступу до байтів на диску і не повідомляє вам деталей про те, як він зберігає свої дані (принаймні, стандартний SQL не робить;

Насправді існує набагато більше осей, за якими можна класифікувати мови програмування (та даних); особливо цікавим є декларативний проти імперативного . Декларативні мови описують те , що що - то є ; імперативні мови описують, як щось робити . DDL частина SQL в основному декларативний, не дивлячись на настійні перспективних ключових слів ( " CREATE TABLE», " DROP DATABASE" і т.д.), і навіть маніпулювання даними частина ( SELECT, UPDATE, INSERT, DELETE) все ще досить декларативним. Дуже цікавою властивістю SQL є те, що він не є Turing завершеним: ви не можете написати без обмеженого циклу в звичайному стандартному ANSI SQL.

Функціональне програмування орієнтується на кілька основних ідей:

• функції - це першокласні громадяни (тобто вони можуть використовуватися як значення, і як вхід до інших функцій, і як вихід з інших функцій)
• функції вищого порядку (функції, що працюють над функціями, або функції, що повертають функції)
• чистота (чиста функція - це така, яка не має побічних ефектів; чиста функція не може робити жодного вводу-виводу, вона не може читати і не змінювати жодного глобального стану, і не може приймати нестандартні аргументи. Чисті функції особливо цікаві, оскільки вони будуть завжди виробляють один і той же вихід з однаковими входами)

SQL, безумовно, не обертається навколо функцій як основного інструменту моделювання речей, але дещо охоплює ідею чистоти - той самий запит, який виконується в одній базі даних, дасть той же результат кожного разу (за винятком замовлення). Викликання SQL "функціональною" мовою - це дещо розтягнення, хоча ІМО.

SQL не є обов'язковим, оскільки процес вирішення запитів і зв'язків HOW визначається не програмістом, а скоріше компілятором / оптимізатором / інтерпретатором. SQL - декларативна мова - у SQL ви оголошуєте відносини. Це створює структуру даних (яка знову не є фізично визначеною мовою, а її реалізацією), використовуючи вставки, оновлення та видалення.

Використання відносин потім здійснюється за допомогою запитів (SELECT заяви), які функціональні тим, що вони не мають побічних ефектів.

Вся справа обмотана навколо реляційної моделі .

SQL насправді не стільки функціональна мова, скільки декларативна. Загалом, функціональні мови підкреслюють декларативний стиль над імперативом, щоб мінімізувати побічні ефекти. Це може призвести до того, що деякі люди називають SQL функціональним, але це не точно. Це декларативне значення з процесуальними елементами.

Чи можливо ваші нотатки зашифровані?

Я ніколи не чув, щоб мови програмування розділялися між "залежністю" та "високим рівнем". Низький рівень / Високий рівень зазвичай використовується для відмежування асемблера та С від мов, які забезпечують пряму підтримку більш абстрактних структур. Відносини є досить абстрактною структурою, тому я б сказав, що все, що підтримує відносини, є високим за визначенням.

Чистий SQL, як правило, описують як декларативну мову, з деякими постачальниками накладаються деякі процедурні біти. Те, що SQL не підтримує функції як змінні, мені здається, негайно позбавляє його функціональної мови.

SQL - це реляційна, заснована на мові мова, яка має функціональні функції процедури.

Я не знаю, чи вважав би я функціональний SQL, однак у нього є деякі аспекти функціональних мов. Сучасні варіанти SQL (з процедурними бітами), безумовно, не функціональні.

Я думаю, SQL - це синтаксичний цукор навколо реляційної алгебри + щось більше. Реляційна алгебра має велику силу функціональних мов, вона дійсно використовує функції дуже високої виражаючої сили (вибір, проекція, перейменування, приєднання, об'єднання, перетин ...). Але, наскільки я знаю, основне лікування реляційної алгебри зазвичай не має еквівалента лямбда-оператора, хоча воно може бути розширено за допомогою оператора рекурсії безперешкодно.

Я думаю, що алгебра відношень - це швидше алгебраїчна мова. SQL зі своїми підзапитами перейшов від чистої реляційної алгебри до більш функціонального стилю, але без лямбда-оператора, я думаю, що це не повноцінна функціональна мова. Я не знаю, чи можна це безперешкодно поширити на повну функціональну мову, я не знаю у цій галузі. У Haskell є кілька бібліотек з ціллю мов баз даних дуже високого рівня.

Я не знаю всіх допоміжних програм, що потрібно для того, щоб мова була кваліфікована як функціональна, але Sql Server запровадив дуже цікавий спосіб роботи з функціями. Спеціальне застереження робить функції, здатні взаємодіяти разом у запиті. Він називається Застосувати. Коли я пояснив це колишньому програмісту APL, він сказав мені, що в APL існує аналогічний пункт щодо подібної мети. Застосувати застереження дозволяє передавати набір атрибутів з рядка таблиці або рядка функції таблиці як вхід до іншої функції. Зважаючи на це, я наклав обмеження на тип функції таблиці, щоб записати її як функціональну. Потрібно оголосити як вбудований, що означає вираження у вигляді одного вибору. Це нав'язує відсутність змінних. Такі запити з великою кількістю логіки можуть бути записані, якщо ви використовуєте загальні вирази таблиці, які потім дозволяють перетворити вирази в стовпчик, свого роду незмінну змінну, яку можна повторно використовувати в інших CTE. Врешті-решт, функція стає дуже великим макросом, завдяки чому оптимізатор може вільно оптимізувати те, як потрібно. Єдине, чого не вистачає людям, - це кілька простих хитрощів для написання умовної логіки та оголошені деякі дані, що підтримують логіку у запиті. Нарешті, деякі функції, що використовують надмірну пропозицію, потрібні як спосіб перенесення результатів як значення, що може бути використане в ряду з інших рядків, але це було б трохи довше. Єдине, чого людям бракує, - це кілька простих хитрощів, щоб написати умовну логіку та оголосити деякі дані supportlogic у запиті. Нарешті, деякі функції, що використовують надмірну пропозицію, потрібні як спосіб перенесення результатів як значення, що може бути використане в ряду з інших рядків, але це було б трохи довше. Єдине, чого людям бракує, - це кілька простих хитрощів, щоб написати умовну логіку та оголосити деякі дані supportlogic у запиті. Нарешті, деякі функції, що використовують надмірну пропозицію, потрібні як спосіб перенесення результатів як значення, що може бути використане в ряду з інших рядків, але це було б трохи довше.