V.92: уже стандарт?

18.03.2001 Михаил Глинников

Получая очередной пресс-релиз, вижу — приняты новые стандарты модемов: V.92 и V.44. И сразу, естественно, возникают вопросы.

Обеспечат ли они, как обещается, качество широкополосного доступа по цене коммутируемого соединения нам, конечным пользователям? В какой мере мы сможем ими воспользоваться здесь, в России? Будут ли готовы наши сервис-провайдеры их поддержать и если да, то когда это произойдет? Ведь основная конкурентная борьба в этой сфере разворачивается именно за спектр и качество предоставляемых услуг.

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

Но сначала — немного о самих стандартах.

Cтандарт V.44

Этот стандарт обеспечивает более эффективное сжатие данных. Он заменяет собой протокол V.42 bis, ориентированный в основном на тексты ASCII, и разработан уже с учетом работы с Web-страницами, HTML и прочей «специфики», характерной для Internet.

Как считают специалисты, при использовании стандартных сайтов типа amazon.com протокол V.44 повышает производительность примерно в два раза. Для Web-страниц выигрыш в скорости может быть еще больше.

Здесь, по оценкам Cisco Systems, эффективная скорость передачи при Web-серфинге превыcит 100 кбит/c в направлении к клиенту (down stream — нисходящий поток).

Конечно, это еще не широкополосный доступ, но некоторое приближение к нему с точки зрения производительности.

Насколько возрастет благодаря новому стандарту эффективность работы с Сетью? Это зависит от массы факторов, и прежде всего — от качества самих телефонных линий. Но все-таки об «обеспечении качества широкополосного доступа по цене коммутируемого», пожалуй, говорить пока рано. Широкополосный доступ, и большинство cпециалистов в этом мнении сходятся, начинается как минимум со 128 кбит/c.

Стандарт V.92

Первая новая функция, реализованная в стандарте V.

92, Modem on Hold, как отмечается в пресс-релизе, «даст пользователю возможность отвечать на входящие телефонные звонки без обрыва соединения с Internet».

На самом деле чудес не бывает, и разрыв, несомненно, произойдет. Правда, потом восстановить связь удастся значительно быстрее за счет второй новой функции — Quick Connect. Но обо всем по порядку.

Действительно, функция Modem on Hold выглядит весьма привлекательно. Ведь, согласитесь, мы часто оказываемся в такой ситуации, когда, перекачивая большой файл из Internet, можем пропустить какой-нибудь важный входящий звонок.

К некоторым моим знакомым теперь вечером вообще стало невозможно дозвониться. И я уверен, что мой случай не уникален. Или другой вариант — допустим, вы уже полчаса переписываете объемный файл, а жене потребовалось срочно позвонить.

Что делать? Как сохранить мир в семье? Вот здесь-то функция Modem on Hold и приходит на помощь. Но… отнюдь не всем и далеко не всегда.

Какова роль функции Modem on Hold? Фактически это попытка стандартизовать технологию Internet Call Waiting, для работы которой требуется наличие соответствующим образом запрограммированных цифровых станций. Однако если учесть, что в Москве две трети аналоговых телефонных станций, такой сервис большинству пользователей Internet пока будет просто недоступен.

Представьте, что вы работаете в Internet, а приятель пытается к вам дозвониться. Обе станции, между которыми происходит соединение, — аналоговые.

Ваша станция, ни о чем не подозревая, обнаруживает, что линия занята и посылает сообщение об этом обратно, т. е. туда, откуда пришел вызов.

И та аналоговая станция, не имея никакого интерфейса с сервером доступа вашего Internet-провайдера, естественно, выдает абоненту сигнал «занято». В результате приятель слышит в трубке привычные короткие гудки.

Функция Modem on Hold может представлять интерес только для абонентов коммерческой телефонии, которые напрямую подключены к цифровым станциям операторов.

Скорее всего, этой услугой смогут воспользоваться жители вновь построенных элитных кварталов в Москве и ближнем Подмосковье.

Если эти счастливчики будут обслуживаться не МГТС, а кем-нибудь из коммерческих операторов, то такая технология вполне может быть здесь реализована.

Для этого нужно, чтобы последняя телефонная станция по «дороге к ним» была цифровой и чтобы к ней был подключен сервер доступа, на котором установлено соответствующее ПО.

Тогда, получив в ответ сигнал «занято», цифровая телефонная станция не отошлет его назад, а запросит служебный сервер о состоянии линии.

Если окажется, что в данный момент на ней работает зарегистрированный пользователь Internet, станция выдаст ему сообщение о том, что поступил вызов, и предложит на выбор — принять этот вызов или продолжить работу.

Разумеется, если пользователь решит ответить на вызов и снимет трубку, то соединение нарушится. Но одним из преимуществ технологии V.92 является наличие функции Quick Connect, о которой шла речь выше. Благодаря ей модем запоминает состояние линии в момент последнего звонка.

Поэтому когда пользователь закончит разговор и положит трубку, соединение восстановится гораздо быстрее за счет того, что Quick Connect значительно сократит время согласования параметров между модемами. Абонентский и провайдерский модемы в такой ситуации «договорятся» скорее раза в полтора-два.

Однако не думайте, что можно, начав переписывать большой файл, отвлечься и поболтать с приятелем минут десять, а потом продолжить процесс «с места прерывания» как ни в чем не бывало — это исключено.

Аналоговые модемы — что дальше

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

Несмотря на появление технологий высокоскоростного доступа, согласно прогнозам на 2004 г.

все равно свыше 60% пользователей в мире будут работать с Internet по аналоговым модемам, 7% — по кабельным, 24% — по модемам HDSL и остальные 9% перейдут в основном на беспроводной доступ.

Ну а в России, по примерным оценкам специалистов, около 98% пользователей Internet имеют коммутируемый доступ и работают с аналоговыми модемами.

К тому же у нас, в отличие от США и стран Западной Европы, рынок тех, кто потенциально ориентирован на коммутируемый доступ, еще далеко «не выбран».

Поэтому независимо от того, будут ли применяться модемы с этими новыми стандартами или нет, количество желающих воспользоваться обычным телефоном для работы в Internet наверняка возрастет.

Очевидно, что с увеличением числа цифровых АТС будет расти и число тех, кто сможет задействовать функцию Modem on Hold. Кстати, в некоторых регионах этот процесс пойдет даже быстрее, чем в Москве. Так, C.-Петербург и ряд других городов по соотношению цифровых и аналоговых АТС уже опережают столицу.

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

Ведь даже в США из 60 млн. зарегистрированных пользователей Сети высокоскоростной доступ имеют лишь 4,5 млн. человек.

Как воспользоваться новыми стандартами

Естественно, сервис-провайдеры должны, прежде всего, иметь у себя серверы доступа с цифровыми модемами, которые поддерживали бы работу с этими стандартами. И ведущие производители сетевого оборудования для Internet-провайдеров уже объявили о поддержке новых протоколов в своем оборудовании.

Так, для довольно хорошо известных в нашей стране cерверов удаленного доступа AS 5300 и AS 5800 компания Сisco Systems примерно в апреле-мае 2001 г. планирует выпустить специальную «прошивку» (модемный микрокод), и сервис-провайдеры, у которых установлено соответствующее оборудование, смогут ею воспользоваться.

А относительно недавно анонсированные серверы этой компании AS 5350 и AS 5400 будут работать с модемами V.92 и V.44. уже в марте. Модель AS 5350 приходит на смену AS 5200. Она позволяет одновременно обрабатывать 60 модемных соединений, а AS 5400 — до 648 таких соединений.

При необходимости обе модели могут выполнять также функции межсетевого экрана, осуществлять построение виртуальных частных сетей и обеспечивать требуемое качество сервисов.

Начало же массовых поставок модемов V.92 и V.44 на наш пользовательский рынок следует ожидать в первом-втором квартале нынешнего года.

Вероятнее всего для оборудования известных производителей типа US Robotics Courier можно будет реализовать поддержку этих стандартов просто путем обновления микрокода.

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

Таким образом, если вы хотите воспользоваться новыми возможностями, начните с того, что узнайте у вашего провайдера, работает ли он со стандартами V.92 и V.44.

Эту информацию можно получить, заглянув на его страницу или просто позвонив в службу поддержки.

Имейте в виду, что у сервис-провайдера может быть несколько пулов (телефонных номеров), на которых предусмотрены разные наборы стандартов.

Затем зайдите на сайт производителя вашего модема и попробуйте выяснить, будет ли выпущен соответствующий микрокод. Если это не планируется, а вам крайне необходимо повысить эффективность работы, что ж, купите модем V.92 или V.44. Но учтите, что первые модели таких модемов будут стоить несколько дороже, как это было в свое время со стандартом V.90.

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

В принципе появление этих новых стандартов — еще одна попытка выжать максимум возможного из модемной технологии. Это, конечно, не революционный шаг, а скорее эволюционный, но тем не менее весьма своевременный, поскольку информация в Internet становится все более многоообразной и ее объемы, передаваемые пользователями по коммутируемым линиям связи, постоянно растут.

ОБ АВТОРЕ

Михаил Глинников — научный редактор журнала «Мир ПК». Контактный тел.: (095) 253-92-27.

Новые стандарты модемов: ожидания и реальность

Стандарты языка SQL

Аннотация: В лекции обсуждаются вопросы стандартизации языка SQL.

Язык SQL предназначен для доступа к информации и управления реляционной базой данных. Управление различными реляционными базами данных осуществляют программы, называемые СУБД — системы управления базами данных (DBMS — DataBase Management System).

Сама реляционная база данных представляет собой хранилище определенным образом организованной информации и СУБД. Однако на практике термин СУБД часто заменяют термином БД (База Данных).

Для того чтобы c различными базами данных — такими как Oracle, Microsoft SQL Server, Informix, DB2, Access, MySQL — можно было общаться на одном языке, был разработан язык SQL.

Начиная с 1986 года, комитеты ISO (International Organization for Standardization) и ANSI (American National Standards Institute) приступили к созданию ряда стандартов языка SQL, которые впоследствии были приняты и получили следующие названия: SQL86, SQL89, SQL92 и SQL99.

Стандарт SQL86 зафиксировал минимальный стандартный синтаксис языка SQL.

Стандарт SQL89 был принят в 1989 году. Он вводил набор операторов языка SQL, которые должны были реализовывать все СУБД, заявляющие поддержку стандарта SQL89.

На практике каждая реальная коммерческая СУБД предоставляет значительно более широкий набор возможностей, чем предусмотрено стандартом.

Так, несмотря на то, что большинство СУБД на момент принятия стандарта уже поддерживали встроенный и динамический SQL, в стандарте SQL89 правила встраивания языка SQL в процедурный язык программирования (такой как язык С) и правила использования динамического SQL прописаны не были.

До последнего времени большинство СУБД поддерживали стандарт SQL92.

В стандарте SQL92 было определено три уровня соответствия:

основной (Entry) ;
средний (Intermediate) ;
полный (Full).

При этом, для того чтобы объявить СУБД поддерживающей стандарт SQL92, большинство производителей реализовывали только основной уровень соответствия.

Новый стандарт SQL99, при разработке именовавшийся как SQL3, стандартизировал объектные расширения языка SQL и некоторые процедурные расширения языка SQL. К моменту принятия этого стандарта большинство коммерческих СУБД, таких как Oracle, уже де-факто ввели использование объектных типов и наследования.

В стандарте SQL99 определено обязательное функциональное ядро (Core) и набор уровней расширенного соответствия. Функциональное ядро SQL99 включает в себя основной уровень соответствия SQL92.

Уровни расширенного соответствия не являются обязательными для реализации в СУБД, претендующей на поддержку стандарта SQL99.

СУБД может не поддерживать ни одного уровня расширенного соответствия или поддерживать любые из них.

Каждый уровень описывает набор возможностей языка SQL, которые должны поддерживать реализации СУБД, претендующие на данный уровень соответствия.
При этом объявлено, что стандарт SQL99 является открытым для всех последующих уровней расширенного соответствия, которые могут появиться в дальнейшем.
В настоящий момент стандарт SQL99 содержит следующие уровни соответствия:

Функциональное ядро.Данный уровень является обязательным для любой реализации СУБД. Он включает в себя основной уровень соответствия SQL92, а также поддержку работы с LOB-объектами (Large Object), вызов из SQL внешних программ, написанных на других языках программирования, и простые типы данных, определяемые пользователем (UDT-типы, User-Defined Datatypes). Вводится поддержка LOB-объектов двух типов: бинарных BLOB-объектов (Binary Large Object) и символьных CLOB-объектов (Character Large Object). Для доступа к LOB-объектам вводятся объекты, называемые локаторами. Локаторы описываются целочисленными переменными, реализующими доступ к LOB-объекту по ссылке. Внешние программы определяются как объекты схемы, так же, как и таблицы. В зависимости от реализации сам код внешней программы может находиться в DLL-библиотеке или в произвольном файле, а внешняя программа создается оператором языка CREATE PROCEDURE или CREATE FUNCTION с обязательным указанием фраз LANGUAGE и EXTERNAL. Следует отметить, что хотя использование внешних программ входит в функциональное ядро, но поддержка вызова процедур и функций SQL относится к расширенному уровню соответствия » PSM -модули» (Persistent Stored Module). Определяемые пользователем типы данных могут быть простыми и структурированными. Второй случай относится к уровню соответствия «Базовая поддержка объектов». Простой тип данных, определяемый пользователем — это существующий тип данных, для которого определено новое имя и возможно некоторое ограничение по количеству символов или цифр. Простой тип данных, определяемый пользователем, создается оператором CREATE TYPE (например, CREATE TYPE name_of_new_type AS INTEGER (5) FINAL; ).
Поддержка работы с датой/временем.Этот уровень соответствия вводит типы данных DATETIME и INTERVAL, а для типа DATETIME вводит поля TIMEZONE_HOUR и TIMEZONE_MINUTE, определяющие смещение для зонального времени относительно универсального времени. В стандарте SQL92 полного уровня соответствия типы данных DATETIME и INTERVAL уже были специфицированы.
Управление целостностью.Этот уровень соответствия вводит поддержку дополнительных возможностей ссылочной целостности: подзапросы в ограничениях целостности CHECK оператора CREATE TABLE, триггеры, утверждения, создаваемые оператором CREATE ASSERTION. Большинство из этих возможностей входило в стандарт SQL92.
Активные базы данных.На этом уровне соответствия определяется поддержка триггеров базы данных, хранимых в базе данных и выполняемых. Триггеры представляют собой фрагменты кода, выполняемые перед или после указанного изменения данных (такого как вставка строки, удаление или изменение строки).
OLAP.Этот уровень соответствия определяет средства описания более сложных запросов. Так, в оператор SELECT включена фраза INTERSECT, позволяющая получать пересечения множеств, выданных несколькими запросами. В стандарте SQL92 эта возможность прописывалась только для полного уровня соответствия. В оператор SELECT включена фраза FULL OUTER JOIN, предназначенная для создания полных внешних соединений таблиц. Такое соединение будет содержать все строки из объединяемых таблиц, в которых при отсутствии совпадений проставляются NULL-значения. Подобная возможность была предусмотрена и в полном уровне соответствия стандарта SQL92. В операторах языка SQL, применяемых для манипулирования данными, определяется поддержка использования конструкторов значений строк и таблиц. Конструкторы значений строк состоят из одного или нескольких выражений (например, (NULL,1,'Field1') ). Конструкторы значений таблиц представляют собой набор значений конструкторов строк, описывающий группу строк (например, VALUES (1,'A'), (2,'B') ).
PSM-модули.Этот уровень соответствия полностью описан в документе SQL/PSM стандарта SQL99. Так, язык SQL расширяется операторами управления CASE, IF, WHILE, REPEAT, LOOP и FOR. Вводится поддержка процедур и функций, создаваемых операторами CREATE PROCEDURE и CREATE FUNCTION. В язык SQL введено использование переменных и применение обработчиков ошибок.
CLI-интерфейс.Этот уровень соответствия вводит поддержку интерфейса уровня вызова, определяющего вызов операторов SQL. В свое время на базе CLI -интерфейса был разработан стандарт ODBC, который более подробно будет рассматриваться в последующих лекциях.
Базовая поддержка объектов (Basic Object Support).Этот уровень соответствия стандартизирует использование объектов, вводя поддержку объектных типов данных, определяемых пользователем, применение типизированных таблиц (таблиц на базе объектных типов), использование массивов и ссылочных типов данных, а также переопределение внешних процедур.
Расширенная поддержка объектов (Enhanced Object Support).Этот уровень соответствия включает все возможности, предоставляемые уровнем базовой поддержки объектов, дополняя их поддержкой множественного наследования для типов данных, определяемых пользователем.

Представленные выше уровни расширенного соответствия напрямую не связаны с документами, соответствующими разделам стандарта. В настоящее время стандарт SQL99 содержит следующие основные разделы:

SQLFramework — описывает логические основы стандарта.
SQLFoundation — определяет содержание каждого раздела стандарта и описывает функциональное ядро стандарта (Core SQL99 ).
SQL/CLI — описывает интерфейс уровня вызова.
SQL/PSM — определяет процедурные расширения языка SQL.
SQL/Bindings — определяет механизм взаимодействия языка SQL с другими языками программирования.
SQL/MM — описываются средства языка SQL, предназначенные для работы с мультимедийными данными.
SQL/OLB — определяет связь SQL с объектными языками, описывая 0-часть стандарта SQLJ для встраивания операторов SQL в язык Java.

Особенности стандартов V.34, V.90 и V.92

Cтандарт
V.34 имеет длинное название, в переводе
имеющее следующий вид: «Модем,
обеспечивающий передачу данных со
скоростями до 28800 (33600) бит/с для
использования на коммутируемой сети
общего пользования и на двухточечных
двухпроводных выделенных каналах
телефонного типа».

Таким образом, этот
стандарт ориентирован на применение в
наиболее распространенных типах
телефонных линий. Стандарт V.34 имеет две
«версии» или редакции – в первой редакции
стандарта от 1994 г. предусматривалась
скорость передачи не выше 28800 бит/с, во
второй от 1998 г. этот предел был увеличен
до 33600 бит/с.

Кроме перечисленных ранее,
этот стандарт имеет ряд других
принципиальных особенностей:

более полное использование полосы пропускания телефонной линии. Из шести предусмотренных стандартом V.34 символьных скоростей передачи две наибольшие (3200 и 3429 символов/с) требуют ширины полосы пропускания линии превышающей стандартное значение 3100 Гц, но достижимой для ряда реальных телефонных линий;
введение в передаваемый сигнал наряду с линейными нелинейных предискажений для частичной компенсации нелинейных искажений, вносимых аппаратурой с импульсно-кодовой модуляцией (ИКМ), работающей на линии. На комплексной плоскости такие предыскажения выглядят в виде неравномерного (отличающегося от строго решетчатого) расположения сигнальных точек;
развитый сервис, включающий возможность организации асимметричной передачи (разные скорости, несущие частоты, число точек на комплексной плоскости и другие режимы работы для модемов на противоположных концах линии), полудуплексного обмена (эхокомпенсация не используется) и дополнительного канала;
автоматический адаптивный выбор режимов работы модемов в соответствии с параметрами реальной телефонной линии. Для этого модемы попеременно передают друг другу последовательность из 21 гармонических колебаний с частотами в диапазоне от 150 до 3750 Гц, определяют возможные режимы работы и обмениваются информацией о них. Настройка скорости работы модемов в соответствии с качеством связи (отношением сигнал-шум) означает, что фактически скорость может уменьшаться с шагом 2400 бит/с и в случае отношения сигнал-шум менее 20 дБ (реальная цифра для некоторых отечественных телефонных линий, особенно при междугородней связи) окажется не более 9600 бит/с. Связь ряда достижимых значений скоростей передачи с отношением сигнал-шум для стандарта V.34 показана на рис. 17.2.

Как
следует из анализа особенностей стандарта
V.34, он практически полностью использует
возможности, предоставляемые стандартными
аналоговыми телефонными линиями.
Дальнейший рост скорости передачи по
линии возможен только при использовании
линий с большей полосой пропускания,
что и предусмотрено в стандарте V.

90 для
модемов со скоростью передачи до 56
Кбит/с, часто обозначаемых как V.90- или
56К–модемы. Стандарт V.90 на 56К–модемы
утвержден ITU-T в сентябре 1998 г. На рис.
18.8приведена иллюстрация
принципа работы обычных (со скоростью
передачи до 33600 бит/с на основе стандарта
V.34) и 56К(V.90)–модемов в телефонной сети
общего пользования.

Несмотря на то, что
большая часть сети цифровая, при работе
на обоих концах линии модемы, соответствующие
протоколу V.34, применяют ее как полностью
аналоговую. Это означает необходимость
использования аналого-цифровых
преобразователей (АЦП) при передаче
сигналов в обоих направлениях.

В
результате дискретизации сигналов по
амплитуде АЦП вносят заметный вклад в
ухудшение отношения сигнал-шум и скорость
передачи в обоих направлениях одинакова
(при самых благоприятных условиях до
33600 бит/c). Однако если на одном из концов
линии (у провайдера) использовать
специальный цифровой V.

90-модем, подключенный
непосредственно к цифровой части
телефонной сети, а на другом конце (у
клиента) аналоговый V.90-модем, то в
направлении от провайдера к пользователю
АЦП отсутствует и скорость (теоретически)
может быть увеличена до 56Кбит/c.

Сама по
себе цифровая телефонная сеть имеет
скорость передачи 64 Кбит/с, однако
наличие дополнительных искажений и
шумов от работы ЦАП и АТС, хотя и меньших
по уровню, чем шум дискретизации АЦП,
ограничивает достижимую скорость
передачи. Кроме того, тестирование
56К-модемов показывает возможность
достижения скорости в диапазоне 40…50
Кбит/с при связи с местной телефонной
станцией и 28…33 Кбит/с при работе на
международных линиях.

Рис.
18.8.Иллюстрация принципа работы
обычных и 56К(V.90)–модемов

Таким
образом, достижение скорости передачи
33,6 Кбит/с и, тем более, 56 Кбит/с требует
выполнения целого ряда условий. В первую
очередь сама по себе телефонная линия
со всем оборудованием, которое используется
для преобразования сигналов и коммутации
каналов, должна быть достаточно
качественной, с наименьшим количеством
вносимых искажений сигналов.

Для
работы со скоростью 56 Кбит/с, необходимо
выполнение дополнительных трех условий:

Цифровое подключение на одном из концов (со стороны провайдера).
Поддержка стандарта V.90 на обоих концах. Стандарт V.90 должен поддерживаться на обоих концах соединения: как аналоговым модемом пользователя, так и сервером удаленного доступа или модемным пулом на стороне хост-компьютера. Переход к стандарту V.90 не означает обязательного приобретения нового модема, так как некоторые из них допускают сугубо программный «upgrade».
Одно аналого-цифровое преобразование. На пути следования сигнала между цифровым модемом V.90 и аналоговым модемом может быть только одно аналого-цифровое преобразование.

В
июне 2000 г. обнародована серия новых
протоколов V.92, V.44 и V.59. Протокол V.92
является развитием протокола V.90 по
части выравнивания скоростей передачи
в обоих направлениях обмена. Максимальная
исходящая скорость от пользователя
увеличена с 33,6 (V.90) до 48 Кбит/с. Это
достигается за счет изменения способа
кодирования информации (ИКМ).

Исходящая
от пользователя информация может
передаваться со скоростями от 24 до 48
Кбит/с с шагом 1,333 Кбит/с как и в протоколе
V.90. Кроме того, уменьшается время
вхождения в связь с 20 (V.90) до 10 с (более
быстрое соединение – Quick Connect). Второй
протокол V.44 позволяет увеличить степень
сжатия передаваемых данных как 6:1, то
есть на 25% в сравнении с V.

42bis, который
обеспечивал сжатие 4:1. Производительность
(информационная скорость передачи)
может увеличиться до 300 Кбит/с. И, наконец,
третий протокол V.59 вводит такую услугу,
как возможность прерывания передачи
данных на время от 0 до 16 минут и ответ
входящему вызову. Для реализации
сервисов, предоставляемых стандартом
V.

92, необходимо выполнение таких же
условий, как и для стандарта V.90.

Почему стандарт SQL ANSI-92 не лучше принят по сравнению с ANSI-89?

в каждой компании, в которой я работал, я обнаружил, что люди все еще пишут свои SQL-запросы в стандарте ANSI-89:

select a.id, b.id, b.address_1
from person a, address b
where a.id = b.id

вместо стандарта ANSI-92:

select a.id, b.id, b.address_1
from person a
inner join address b
on a.id = b.id

для чрезвычайно простого запроса, подобного этому, нет большой разницы в удобочитаемости, но для больших запросов я нахожу, что мои критерии объединения сгруппированы с перечислением таблицы, что значительно упрощает просмотр, где у меня могут быть проблемы в моем соединении, и давайте я сохраню все мои фильтрация в моем предложении WHERE. Не говоря уже о том, что я чувствую, что внешние соединения намного интуитивно понятны, чем синтаксис (+) в Oracle.

когда я пытаюсь проповедовать ANSI-92 людям, есть ли какие-либо конкретные преимущества в использовании ANSI-92 над ANSI-89? Я бы попробовал это самостоятельно, но настройки Oracle, которые мы имеем здесь, не позволяют нам использовать EXPLAIN PLAN — не хотели бы, чтобы люди пытались оптимизировать свой код, не так ли?

ansi-92 ansi-sql join sql

Я также пытаюсь евангелизировать синтаксис SQL-92. Шестнадцать лет спустя одобрено, это о времени люди начинают использовать его! И все бренды базы данных SQL теперь поддерживают его, поэтому нет причин продолжать использовать отвратительный (+) синтаксис Oracle или *= синтаксис Microsoft/Sybase.

Я постепенно вижу людей, использующих синтаксис SQL-92 чаще, чем раньше. Я отвечаю на вопросы SQL в интернете с 1994 года.

ну стандарт ANSI092 включает в себя довольно отвратительный синтаксис. Естественные Соединения — Это одно и то используя П. Это другое. ИМХО, добавление столбца в таблицу не должно нарушать код, но естественное соединение ломается самым вопиющим образом.

«Лучший» способ сломать-ошибка компиляции. Например, если вы выберете * somewhere, добавление столбца может ошибка компиляции. Следующий лучший способ потерпеть неудачу — Ошибка времени выполнения.

Это хуже, потому что ваши пользователи может, и вижу, но все равно предупреждаю, что ты что-то сломал.

Если вы используете ANSI92 и пишете запросы с естественными соединениями, он не сломается во время компиляции и не сломается во время выполнения, запрос просто внезапно начнет давать неправильные результаты. Эти типы ошибок коварны. Отчеты идут неправильно, потенциально раскрытие финансовой информации неверно.

для тех, кто не знаком с естественными соединениями. Они объединяют две таблицы для каждого имени столбца, существующего в обеих таблицах. Какой действительно здорово, когда у вас есть ключ столбца 4, и вам надоело его печатать.

Проблема возникает, когда Table1 имеет уже существующий столбец с именем DESCRIPTION, и вы добавляете новый столбец в Table2 с именем, О, я не знаю, что-то безобидное, например, МММ, описание, и теперь вы соединяете две таблицы в поле VARCHAR2(1000), которое является свободной формой.

предложение USING может привести к полной двусмысленности в дополнение к описанной выше проблеме. В другом так пост, кто-то показал это ANSI-92 SQL и попросил помочь его прочитать.

SELECT c.*
FROM companies AS c
JOIN users AS u USING(companyid)
JOIN jobs AS j USING(userid)
JOIN useraccounts AS us USING(userid)
WHERE j.jobid = 123

Это совершенно неоднозначное. Я поместил столбец UserID в обе компании и таблицы пользователей, и нет никаких жалоб. Что делать, если столбец UserID в компаниях-это идентификатор последнего человека, который изменит эту строку?

