The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Опубликован стандарт SQL:2023

03.06.2023 15:43

Международная организация по стандартизации (ISO) утвердила и опубликовала международный стандарт SQL:2023 (ISO/IEC 9075), который определяет девятую редакцию спецификации языка SQL, применяемого для манипуляции данными в реляционных СУБД. Прошлое обновление спецификации было выпущено в 2016 году (SQL:2016).

Основные изменения в новой спецификации:

  • Добавлено расширение SQL/PGQ (Property Graph Queries) для манипуляции наборами связанных между собой данных, образующих граф.
    
       CREATE TABLE person (...);
       CREATE TABLE company (...);
       CREATE TABLE ownerof (...);
       CREATE TABLE transaction (...);
       CREATE TABLE account (...);
    
       CREATE PROPERTY GRAPH financial_transactions
           VERTEX TABLES (person, company, account)
           EDGE TABLES (ownerof, transaction);
    
       SELECT owner_name,
           SUM(amount) AS total_transacted
       FROM financial_transactions GRAPH_TABLE (
         MATCH (p:person WHERE p.name = 'Alice')
            -[:ownerof]-> (:account)
            -[t:transaction]- (:account)
            <-[:ownerof]- (owner:person|company)
         COLUMNS (owner.name AS owner_name, t.amount AS amount)
       ) AS ft
       GROUP BY owner_name;
    
  • Определена возможность настройки поведения обработки значений NULL при наличии ограничителя "UNIQUE". При указании "UNIQUE NULLS DISTINCT", добавляемые в базу значения NULL будут трактоваться как уникальные. Например, в таблице с условием "UNIQUE NULLS DISTINCT (a, b, c)" можно выполнить несколько операций "INSERT INTO t2 VALUES (1, NULL, NULL);", а в таблице с условием "UNIQUE NULLS NOT DISTINCT (a, b, c)" - нет.
  • Расширены возможности выполнение операции "ORDER BY" над сгруппированными таблицами. В спецификации теперь разрешены операции упорядочивания сгруппированных таблиц по столбцу, не упомянутому в списке вывода SELECT сгруппированной таблицы. Ранее большинство СУБД позволяло делать такие манипуляции, но спецификация не определяла подобную возможность. Например:
    
       SELECT product.product_id, sum(product_part.num)
         FROM product JOIN product_part ON product.product_id =  product_part.product_id
         GROUP BY product.product_id
         ORDER BY product.product_code;
    
  • Добавлены новые функции GREATEST и LEAST, выбирающие наибольшее и наименьшее значение из переданного списка. Например:
    
       SELECT greatest(1, 2, 3);  --> 3
       SELECT least(1, 2, 3);     --> 1
       SELECT least(standard, discount) FROM data ...
    
  • Добавлены новые функции LPAD и RPAD для дополнения строки до определённого размера. Например:
    
       SELECT lpad(cast(amount as varchar), 12, '-') FROM ...
    
       ----12345.67
    
  • Добавлены многосимвольные варианты функции TRIM - LTRIM, RTRIM и BTRIM, которые позволяют вырезать из начала или конца строки символы, указанные в списке. По сравнению с TRIM новые функции имеют более простой синтаксис. Например:
    
       SELECT ltrim('cccbtest', 'abc'); --> test
       SELECT trim(leading 'abc' from 'cccbtest'); 
    
  • Для типов "VARCHAR" и "CHARACTER VARYING" разрешено не указывать максимальный размер, в этом случае максимальный размер будет зависеть от реализации СУБД.
    
       CREATE TABLE t1 (
           a VARCHAR(256), 
           b VARCHAR,
           ...
       );
    
  • Расширены возможности по выявлению циклов в рекурсивных запросах, используя выражение "CYCLE". Поле с маркером цикла теперь может иметь тип "boolean", а не строковый, и передавать признак цикла в форме значений true и false. Например:
    
       WITH RECURSIVE ... (
           SELECT ...
             UNION ALL
           SELECT ...
       )
       CYCLE id SET is_cycle USING path;
       -- вместо CYCLE id SET is_cycle TO 'Y' DEFAULT 'N' USING path;
    
  • Добавлена новая агрегатная функция any_value(), которая из входного набора данных возвращает произвольное значение, не являющееся NULL.
    
       CREATE TABLE t1 (
           a int,
           b int
       );
       INSERT INTO t1 VALUES (1, 11), (1, 22), (1, 33);
       SELECT a, any_value(b) FROM t1 GROUP BY a;
    
       в зависимости от вызова вернёт "1 | 11", "1 | 22" или "1 | 33".
    
  • Добавлена возможность указания шестнадцатеричных, двоичных и восьмеричных литералов. Например:
    
       SELECT 0xFFFF, 0o755, 0b11001111 ...
    
  • Разрешено использование в числе символа подчёркивания для повышения наглядности цифровых литералов.
    
       SELECT ... WHERE a > 1_000_000;
       UPDATE ... SET x = 0x_FFFF_FFFF ...
    
  • Значительно расширены возможности, связанные с обработкой данных в формате JSON. Добавлен отдельный тип JSON (в стандарте SQL:2016 данные JSON предписывалось хранить в полях со строковыми типами). В данных с типом JSON можно проверять уникальность, используя "JSON('...text...' WITH UNIQUE KEYS)". Тип JSON также может сравниваться, сортироваться и использоваться в операциях группировки. Предложенные в прошлом стандарте функции JSON_OBJECT, JSON_OBJECTAGG, JSON_TABLE и т.п. могут работать как со старым строковым представлением, так и с отдельными типом JSON.

    Реализована поддержка операций JSON_SERIALIZE, JSON_SCALAR и IS JSON. Предоставлен упрощённый синтаксис доступа к наборами вида '{"foo": {"bar": [100, 200, 300]}, ...}' из SQL ("SELECT t.j.foo.bar[2], ... FROM tbl t ..."). Добавлено 14 новых методов для применения к значениям SQL/JSON внутри языка SQL/JSON.

