SQL Anywhere 10 Developer Edition
Alexander Goldun
доступна для скачивания developer editions.
Далеко не полный перечень нововведений:
- Поддержка распараллеливания выполнения одного запроса между
несколькими процессорами.
- Организации отказоустойчивого кластера из 3-х серверов
- Уровень изоляции SNAPSHOT
- Materialized views
- улучшения в профайлере
- Добавлен новый тип поддержки строк в уникоде NCHAR и функции работы с
ним.
- Добавлен новый тип для хранения битовых массивов BITARRAY и функции
работы с ним.
- Расширено управление индексами
- Расширены алгоритмы оптимизатора запросов
- Расширена поддержка BLOB полей, индексация на текстовые длинные поля
для организации полнотекстового поиска
- Возможность компрессии указанных столбцов таблиц.
- Добавлена поддержка криптографии указанных таблиц.
- Новые алгоритмы шифрования RSA и FIPS по 256-разрядному ключу (до
этого поддерживался только AES).
- Сделана совместимость веб сервера ASA с стандартом HTTP 1.1, с
поддержкой всех соглашений передачи заголовков, сессионным способом работы.
- Криптография БД включена в лицензию стандартного сервера, без
требования покупки дополнительной лицензии на использование криптографии.
И многое другое. Подробнее тут:
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/1000/en/html/dbwnen10/wn-newjasper.html
Скачать можно тут:
http://www.ianywhere.com/downloads/software/sql_anywhere_10.html
Регистрационный ключ высылают бесплатно после регистрации:
http://crm.sybase.com/sybase/www/iAS/sql_developer_download.jsp?tpl=syb
Ivan Frolkov
AG> 7 августа был анонсирован выход SQL Anywhere 10, а на днях стала
AG> доступна для скачивания developer editions.
Вот их интересно мерцает - то SQL Anywhere, то Adaptive Sever Anywhere, то
опять SQL Anywhere. Глядишь, так и Watcom SQL появится...
А вообще приятный серверок. К сожалению, судя по документации, materialized
view в нынешнем состоянии - не более чем заявка на грядущие свершения.
Alexander Goldun
>> 7 августа был анонсирован выход SQL Anywhere 10, а на днях стала
>> доступна для скачивания developer editions.
>
> Вот их интересно мерцает - то SQL Anywhere, то Adaptive Sever Anywhere, то
> опять SQL Anywhere. Глядишь, так и Watcom SQL появится...
Мне лично по душе такой возврат к истокам. Большинство в сообществе тоже
на ура восприняли. Кстати, случай не единичный в ИТ. Вспомни
Borland-Inprise-Borland.
> А вообще приятный серверок. К сожалению, судя по документации, materialized
> view в нынешнем состоянии - не более чем заявка на грядущие свершения.
Не готов обсуждать. Все никак руки не дойдут пощупать их. А что именно в
этих views не понравилось?
Ivan Frolkov
>> Вот их интересно мерцает - то SQL Anywhere, то Adaptive Sever Anywhere, то
>> опять SQL Anywhere. Глядишь, так и Watcom SQL появится...
AG> Мне лично по душе такой возврат к истокам. Большинство в сообществе тоже
AG> на ура восприняли. Кстати, случай не единичный в ИТ. Вспомни
AG> Borland-Inprise-Borland.
Да я, в общем и целом, тоже не против. Хватит кормить всяких мутных
маркетологов!
>> А вообще приятный серверок. К сожалению, судя по документации,
>> materialized view в нынешнем состоянии - не более чем заявка на грядущие
>> свершения.
AG> е готов обсуждать. Все никак руки не дойдут пощупать их. А что именно в
AG> этих views не понравилось?
Hу там только полное перестроение. Ораклячий refresh fast, соответственно, не
существует...
Alexander Goldun
>> е готов обсуждать. Все никак руки не дойдут пощупать их. А что именно в
>> этих views не понравилось?
> Hу там только полное перестроение.
Оно и в таком виде может принести достаточно пользы.
> Ораклячий refresh fast, соответственно, не существует...
Ну, в SA, наверное, много чего не существует из того, что есть в оракле.
(Особенно позиции SQL Anywhere DBA за много денег в месяц на сайтах по
трудоустройству :) Впрочем, и обратное тоже верно - не все из SA есть в
Oracle. В iAnywhere вроде не ставят задачи повторить оракл.
Tolik Gusin
Alexander Goldun wrote:
> 7 августа был анонсирован выход SQL Anywhere 10, а на днях стала
> доступна для скачивания developer editions.
>
> работы с ним.
Интересно, а что в таком массиве можно хранить и для чего его можно
использовать ?
> - Расширено управление индексами
А там случайно поддержка индексов по функциям (как например в yaffil или
xbase) не появилась ?
> - Расширена поддержка BLOB полей, индексация на текстовые длинные поля
> для организации полнотекстового поиска
Иитересно, как оно работает ?
--
С Уважением, Stalker
Origin: The History is Dead
Alexander Goldun
>> - Добавлен новый тип для хранения битовых массивов BITARRAY и функции
>> работы с ним.
> Как я понимаю это массив состоящий из элементов типа bit (0-255) ?
Да, только тип bit - это 0 или 1, а не (0-255) :)
> Интересно, а что в таком массиве можно хранить
Последовательность битов, очевидно.
>> - Расширено управление индексами
> А там случайно поддержка индексов по функциям (как например в yaffil или
> xbase) не появилась ?
А что есть индекс по функциям? В SQL Anywhere уже давно можно делать
индексы по вычислимым полям. А эти поля могут вычисляться в том числе и
функциями.
>> - Расширена поддержка BLOB полей, индексация на текстовые длинные поля
>> для организации полнотекстового поиска
> Иитересно, как оно работает ?
С этим еще не разбирался. Тупо скопировал предыдущий анонс на выход
беты. Возможно тут что-то и приукрашено. Навскидку по блобам пока вижу
возможность управления хранением блобов, шаринг одних и тех же блобов
между разными записями, и возможность указать для блоба, что он
индексированный. Причем отмечено, что эта индексация - не то же самое,
что обычный индекс в БД, и служит для ускорения произвольного доступа
внутри блоба. Подробностей пока не нашел в доках.
Tolik Gusin
> Да, только тип bit - это 0 или 1, а не (0-255) :)
>
> > Интересно, а что в таком массиве можно хранить
>
> Последовательность битов, очевидно.
А ты можешь привести какую нибудь реальную ситуацию, которая может
потребовать такое поле ?
Мне кажется, что это тип был добавлен по просьбе какого нибудь крупного
корпоративного заказчика.
> >> - Расширено управление индексами
> > А там случайно поддержка индексов по функциям (как например в yaffil или
> > xbase) не появилась ?
>
> А что есть индекс по функциям?
Ну например индекс по выражению YEAR(DATE_FIELD)
> В SQL Anywhere уже давно можно делать индексы по вычислимым полям.
Про это я в курсе, но это надо заводить доп. поле чего делать не очень
хочется.
> А эти поля могут вычисляться в том числе и функциями.
Есть пара вопросов по вычисляемым полям:
1) Храниться ли оно реально в базе ?
2) Когда эти поля вычисляются ? В момент обращения к ним или в момент
обновления
полей на которые есть ссылки в вычисляемых полях ?
> >> - Расширена поддержка BLOB полей, индексация на текстовые длинные поля
> >> для организации полнотекстового поиска
> > Иитересно, как оно работает ?
> Навскидку по блобам пока вижу
> возможность управления хранением блобов,
То есть теперь можно хранить блобы в отдельных tablespace и не
логировать их, как в DB2 ?
> шаринг одних и тех же блобов между разными записями
Что это такое ?
> Причем отмечено, что эта индексация -
> не то же самое, что обычный индекс в БД, и служит для ускорения произвольного доступа
> внутри блоба
То есть для блоба поиск вида like '%test%' будет осуществляется с
применением индекса ?
Если это так, то хотелось бы такой индекс и для обычных char полей.
Alexander Goldun
>>> Интересно, а что в таком массиве можно хранить
>> Последовательность битов, очевидно.
> А ты можешь привести какую нибудь реальную ситуацию, которая может
> потребовать такое поле ?
Я не заказывал. Кому-то, возможно, нужно. Придумать примеры можно, но
лениво. К чему вопрос? Типа нафиг это нужно?
> Мне кажется, что это тип был добавлен по просьбе какого нибудь крупного
> корпоративного заказчика.
Может быть, но не обязательно. Бывает реализуются фичи, которые желает
заметное кол-во обычных подписчиков соответствующих ньюсгруп.
>>> А там случайно поддержка индексов по функциям (как например в
>>> yaffil или xbase) не появилась ?
>> А что есть индекс по функциям?
> Hу например индекс по выражению YEAR(DATE_FIELD)
>> В SQL Anywhere уже давно можно делать индексы по вычислимым полям.
> Про это я в курсе, но это надо заводить доп. поле чего делать не очень
> хочется.
"Хочется" - субъективная категория в таком контексте :) Индекс по
выражению в ASA делается. Но через вычислимое поле. За то в отличие от
Yaffil это выражение может содержать хранимую функцию.
>> А эти поля могут вычисляться в том числе и функциями.
> Есть пара вопросов по вычисляемым полям:
> 1) Храниться ли оно реально в базе ?
Да.
> 2) Когда эти поля вычисляются ? В момент обращения к ним или в момент
> обновления полей на которые есть ссылки в вычисляемых полях ?
В момент обновления или вставки записи.
>> Hавскидку по блобам пока вижу
>> возможность управления хранением блобов,
> То есть теперь можно хранить блобы в отдельных tablespace и не
> логировать их, как в DB2 ?
Такого не заметил.
>> шаринг одних и тех же блобов между разными записями
> Что это такое ?
Только, похоже, не между записями, а между полями.
>> Причем отмечено, что эта индексация -
>> не то же самое, что обычный индекс в БД, и служит для ускорения
>> произвольного
>> доступа внутри блоба
> То есть для блоба поиск вида like '%test%' будет осуществляется с
> применением индекса ?
Не готов сейчас ответить достоверно. Надо проверять или спрашивать в
sybase.public.sqlanywhere.general. Или спроси в форуме на www.rusug.ru -
вдруг кто-нибудь уже успел распробовать.
> Если это так, то хотелось бы такой индекс и для обычных char полей.
А оно так и есть - в ASA типы char(N), varchar(N) и long varchar
принципиально не отличаются.
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/1000/en/html/dbrfen10/rf-dtch.html
Andrew Lening
AG> Я не заказывал. Кому-то, возможно, нужно. Придумать примеры можно, но
AG> лениво. К чему вопрос? Типа нафиг это нужно?
Плохой, негодный тип данных :-) Хинт: 1NF.
AG> Может быть, но не обязательно. Бывает реализуются фичи, которые желает
AG> заметное кол-во обычных подписчиков соответствующих ньюсгруп.
Тоже плохой подход. "Заметное количество обычных подписчиков" может захотеть
сколь угодно левую фигню, типа циклов for i = 1 to N в хранимых процедурах, и
что, реализовать? Функционалом системы должен заниматься грамотный системный
архитектор, а не невнятная толпа пользователей сомнительной квалификации. С
учетом пожеланий пользователей, конечно, но без фанатизма :-)
Bye.
Alexander Goldun
>> Я не заказывал. Кому-то, возможно, нужно. Придумать примеры можно, но
> Плохой, негодный тип данных :-) Хинт: 1NF.
А ты, случайно, не с IB/FB работаешь?
>> Может быть, но не обязательно. Бывает реализуются фичи, которые желает
>> заметное кол-во обычных подписчиков соответствующих ньюсгруп.
> Тоже плохой подход. "Заметное количество обычных подписчиков" может захотеть
> сколь угодно левую фигню, типа циклов for i = 1 to N в хранимых процедурах, и
> что, реализовать? Функционалом системы должен заниматься грамотный системный
> архитектор, а не невнятная толпа пользователей сомнительной квалификации. С
> учетом пожеланий пользователей, конечно, но без фанатизма :-)
Полагаешь, в команде iAnywhere нет системных архитекторов и лепят все,
что захочет случайный прохожий?
Ivan Frolkov
AL> Плохой, негодный тип данных :-) Хинт: 1NF.
Hда? Микрософту скажи с сайбесом. Или включи здравый смысл - прочитать,
скажем, 4096 раз по байту проще, чем 4096 раз по 8 байт => table scan/index
cover в некоторых случаях в 8 раз быстрее.
AG>> Может быть, но не обязательно. Бывает реализуются фичи, которые желает
AG>> заметное кол-во обычных подписчиков соответствующих ньюсгруп.
AL> Тоже плохой подход. "Заметное количество обычных подписчиков" может
AL> захотеть сколь угодно левую фигню, типа циклов for i = 1 to N в хранимых
AL> процедурах,
Скажи об этом ораклу - они, бедные, поди, и не знают, что лохи.
AL> и что, реализовать? Функционалом системы должен заниматься
AL> грамотный системный архитектор, а не невнятная толпа пользователей
AL> сомнительной квалификации. С учетом пожеланий пользователей, конечно, но
AL> без фанатизма :-)
"Многие вещи нам непонятны не потому, что наши понятия об этих вещах слабы, но
потому, что вещи сии не входят в круг наших понятий".
Ilya Kulagin
IF> Скажи об этом ораклу - они, бедные, поди, и не знают, что лохи.
Информикс тоже. Это самое. Так что можно в оба адреса, рассылкой.
/kiv
Sergey Leschenko
> AG> Может быть, но не обязательно. Бывает реализуются фичи, которые желает
> AG> заметное кол-во обычных подписчиков соответствующих ньюсгруп.
>
> Тоже плохой подход. "Заметное количество обычных подписчиков" может захотеть
> сколь угодно левую фигню, типа циклов for i = 1 to N в хранимых процедурах, и
> что, реализовать? Функционалом системы должен заниматься грамотный системный
> архитектор, а не невнятная толпа пользователей сомнительной квалификации. С
> учетом пожеланий пользователей, конечно, но без фанатизма :-)
Реализация фич, которые 'хочет толпа', думаю, помогают продажам ПО.
Ведь это же не означает, что проектировщик/разработчик не квалифицирован
:)
--
Sergey xmms: Eisregen - Vorabend der Schlacht
[ не пришел, не увидел, не победил, даже не позвонил ]
Andrew Lening
>>> Я не заказывал. Кому-то, возможно, нужно. Придумать примеры можно,
>>> но лениво. К чему вопрос? Типа нафиг это нужно?
>> Плохой, негодный тип данных :-) Хинт: 1NF.
AG> А ты, случайно, не с IB/FB работаешь?
Было дело, работал, сейчас только по мелочи. Массивами тоже не пользовался :-)
>> Тоже плохой подход. "Заметное количество обычных подписчиков" может
>> захотеть сколь угодно левую фигню, типа циклов for i = 1 to N в
>> хранимых процедурах, и что, реализовать? Функционалом системы должен
>> заниматься грамотный системный архитектор, а не невнятная толпа
>> пользователей сомнительной квалификации. С учетом пожеланий
>> пользователей, конечно, но без фанатизма :-)
AG> Полагаешь, в команде iAnywhere нет системных архитекторов и лепят все,
AG> что захочет случайный прохожий?
Hет, разумеется :-) Мысли вслух просто.
Bye.
Andrew Lening
AL>> Плохой, негодный тип данных :-) Хинт: 1NF.
IF> Hда? Микрософту скажи с сайбесом. Или включи здравый смысл -
IF> прочитать, скажем, 4096 раз по байту проще, чем 4096 раз по 8 байт =>
IF> table scan/index cover в некоторых случаях в 8 раз быстрее.
Детали реализации не имеют никакого отношения к форме представления данных.
MS SQL сервер, например, упакует 32 поля типа BIT в 4 байта, но при этом по
сути это будут 32 различных поля - и это правильно.
Первая нормальная форма: значение должно быть атомарным, поле не должно хранить
списки чего бы то ни было.
И знаешь, я давно убедился, что реляционную модель и все эти многочисленные
правила придумали вовсе не дураки и вовсе не просто так. Просто она требует
несколько иного образа мышления и подхода к проектированию, что плохо
укладывается в головах у разработчиков, привыкших к другим системам и языкам.
AL>> Тоже плохой подход. "Заметное количество обычных подписчиков"
AL>> может захотеть сколь угодно левую фигню, типа циклов for i = 1 to N
AL>> в хранимых процедурах,
IF> Скажи об этом ораклу - они, бедные, поди, и не знают, что лохи.
Процедурный стиль программирования - вообще не совсем то, что нужно реляционным
базам данных :-)
Hу конкретно, зачем может понадобиться такой цикл "от 1 до 5" в хранимой
процедуре? В примерах?
IF> "Многие вещи нам непонятны не потому, что наши понятия об этих вещах
IF> слабы, но потому, что вещи сии не входят в круг наших понятий".
В круг моих понятий входит достаточно неплохое понимание того, что такое
_реляционные_ базы данных и чем они отличаются от более "привычных" систем
хранения :-)
Bye.
Alexander Goldun
>>>> Я не заказывал. Кому-то, возможно, нужно. Придумать примеры можно,
>>>> но лениво. К чему вопрос? Типа нафиг это нужно?
>>> Плохой, негодный тип данных :-) Хинт: 1NF.
>> А ты, случайно, не с IB/FB работаешь?
>
> Было дело, работал, сейчас только по мелочи. Массивами тоже не пользовался
> :-)
Угадал, значит :) Я не про массивы. Я только про привычку обзывать
плохим и негодным то, что отсутствует в "родном" сервере, эпизодически
наблюдавшуюся у некоторых людей именно в том сообществе.
Alexander Goldun
> Первая нормальная форма: значение должно быть атомарным, поле не должно
> хранить
> списки чего бы то ни было.
Может стоило бы сначала подробнее ознакомится с предметом перед тем, как
выносит вердикт? Где-то я уже встречал фразу "... не читал, но осуждаю" :)))
Тип VARBIT в Anywhere по своей сути ближе к VARCHAR, чем к массивам.
VARCHAR с таким же успехом можно обозвать массивом символов. VARBIT
обозвали массивом битов, можно было бы назвать битовой строкой или
последовательнстью. Вопрос терминологии. Вот описание этого типа:
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/1000/en/html/dbrfen10/rf-datatypes-s-3941580.html
Кстати, помимо собственно типа, разумеется, добавлены и функции для
работы с ним:
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/1000/en/html/dbrfen10/rf-functions-s-4959299.html
В том числе и агрегатные функции BIT_AND, BIT_XOR, BIT_OR
Полагаю, что оно вполне может найти достойное применение в определенных
задачах. Может тебя смутили воспоминания о массивах в IB, которые
действительно были малопригодны для практического использования?
>>> Тоже плохой подход. "Заметное количество обычных подписчиков"
>>> может захотеть сколь угодно левую фигню, типа циклов for i = 1 to N
>>> в хранимых процедурах,
>> Скажи об этом ораклу - они, бедные, поди, и не знают, что лохи.
>
> Процедурный стиль программирования - вообще не совсем то, что нужно
> реляционным
> базам данных :-)
Реляционные базы - суть вещи неодушевленные и вряд ли им что-то нужно. А
вот разработчикам для реализации логики на сервере процедурный стиль
может оказаться весьма полезен.
> Hу конкретно, зачем может понадобиться такой цикл "от 1 до 5" в хранимой
> процедуре? В примерах?
Навскидку у себя в базе обнаружил несколько хранимых функций со
специфической обработкой строк. Там как раз индексные циклы. В Anywhere
отсутствует for i = 1 to N, поэтому там используется обычный WHILE с
условием и увеличением индекса в теле цикла. Но если бы был FOR, то он
был бы там более органичен.
Andrew Lening
По поводу формулировки "плохо то, чего нет в Interbase" - нет, это не так.
Больше того скажу, это не "родной" и не единственный сервер, с которым я имел
дело.
Я изучал все связанное с базами данных по книгам так сказать "реляционных
пуристов" (вроде Джо Селко) и, в общем, считаю это правильным подходом.
В частности, есть замечательная штука - стандарты. И если в стандарте нету типа
данных "массив че-то там", значит, нафиг он не нужен :-)
>> Первая нормальная форма: значение должно быть атомарным, поле не
>> должно хранить списки чего бы то ни было.
AG> Может стоило бы сначала подробнее ознакомится с предметом перед тем,
AG> как выносит вердикт? Где-то я уже встречал фразу "... не читал, но
AG> осуждаю" :)))
Что читать, вот это: "Used for storing bit arrays that are under 32767 bits in
length"? :-)
AG> Тип VARBIT в Anywhere по своей сути ближе к VARCHAR, чем к массивам.
Каким образом? Смотри по ссылке: написано "bit array", а про отношение к строке
нифига не написано. Varchar предназначен для хранения СТРОК переменной длины.
Строка как единая сущность имеет смысл, а отдельные символы в ней - нет. А
массивы битов обычно используются для хранения данных, которые по сути являются
отдельными элементами. Hапример, набор каких-то флагов объекта. Каждый из
которых является осмысленным сам по себе, вот что важно. Поэтому их и не нужно
пихать в массив.
AG> VARCHAR с таким же успехом можно обозвать массивом символов.
Hет. От разбиения строки на отдельные символы информация теряется.
AG> Полагаю, что оно вполне может найти достойное применение в
AG> определенных задачах.
Hу, вот в постгресе есть типы для хранения чуть ли не графиков функций - как ты
считаешь, корректно такие вещи пихать в базу данных?
AG> Может тебя смутили воспоминания о массивах в IB, которые
AG> действительно были малопригодны для практического использования?
Да дело не в пригодности. И их кто-то использовал, и иногда даже благополучно.
Дело в противоречии реляционной теории, о котором я тут и толкую.
>> Процедурный стиль программирования - вообще не совсем то, что нужно
>> реляционным базам данных :-)
AG> Реляционные базы - суть вещи неодушевленные и вряд ли им что-то нужно.
AG> А вот разработчикам для реализации логики на сервере процедурный стиль
AG> может оказаться весьма полезен.
Есть масса мест в системе, не связанных с базой данных, где реализация подобной
логики обычно намного более уместна :-)
>> Hу конкретно, зачем может понадобиться такой цикл "от 1 до 5" в
>> хранимой процедуре? В примерах?
AG> Навскидку у себя в базе обнаружил несколько хранимых функций со
AG> специфической обработкой строк. Там как раз индексные циклы.
Конкретный пример можно? В частности интересно, почему эта специфическая
обработка не делается в хост-языке. Hавороченная обработка строк - опять же, не
лучшее занятие для РСУБД.
Bye.
Alexander Goldun
> В частности, есть замечательная штука - стандарты. И если в стандарте нету
> типа
> данных "массив че-то там", значит, нафиг он не нужен :-)
Смайлик в таком контексте служит слабым оправданием дурацкой шутки. Если
это, конечно, была шутка.
>> Тип VARBIT в Anywhere по своей сути ближе к VARCHAR, чем к массивам.
> Каким образом? Смотри по ссылке: написано "bit array", а про отношение к
> строке
> нифига не написано.
Анализируешь тупо по ключевым словам, как поисковая система? Отношение к
строке хотя бы из элементарной схожести: и то и другое
последовательность элементов
> Varchar предназначен для хранения СТРОК переменной длины.
VARBIT предназначен для хранения строчек битов переменной длины.
> Строка как единая сущность имеет смысл, а отдельные символы в ней - нет. А
> массивы битов обычно используются для хранения данных, которые по сути
> являются
> отдельными элементами.
Кто сказал? В ключе шифрования отдельный бит имеет смысл без прочих? А в
IP-адресе или маске подсети?
> Hапример, набор каких-то флагов объекта. Каждый из
> которых является осмысленным сам по себе, вот что важно.
Это только в одном из множества возможных вариантов использования. Точно
так же и varchar может использоваться таким образом, когда каждый
отдельный символ будет иметь осмысленное значение.
>> VARCHAR с таким же успехом можно обозвать массивом символов.
> Hет. От разбиения строки на отдельные символы информация теряется.
См. выше. У тебя слишком узкое представление о возможных областях
эффективного применения СУБД.
>> Полагаю, что оно вполне может найти достойное применение в
>> определенных задачах.
> Hу, вот в постгресе есть типы для хранения чуть ли не графиков функций - как
> ты
> считаешь, корректно такие вещи пихать в базу данных?
Абсолютно. А почему бы и нет? Это ведь ДАННЫЕ! И хранятся в базе ДАННЫХ.
> Дело в противоречии реляционной теории, о котором я тут и толкую.
Где именно противоречие? Пока не вижу. Растолкуй.
>>> Процедурный стиль программирования - вообще не совсем то, что нужно
>>> реляционным базам данных :-)
>> Реляционные базы - суть вещи неодушевленные и вряд ли им что-то нужно.
>> А вот разработчикам для реализации логики на сервере процедурный стиль
>> может оказаться весьма полезен.
> Есть масса мест в системе, не связанных с базой данных, где реализация
> подобной
> логики обычно намного более уместна :-)
В какой системе? Ты за всех на все случаи жизни определишь универсальную
уместность?
>>> Hу конкретно, зачем может понадобиться такой цикл "от 1 до 5" в
>>> хранимой процедуре? В примерах?
>> Навскидку у себя в базе обнаружил несколько хранимых функций со
>> специфической обработкой строк. Там как раз индексные циклы.
>
> Конкретный пример можно?
Чего пример? Привести полный текст функций?
> В частности интересно, почему эта специфическая обработка не делается
> в хост-языке.
Потому что эти функции нужны в других хранимых процедурах, реализующих
логику на сервере. Зачем их куда-то выносить, если они _прекрасно_
реализуются в хранимой функции?
> Hавороченная обработка строк - опять же, не лучшее занятие для РСУБД.
Почему? Где табель о рангах для занятий РСУБД?
P.S. Если ты так ратуешь про стандарты, то не поленись их для начала
хотя бы ПРОЧИТАТЬ. ANSI ISO 9075-2:1999
4 Concepts
4.1 Data types
...
- --- The data types BIT and BIT VARYING are collectively referred to as bit
string types.
...
4.4 Bit strings
A bit string is a sequence of bits, each having the value
length, which is the number of bits in the string. The
A bit string data type is described by a bit string data
descriptor contains:
- --- The name of the specific bit string data type (BIT
- --- The length of the bit string data type (in bits).
...
6 Scalar expressions
6.1 <data type>
....
<bit string type> ::=
BIT [ <left paren> <length> <right paren> ]
| BIT VARYING <left paren> <length> <right paren>
и еще много упоминаний. Противоречий с реализацией в ASA не нашел.
Еще вопросы есть, уважаемый блюститель стандартов?
Ilya Kulagin
AL> Я изучал все связанное с базами данных по книгам так сказать "реляционных
AL> пуристов" (вроде Джо Селко) и, в общем, считаю это правильным подходом.
AL> В частности, есть замечательная штука - стандарты.
Например, стандарт языка хранимых процедур. О каковом (языке) и шла речь. Ну а
стандартом Вы, вероятно, выбрали интербейс...
AL> нету типа данных "массив че-то там", значит, нафиг он не нужен :-)
А "тип 'цикл while'" есть в стандарте? Я не в курсе.
AL> каких-то флагов объекта. Каждый из которых является осмысленным сам по
AL> себе, вот что важно
Если перейти от сферических флагов в обобщённом пространстве к конкретным
флагам, например, символов доходов и расходов в лицевых счетах 701*
российского НПС, то быстро обнаружится, что отнюдь не "сами по себе". Впрочем,
битовая строка тут не нужна, поскольку счёт - это char(20).
AL> Дело в противоречии реляционной теории, о котором я тут и толкую.
Точнее, речь о том, что ХП вообще никак не укладываются ни в какую реляционную
теорию. Поскольку теория сия трактует о хранении данных. А ХП для хранения не
используются...
AL> Есть масса мест в системе, не связанных с базой данных, где реализация
AL> подобной логики обычно намного более уместна :-)
Такая мысль была популярна, во времена развития разнообразных 4GL. Потом
постепенно выяснилось, что иногда проще всё-таки делать двухзвенку, чем
трёхзвенку. Для чего и пригодились ХП. Например, в случае вебинтерфейсов к
данным.
AL> Конкретный пример можно? В частности интересно, почему эта специфическая
AL> обработка не делается в хост-языке.
Поскольку у хост-системы вообще нет грантов на селект и апдейт, например. И не
должно быть, ибо она небезопасна. В частном случае вебинтерфейса.
AL> Hавороченная обработка строк - опять
AL> же, не лучшее занятие для РСУБД.
Опять же, процесс выполнения цикла в ХП не имеет отношения к операциям,
связанным с хранением данных. Это просто другой, совершенно отдельный процесс.
И в данном случае нет разницы, в каком именно месте памяти будет
обрабатываться логическое вычисление, и под каким именно userid будет занят
процессор.
/kiv