Я серьезно, может кто-нибудь объяснить, почему такая двусмысленность была нужна? Почему он встроен прямо в стандарт?

Я думаю, что Билл прав, что есть большая база разработчиков, которые скопируйте / вставьте туда путь через кодирование. На самом деле, я могу признать, что я один из них, когда дело доходит до ANSI-92. Каждый пример, который я когда-либо видел, показывал, что несколько соединений вложены в круглые скобки.

Честность, что делает выбор таблиц в sql трудно в лучшем случае. Но затем эвангилист SQL92 объяснил, что фактически заставит порядок соединения. ИИСУС…

все эти копировальные пастеры, которые я видел, теперь фактически заставляют порядок соединения-задание, которое в 95% случаев лучше оставить оптимизаторам особенно копия/Пастер.

Tomalak получил это право, когда он сказал:

люди не переключаются на новый синтаксис просто потому что она есть!—6—>

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

на ум приходит несколько причин:

люди делают это по привычке
люди ленивы и предпочитают «старый стиль» присоединяется, потому что они вызывают меньше набирать
новички часто имеют свои проблемы, оборачивая голову вокруг синтаксиса SQL-92 join
люди не переключаются на новый синтаксис только потому, что он есть
люди не знают о преимуществах нового (если вы хотите назвать это, что) синтаксис и, в первую очередь, что он позволяет вам для фильтрации таблицы до вы делаете внешнее соединение, а не после него, когда все, что у вас есть, — это предложение WHERE.

со своей стороны, я делаю все мои соединения в синтаксисе SQL-92, и я конвертирую код, где могу. Это более чистый, читаемый и мощный способ сделать это. Но трудно убедить кого-то использовать новый стиль, когда они думают, что это вредит им с точки зрения большей работы по набору текста, не изменяя результат запроса.

в ответ на естественное соединение и использование сообщения выше.
Почему вы когда — либо видели необходимость использовать их-они не были доступны в ANSI-89 и были добавлены для ANSI-92 как то, что я вижу только как ярлык.
Я бы никогда не оставил соединение на волю случая и всегда указывал бы таблицу/псевдоним и идентификатор.

для меня единственный способ пойти-ANSI-92. Это более многословно, и синтаксис не нравится последователям ANSI-89, но он аккуратно отделяет ваши соединения от ваших ФИЛЬТРУЮЩИЙ.

сначала позвольте мне сказать, что в SQL Server синтаксис внешнего соединения (*=) не дает правильных результатов все время. Бывают случаи, когда он интерпретирует это как перекрестное соединение, а не внешнее соединение. Так что есть веская причина прекратить его использовать.

И этот внешний синтаксис соединения является устаревшей функцией и не будет в следующей версии SQL Server после SQL Server 2008. Вы все еще сможете делать внутренние соединения, но зачем кому-то это нужно? Они неясны и гораздо сложнее поддерживать.

Вы не можете знать, что является частью соединения и что это просто предложение where.

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

Вы не должны писать какой-либо код SQL без понимания соединений тщательно. Если вы хорошо их понимаете, то, вероятно, придете к выводу, что синтаксис ANSI-92 понятнее и легче поддерживать.

Я никогда не встречал эксперта SQL, который не использовал синтаксис ANSI-92 в предпочтении старому синтаксису.

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

Я преподавал ANSI-89 в школе и работал в промышленности в течение нескольких лет. Затем я покинул сказочный мир СУБД на 8 лет. Но потом я вернулся, и этому новому материалу ANSI 92 учили. Я изучил синтаксис Join On, и теперь я действительно учу SQL, и я рекомендую новый синтаксис JOIN ON.

но обратная сторона, которую я вижу, — это коррелированные подзапросы, кажется, не имеет смысла в свете соединений ANSI 92.

Когда информация о соединении была включена в WHERE и коррелирована подзапросы «объединены» в том, где все казалось правильным и последовательным.

В ANSI 92 критерии соединения таблицы не находятся в WHERE и подзапросе «join», синтаксис кажется непоследовательным. С другой стороны, попытка «исправить» это несоответствие, вероятно, только ухудшит ситуацию.

Я не знаю ответа наверняка.. это вероисповедные войны (albiet в меньшей степени, чем Mac ПК или другим)