В СУБД PostgreSQL большая часть предложенных в SQL:2023 новшеств уже доступна или запланирована для включения в следующий значительный выпуск. Поддержка ANY_VALUE, подчёркиваний в числах, шестнадцатеричных/двоичных/восьмеричных литералов и шестнадцатеричных литералов в SQL/JSON появится в осеннем выпуске PostgreSQL. Поддержка расширенных возможностей для типа JSON, упрощённого синтаксиса SQL/JSON, новых JSON-методов и расширения PGQ ожидается в выпусках после PostreSQL 16, но работа в этих областях пока не началась. Остальные новшества SQL:2023 уже доступны в существующих выпусках PostreSQL.

  1. Главная ссылка к новости (https://peter.eisentraut.org/b...)
  2. OpenNews: Релиз языка для формирования структурированных запросов HTSQL 2.0
  3. OpenNews: Проект libSQL начал развитие форка СУБД SQLite
  4. OpenNews: Релиз СУБД PostgreSQL 15
  5. OpenNews: Facebook представил новый язык формирования запросов GraphQL
  6. OpenNews: Facebook сменил лицензию на GraphQL и выпустил React 16
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/59239-sql
Ключевые слова: sql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (64) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.3, Аноним (3), 16:21, 03/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    SQL -- это манястандарт. Стандарт де-факто -- это документация реализаций. Вот ее и надо читать.
     
     
  • 2.4, Аноним (4), 16:26, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Примерно как с сишечкой - угадай скомпилится оно на другом компиляторе, а если скомпилится - будет ли работать также.
     
     
  • 3.24, Аноним (24), 20:28, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    У сишечки по крайней мере есть из чего выбрать.
     
     
  • 4.29, Аноним (4), 21:31, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • –7 +/
    Очень жаль что выбор из сортов вы считаете выбором и радуетесь ему))
     
     
  • 5.48, FF (?), 02:59, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    другое дело когда единственное и то не допилили
     
     
  • 6.58, Аноним (58), 13:08, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ой тут бы старые стандарты доучить + популярные спец. выражения базы, которую использую, в голове места не осталось
     
  • 3.49, FF (?), 03:00, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    в кривых руках только жабаскрип или просто жаба, даже до раста подпускать нельзя
     
     
  • 4.54, Golangdev (?), 06:33, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Но-но-но!

    Java, SQL и XML это столпы развития ИТ-индустрии (в нулевые, а в заскорузлых банках и сейчас), попрошу не гнать!)

     
     
  • 5.59, Аноним (58), 13:10, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    внезапно поведение java отличается на разных jvm, хоть и не сильно, а поведение js отличается в браузерах (включая скорость работы), а на js вообще писать не нужно, только TypeScript
     
  • 2.15, Аноним (15), 17:46, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как полный нуб в SQL с этим столнулся. Читаешь введение в SQL, всё красиво и логично, пытаешься просто скопипастить пример с CREATE FUNCTION - и внезапно ни в одной реальной СУБД это не работает. Везде свои костыли и колдунство, ни одна не реализует стандарт.
     
     
  • 3.19, 1 (??), 18:32, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А зачем FUNCTION в запросах? это стандарт выборки или обработки, то что всякие ораклы реализуют всю логику на sql вовсе не значит что это правильно, они и на брейфаке реализуют если будет возможность продать, только на нем никто не купит, а купить продукт написанный на одном sql это ведь так соблазнительно, не надо заморачиваться с чем-то еще, только потом локти кусают, и прикручивают всякие костыли, чтобы интегрироваться с чем-то еще.
     
     
  • 4.20, Прохожий (??), 18:51, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >А зачем FUNCTION в запросах?

    Потому что это очень удобно для сложных запросов.

     
     
  • 5.50, FF (?), 03:01, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Молодцы, ребята, не отличаете DML от DDL
     
     
  • 6.63, Neon (??), 05:00, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Т.е. создатели конкретных БД тоже не различают ?
     
  • 4.51, FF (?), 03:02, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    самобытность оракла идет потому, что там фичи многие еще до появления их в стандарте были
     
  • 4.69, BorichL (ok), 15:06, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем функциональное программирование?  Если логика работы с базой чуть сложнее, чем select * from TABLE1, то без функций там делать нечего.
     
     
  • 5.81, Аноним (81), 13:07, 15/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    интересно, узнал ли BorichL уже что функциональное программирование это не когда ты функции в SQL определяешь чтоб там логику императивно запилить?
     
  • 3.42, Тот_ещё_аноним (ok), 00:00, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Каждая субд реализует свой стандарт
    Не лучше или хуже - просто свой

    Чтоб не соскочили)

     
  • 3.68, anonymous (??), 10:44, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Справедливости ради, постгря реализует ближе всего к стандарту.
     
  • 3.80, mos87 (ok), 12:00, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    жырно.
     
  • 2.23, Аноним (23), 20:07, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Стандарт нужен, чтобы маняреализации не слишком расходились между собой.
     

  • 1.5, Аноним (5), 16:33, 03/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –13 +/
    Что эта проприетарщина делает на опеннете?
     
     
  • 2.6, Анонимусс (?), 16:56, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > ISO/IEC 9075

    А чем оно принципиально отличается от ISO/IEC 9899:2018 или ISO/IEC 14882:2020?
    Оно тоже проприетарщиана или нет?

     
     
  • 3.47, Аноним (5), 02:01, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А кто сказал, что оно отличается?
    Свободно читать и распространять нельзя - значит проприетарщина.
     
  • 2.11, Аноним (11), 17:32, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +16 +/
    А что ты тут делаешь? Как ты вырвался от санитаров?
     

  • 1.8, Аноним (8), 17:14, 03/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Это круто, сейчас как раз пишеться прокси через sql через вк
     
     
  • 2.13, Аноним (8), 17:38, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А чтобы прикрыть такой прокси нужны будут космические ресурсы - тоесть это невозможно
     
     
  • 3.36, Аноним (36), 22:09, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    главное бюджет. если очень захотеть можно в космос полететь
     
  • 2.76, жявамэн (ok), 16:40, 06/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    что за чушь я прочитал?
     

  • 1.9, Аноним (9), 17:18, 03/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Property Graph Queries

    Годно. Посмотрим как это будет в реализациях работать, конечно же, но может хоть не придётся для простых небольших графов отдельную БД поднимать.

     
  • 1.10, Аноним (11), 17:32, 03/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Наконец-то нормальный стандарт.
     
     
  • 2.17, А (??), 17:57, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Стандарт-то может и нормальный, но всем наплевать на него. Главное, реализация в конкретной СУБД.
     
     
  • 3.22, Аноним (23), 20:06, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Стандарт позволяет поумерить творческую энергию создателей конкретных СУБД.
     
     
  • 4.43, Тот_ещё_аноним (ok), 00:01, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как? Их накажут, да?
     
  • 4.53, FF (?), 03:05, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    особенно когда создатели создали конкретные СУБД до рождения половины самых осведомленных и опытных анонимов и создания стандарта тоже
     
  • 3.25, Аноним (11), 20:30, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Это в NoSQL даже стандарта нет и там треш трешовый.
     
     
  • 4.52, FF (?), 03:04, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    что там стандартизировать? избыточные агрегаты JSON в качестве значений?
     
  • 2.64, Аноним (64), 07:31, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    эт вражеский стандарт
    нужен ГОСТ.
     

  • 1.18, Аноним (18), 18:04, 03/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Звучит как "опубликован новый стандарт латыни, наконец-то все проблемы коммуникации среди граждан Римской Империи будут решены".
     
     
  • 2.26, Аноним (11), 20:31, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее новая версия Эсперанто и скоро все люди не шаре будут говорить на одном языке.
     

  • 1.27, X (?), 20:37, 03/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Расширены возможности выполнение операции "ORDER BY"

    Ну не может постгря такое, почему, написано, что есть то?

     
     
  • 2.65, Брат Анон (ok), 08:13, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты понимаешь разницу между стандартом и реализацией стандарта?
    Ты понимаешь, что этот стандарт только утверждён и пока ни одна РСУБД на планете его не поддерживает?
     

  • 1.28, Аноним (28), 20:47, 03/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не хватает функций для частичного обновления поля. Например если я хочу одним запросом обновить содержимое поля с n по n+m байта, или если ключа нет, вставить данные с n по n+m байт, а остальное занулить, такого нет.
     
     
  • 2.31, www2 (??), 21:50, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не хватает возможности массового обновления разных полей во сножестве строк - приходится либо много строк обновлять одинаково, либо все по-разному, но только по одной :D
     
     
  • 3.35, Tron is Whistling (?), 22:03, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Давно IF и CASE отменили?
     

  • 1.34, Tron is Whistling (?), 22:02, 03/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    С графами что-то заложить давно напрашивалось, но получившийся синтаксис реально удолбищный и вырвиглазный.
     
     
  • 2.37, Аноним (37), 22:13, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И что там напрашивалось?! Если тебе нужны графы, то используй графовую бд, а не клюй всем моск.
     
     
  • 3.38, Tron is Whistling (?), 22:22, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    У поколения лефтпада построить граф на реляционке уже рокет сайнс?
     
     
  • 4.44, Аноним (9), 01:16, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Бегать по графу на SQL — чистой воды мазохизм, где даже примитивный запрос легко превращается в пару страниц SQL. Нет, конечно же это не рокет сайнс, всё можно. Но потом обслуживать это тяжело, новых людей в проект вводить тяжело, любые изменения даются лишним трудом. Поэтому проще и дешевле поднять рядом специализированную БД и общаться с ней. Для больших проектов придётся это делать в любом случае, а вот для небольших эти операционные накладные расходы немного жмут. А то, что тебе синтаксис показался не таким, так это от того, что опыта работы с такими системами у тебя нет, и проблематику ты если и представляешь, то в лучшем случае по картинкам из учебника. Так что, Вася, ты бы мел поупырил.
     
     
  • 5.55, Tron is Whistling (?), 10:00, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну я и говорю - рокет сайнс. На деле-то примитивная операция, не требующая специализированных БД, под каждую из которых надо отдельного DBA.
     
     
  • 6.67, User (??), 09:12, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да и вообще эти ваши "бд" с DBA странная какая-то понь-цепция - что нельзя было простыми регулярками по текстовому файлу обойтись? Ох уж это новое поколение, все им "рокет сайнс"...
     
     
  • 7.70, Tron is Whistling (?), 15:49, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    В ряде случаев регулярки по исходнику будут гораздо быстрее, чем сложить исходник в RDBMS и тягать оттуда.
    Особенно когда исходник надо раз-два обработать, или он специфично RDBMS-не-кантуемый.
    Поверь мне, в этом случае я RDBMS тянуть не буду.
    Но у поколения смузи по ходу две крайности.
     
     
  • 8.72, User (??), 21:57, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот и тут так же - один-два запроса можно и на рСУБД сделать, но если в проек... текст свёрнут, показать
     
     
  • 9.73, Tron is Whistling (?), 08:24, 06/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот у меня тот случай, когда графы обходить нужно, но лепить для этого какую-... текст свёрнут, показать
     
  • 9.74, Tron is Whistling (?), 08:26, 06/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Тем более, что для обхода достаточно просто рекурсивного запроса ... текст свёрнут, показать
     
     
  • 10.75, User (??), 13:53, 06/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот в postgresql для подобных применений можно использовать ltree - edgedb ap... текст свёрнут, показать
     
  • 5.56, Tron is Whistling (?), 10:10, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А синтаксис говно, потому что к нему пустили растОманов.
     
     
  • 6.57, Карлос Сношайтилис (ok), 11:04, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Расскажи, как злые рестомане тебя обижают и унижают, покажи на алфавите, какими буквами сделали тебе больно
     
  • 2.62, edo (ok), 23:13, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Незапоминаемые закорючки в стандарт sql ещё с json пришли (((
     

  • 1.66, nc (ok), 08:39, 05/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    какой смысл в этих стандартах, если все равно каждая СУБД использует свой диалект?
     
     
  • 2.71, Аноним (71), 20:40, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Иллюзия контроля во все поля. Некоторым трудно признать, что есть несколько конкурирующих диалектов созданых в рамках работы над реальными проектами. Надо непременно один стандарт включающий все на свете, чтобы их не изучать. Такая попытка унифицировать буйство рельного мира.
     

  • 1.77, Аноним (77), 23:42, 06/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    SQL хорош для своих лет - в смысле для 197* годов. Сегодня системы стали настолько сложными и такие сложные данные внутри (напр JSON), что SQL с его у6людcким, неуклюжим синтаксисом и возможностями отстал на те же 50 лет.

    Миру нужны новые возможности или хотя бы вразумительный доступ к данным. Например, в стиле FoxPro - когда программист сам ходит по таблице, запрашивает подчинённые записи, агрегирует поля и т.п. Скажем, нет ничего проще, чем пройтись по таблице, собрав и по-недельные суммы и помесячные ЗА ОДИН ПРОХОД, попутно сосчитав баланс отрицательных чисел. Мы 100% придём к такой технологии, но не сейчас - слишком заскорузлые мозги у нынешних "профи".

     
     
  • 2.79, Россия_тюрьма_свободы_нет (?), 13:16, 09/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем?
    Ваш текст все равно планом будет преобразован.
    В конце концов powerBi или другая херовина пишет запросы, или клиенты фильтры в ui выбирают
     
     
  • 3.82, Аноним (82), 07:10, 06/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ты не понял. Вместо формулировки "что я хочу" на неуклюжем SQL, я буду "алгоритмически" писать, что мне нужно от таблиц. Потому что даже в простых системах есть неординарные запросы, которые легче сказать, чем написать (особенно с агрегированием, сортировкой и т.п.). SQL потому и сложен, что он ДЕКЛАРАТИВНЫЙ (что ещё раз подчёркивает его неуклюжесть для использования "императивным мозгом").
    Поэтому старый подход а-ля FoxPro вполне может быть востребован, заодно сильно упрощая жизнь разрабам.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру