Чому бази даних не інтегровані як мовна функція?

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

Єдиною мовою, яку я можу придумати, - це старі мови xBase, такі як DBase, Clipper та FoxPro. Є проект GNU, який пропонує безкоштовну і в основному сумісну версію під назвою Clip

Також був Pick Basic, який прив'язав мову програмування безпосередньо до платформи бази даних.

Це зроблено. Це був еволюційний глухий кут, який обмежував доступ мови до даних.

Мови "малі", а бази даних - "великі"; тож коли вони поєднуються, це не мова з базою даних як особливості, а база даних з мовою як особливістю. У багатьох базах даних є прикріплені до них деякі власні мови, наприклад, PL / SQL, T-SQL.

Я не обов'язково думаю, що правильне питання - "чому їх немає?" але "навіщо там бути?". Що можна отримати від того, щоб бази даних були особливістю мови? Пам’ятайте, мова знаходиться в самому дні стека програмування. Зростання мови роздутою впливає на все . Таким чином, мовним дизайнерам потрібно неквапливо додавати нові функції, особливо ті, які б передбачали таку інвестицію.

Існує 3 застарілих системи, що відповідають вашим вимогам:

1. Виберіть ,
2. СУМКА ,
3. Microsoft Access

Pick і MUMPS були розроблені за роки до першої академічної роботи про реляційні бази даних (це було приблизно за десять років до того, як перша комерційна система баз даних на базі SQL вийшла на ринок - від компанії, яку ми зараз називаємо Oracle; перша спроба IBM про продукт продумала і пізніше була успішна система на базі SQL). Ви можете їх знайти досі (наша система місцевого громадського транспорту використовувала Pick до недавнього часу для системи планування поїздок). Ви не хочете нічого робити ні з Pick, ні з MUMPS, а найкраща порада, яку я можу дати, - це "відійти від клавіатури руками в повітрі!" Якщо ви робите що - небудь зробити з ними, фраза «ти пошкодуєш» повинен бути дзвін у вухах.

Microsoft Access піддається серйозним знущанням та критиці в ІТ-колах, оскільки не розробникам досить легко зробити критичну ділову програму з доступу та переробити її в щось, без чого компанія буквально не може жити. Також цілком ймовірно, що досить багато розробників почали розробляти через MS Access, і, як все продовжувало зациклюватися, вони навчилися їх виправляти (перший крок - традиційно вивчити візуальний базовий і переписати додаток Access спочатку в VB, потім у чомусь «кращому»). Можна зробити добре сприйнятий додаток Access, який розповсюджується з величезною кількістю даних - я бачив, що це зроблено, - але існують простіші способи зробити це, і для отримання (і підтримки) колодязя потрібно набагато менше навичок. вела додаток із VB та SQL Server.

Починаючи з SQL Server 2005, Microsoft представила можливість вводити CLR у збережені процедури та функції. І якщо ви хочете бути хитрими щодо цього, ви можете зробити типи даних, які ви могли б використовувати як стовпці бази даних. Я думаю, що у Oracle було щось подібне з Java.

Якщо говорити, я не думаю, що щось зупиняє вас у створенні такого або гіпотеза про них. Вибір та МУМПС старші за більшість кодерів тут і відображають дуже COBOLy погляд на світ.

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

Додавання бази даних до мови програмування може задовольнити лише дуже вузький набір користувачів. Що робити, якщо вони хочуть використовувати деякі функції RDBMS? Або взагалі не хочете використовувати базу даних? У таких випадках використання компілятора буде необмеженим.

Помилка

Ну, по-перше, ви запитуєте, чому структура, в якій діє мова, не забезпечує базу даних. Мова - це просто засіб виразити те, що ви хочете зробити в заданих граматиках; він насправді не надає подібні послуги. :)

Однак це є кілька причин.

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

• База даних, яка отримує навантаження, повинна знаходитися на своїй окремій машині, а не в процесі дії коду, який має доступ до неї.