предположим, что до недавнего времени Oracle (и, возможно, другие поставщики) не принимали стандарт ANSI-92 (я думаю, это было в Oracle v9 или около того), и поэтому для разработчиков DBAs/Db, работающих в компаниях, которые все еще использовали эти версии (или хотели, чтобы код был переносимым на серверах, которые могли бы использовать эти версии, они должны были придерживаться старый стандарт…

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

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

инерция и практичность.

ANSI-92 SQL похож на сенсорный ввод. Теоретически это может когда-нибудь все исправить, но теперь я могу печатать гораздо быстрее, глядя на клавиши четырьмя пальцами. Для того чтобы двигаться вперед, мне придется идти назад, не имея никаких гарантий, что когда-нибудь будет отдача.

написание SQL-это около 10% моей работы. Если мне нужен ANSI-92 SQL для решения проблемы, которую ANSI-89 SQL не может решить, я использую его. (Я использую его в Access, in факт.

Если бы использование его все время помогало мне быстрее решать существующие проблемы, я бы потратил время на его ассимиляцию. Но я могу вывести ANSI-89 SQL, даже не задумываясь о синтаксисе.

Мне платят за решение проблем-думать о синтаксисе SQL-это пустая трата моего времени и денег моего работодателя.

когда-нибудь, молодой Кузнечик, вы будете защищать свое использование синтаксиса ANSI-92 SQL от молодых людей, нытье, что вы должны использовать SQL3 (или что-то еще). И тогда ты поймешь. 🙂

у меня был запрос, который был первоначально написан для SQL Server 6.5, который не поддерживал синтаксис SQL 92 join, т. е.

select foo.baz
from foo
left outer join bar
on foo.a = bar.a

вместо этого было написано как

select foo.baz
from foo, bar
where foo.a *= bar.a

запрос был вокруг в течение некоторого времени, и соответствующие данные накопились, чтобы сделать запрос работать слишком медленно, около 90 секунд для завершения. К тому времени, когда эта проблема возникла, мы обновились до SQL Server 7.

после возни с индексами и другими пасхальными яйцами я изменил соединение синтаксис должен быть совместим с SQL 92. Время запроса упало до 3 секунд.

есть веская причина для переключения.

репост от здесь.

Я могу ответить с точки зрения среднего разработчика, зная достаточно SQL, чтобы понять оба синтаксиса, но все же гуглить точный синтаксис insert каждый раз, когда мне это нужно… :- P (Я не делаю SQL весь день, просто исправляя некоторые проблемы время от времени.)

Почему стандарт SQL ANSI-92 не принят лучше, чем ANSI-89?

Ну стандартный ANSI092 включает в себя некоторые довольно отвратительные синтаксис. [Естественные соединения][1] это одно и то используя П. Это другое. ИМХО, добавление столбца к таблице должен'т сломать код, но естественное соединение рвется в самых вопиющих моды.

В «лучших» и способ взлома-это ошибка компиляции. Например, если вы выберите * где-то, добавление столбца может компилироваться. Следующий лучшим способом не будет ошибка времени выполнения.

Это's хуже, потому что ваши пользователи могут видеть это, но она по-прежнему дает хорошее предупреждение, что вы'вэ-то сломал.

Если вы используете ansi92 присвоено и писать запросы с естественные соединения, он выиграл'т сломать во время компиляции, и он выиграл'т сломать во время выполнения запроса будет просто начнем выдавать неверные результаты. Эти типы ошибок коварны. Отчеты ошибетесь, потенциально раскрытия финансовой информации являются неправильными.

Для тех, кто незнаком с естественными соединениями. Они объединяют две таблицы на каждое имя столбца, который присутствует в обеих таблицах. Что очень круто, когда у тебя есть 4 основных колонки и вы'вновь заболел вводить его.

Проблема приходит, когда Таблица1 уже есть столбец с именем «описание» и добавить новый столбец к таблице table2 имени, я не'т знаю, что-то безобидное, как, МММ, описание и теперь вы'повторного соединения двух таблиц на VARCHAR2(1000) поле, которое находится в свободной форме.

Использование положение может привести к полной неопределенности в дополнение к описанной выше проблеме. В другой [так] Сообщение2, кто-то показал этот стандарт ANSI-92 SQL и попросил помочь прочитать его.

Это совершенно неоднозначное. Я положил столбец userId в обеих компаниях и таблицы пользователей и там's никакой жалобы. А что если столбец userId в компаниях-идентификатор последнего человека, чтобы изменить эту строку?

Я'м серьезный, может кто-нибудь объяснить, почему такая двусмысленность была нужна? Почему ее построили прямо в стандарт?

Я считаю, что законопроект правильный, что существует большая база разработчика, который копировать/вставить есть способ, с помощью кодирования. На самом деле, я могу признаться, что я'м один, когда дело доходит до стандарта ANSI-92.

Каждый пример, который я когда-либо видел, показал множественные суставы, вложенные в скобках. Честность, что делает выбор из таблицы в SQL сложно. Но тогда evangilist SQL92 пояснил, что фактически принудительный порядок соединения. Иисус…

все эти копии поклейщиков я'видел сейчас фактически заставляя того присоединиться — работа, которая'с 95% времени лучше оставить для оптимизаторов especially копия/Пастер.

Tomalak получил это право, когда он сказал:

люди Дон't, чтобы новый синтаксис просто
потому что он есть