• ORM забезпечують велику безпеку типу і перевіряють час компіляції, що було б користю від такої дії, не маючи насправді рамки, намагаючись бути базою даних.

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

вони є; такі мови називаються 4GL . DataFlex - мій улюблений, хоча я його більше не використовую.

Caveat: Я допоміг розробити об'єктно-орієнтовану версію DataFlex, v3.0

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

Мови загального призначення розглядають усі IO як одну і ту ж, будь то запис або читання з / з диска, веб-камери, мережі, екрана, місця в пам'яті - це все IO, і це все, що стосується самих мов програмування з.

Насправді, окрім читання / запису до купи та стеку, більшість мов програмування навіть не роблять жодного фактичного IO. Деякі мови надають натільні функції для вираження операцій вводу-виводу (наприклад, print команда в BASIC), але більшість мов просто трактують їх як звичайні виклики функцій (наприклад, printfна C) і дозволяють бібліотекам обробляти фактичну запис.

Деякі мови, такі як C #, пропонують мовні функції для вираження запитів, але навіть тоді вони є лише виразами на найосновнішій структурі даних списків (або IEnumerables, як їх називають у .NET), які перетворюються бібліотеками на операції SQL - сама мова все ще просто працює з дуже абстрактними поняттями IO.

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

Так. Мови на платформі AS / 400 мають рідну, першокласну підтримку баз даних.

Це пов'язано з тим, що платформа AS / 400 має всю інтегровану базу даних скрізь і дозволяє отримати безліч дуже приємних функцій, таких як простота навігації через набір результатів, оновлення значень на шляху.

Залежить від мови та платформи. Наприклад, для мене досить тривіально використовувати різноманітні бази даних під час роботи з C, я просто використовую відповідну бібліотеку.

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

Принаймні, це стосується мов, які відповідають стандартам, встановленим такими організаціями, як ISO.

Як написано, питання частково неправильне, як показали деякі зустрічні приклади, наведені вище.

Тому я спершу уточнив питання, щоб прочитати: "Чому СУБД, як правило, не інтегрована як особливість мов програмування високого рівня загального призначення?"

Це з тієї ж причини, що інші програмні продукти, такі як операційні системи, файлові системи, веб-сервери, шари кешування тощо, як правило, не вбудовані. Мови загального призначення, як правило, працюють на рівні абстракції, що перевищує рівень таких продуктів. Тому програміст розумно впроваджувати СУБД умова загального призначення, і що СУБД може навіть розкривати аспекти своєї материнської мови або специфічної для БД декларативної мови для використання програмістами БД. Але є занадто багато варіантів проектування в написанні СУБД, щоб було розумно виправити їх загальною мовою програмування. Якщо ви їх виправите, ви опинитесь на кшталт MUMPS, де заплутування цих двох результатів спричинило цілу галузь, забруднену проблемою з куркою-яйцем, застрягши зі застарілою СУБД і застарілою мовою програмування.

Використовується для роботи в NonStop / SQL, який був повністю інтегрований у NonStop / C, NonStop / C ++, NonStop / Cobol, NonStop / Fortran та, ймовірно, інші мови, а також повністю інтегрований з NonStop / Guardian, операційною системою, на якій працюють комп'ютери побіг.

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

Найближчим, до якого ви збираєтеся потрапити на ПК, швидше за все, буде MS Access, а Embarcadero / Borland Delphi - це найближча секунда.

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

Як колишній розробник Visual Foxpro, мені важко, що жодна основна мова не визначає реляційну модель як частину мови.

Мати повний механізм баз даних - це не дуже гарна ідея, але натомість мова "SQL" може бути ДУЖЕ корисною.

У ОО існують невідповідність імпедансу. Це сталося тому, що предмети і встановлені не так, як один до одного. Але якщо мова дозволить мені визначити ТАБЛИЦІ, ПОЛИ, ВЗАЄМОДІЇ, ОБЛАДНАННЯ тощо (не прив'язуючи їх до певного сховища), буде дуже потужним. Крім того, створення ORM буде більше відображенням 1 на 1.