Hello, "aston"

> Переключение контекста будет происходить обязательно.

Вопрос. Какой смысл вкладывается в слова "Переключение контекста" (в контексте данного обсуждения конечно)?

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, aston, Вы писали:

A>>Да черт с ней, с объектной моделью. Смысл то в том, что у сервера, помимо SQL, есть еще процедурный язык. Так вот — в Oracle их 2 — PL/SQL и Java. В MSSQL это T-SQL.
M>Да нет же, в MSSQL T-SQL — это именно диалект ANSI SQL и не более того.
Давайте оставим стандарты в покое и посмотрим: какую роль имеют процедурные расширения того или иного сервера. Прально — написание процедурного кода, который тесно интегрирован с SQL сервера. И именно в этом контексте что T-SQL, что PL/SQL, что Java выполняют одну и ту же задачу, только Java позволяет писать еще и объектный код.

A>>Короче говоря, считайте, что Java в Oracle, это как T-SQL в MSSQL.
M>Нет, это не так. T-SQL в принципе предназначен для другого. Ява — это ООП, а SQL — это Relation и наличие/отсутствие переключения контекста здесь никакой роли не играет.
Ну в чем различие в их предназначении:

T-SQL

GO
CREATE PROCEDURE SomeProc
AS
  --some t-sql code here
GO

PL/SQL

CREATE OR REPLACE PROCEDURE SomeProc
IS
BEGIN
  --some pl/sql code here
END;

Java SP

CREATE OR REPLACE PROCEDURE SomeProc
AS LANGUAGE JAVA
NAME 'SomeClass.SomeProc'

+

public class SomeClass {
  public static void SomeProc () {
    //some Java code here
  }
}

Почему Oracle так поступил? Я думаю, там следут логике, что дешевле и эффективнее обрабатывать данные там, где они хранятся, т.е. на сервере. А клиенту выдавать уже обработанный и подготовленный рзеультат. В этом плане надобность в App-сервере действительно как-то пропадает.

M>Просто в Оракле сростили две идеологически разные функциональности в одну, поскольку в некоторых случаях это удобно. Но это совершенно не означает того, что их противопоказано использовать по отдельности.
Просто Oracle наплевал на стандарты и ушел вперед и это надо признать. MS пока в роли догоняющего и ударными темпами мутит Yukon.
Все это мое IMHO и переубеждать меня в этом безполезно.

Здравствуйте, TK, Вы писали:

TK>Hello, "aston"

>> Переключение контекста будет происходить обязательно.

TK>Вопрос. Какой смысл вкладывается в слова "Переключение контекста" (в контексте данного обсуждения конечно)?

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

В PL/SQL это так:

DECLARE                                    --это PL/SQL
  SomeVar NUMBER;                --это PL/SQL
BEGIN                                        --это PL/SQL
    SELECT                                 --а это уже SQL - switch context и парсим это выражение как SQL
        SomeField                        --SQL
    INTO                                    --SQL
        SomeVar                            --SQL
    FROM                                    --SQL
        SomeTable;                    --SQL
    IF SomeVar > 0 THEN        --а это снова PL/SQL  - switch context и снова парсим как PL/SQL
        NULL;                                --это PL/SQL
    END IF;                                --это PL/SQL
END;                                        --это PL/SQL

В гипотетическом C/SQL это могло бы выглядеть так:

{
    int SomeVar;                    //это С
    SELECT                                 //а это уже SQL - switch context и парсим это выражение как SQL
        SomeField                        //SQL
    INTO                                     //SQL
        SomeVar                            //SQL
    FROM                                    //SQL
        SomeTable;                    //SQL
    if (SomeVar > 0) {};    // а это снова C  - switch context и снова парсим как С
}

Извиняюсь за кривоту с комментами. Я ставлю Tab, а в превью идет замена на пробелы.

Здравствуйте, aston, Вы писали:

A>Давайте оставим стандарты в покое и посмотрим: какую роль имеют процедурные расширения того или иного сервера.
Ладно, давайте смотреть более абстрактно, в конце-концов брать какой-то конкретный язык это не совсем верно. Что ребуется от абстрактного реляционного хранилища данных? Уметь положить в реляционное хранилище, уметь взять из него и преобразовать в другой вид (попрежнему реляционный), посредством операторов реляционной алгебры. Все, требовать от хранилища чего-то большего смысла не имеет.
И в данном случае процедурное расширение — это метод работы с данными посредством операторов реляционной алгебры и ничего больше. Всем остальным, по идеологии MS занимается клиентский код и в этом смысле MS от чистого хранилища практически не отходил.

A>Ну в чем различие в их предназначении:
В том, что T-SQL работает только с реляционными данными и по другому не умеет, да и не должен.
Ява же работает с объектами, и для преобразования реляционных данных в объекты нужен хотя бы минимальный ORM. При этом непосредственно к данным обращается все равно SQL.
Ровно с тем же успехом все Яву можно использовать на клиенте, а вот SQL от сервера оторвать уже не полчится.

A>Почему Oracle так поступил? Я думаю, там следут логике, что дешевле и эффективнее обрабатывать данные там, где они хранятся, т.е. на сервере. А клиенту выдавать уже обработанный и подготовленный рзеультат.
А вот это уже очень и очень спорное утверждение. По крайней мере это верно далеко не всегда.

A>Просто Oracle наплевал на стандарты и ушел вперед и это надо признать. MS пока в роли догоняющего и ударными темпами мутит Yukon.
Как уже совершенно верно заметил TK, добавление Net в сервер, по большому счету, лишь дань моде и больше чем на сервис-пак не тянет, так же как и добавление версионности. При желании они могли бы сделать это гораздо раньше. К примеру, по непроверенным данным, добавление версионности обошлось просто-таки в смешное количество человеко-часов. Ну это так, к слову.
Вы правы в одном, MS действительно приходится догонять Оракл, но несколько в другом смысле, чем Вы думаете. Мне тут подкинули довольно интересную мысль и думаю, что в ней есть зерно истины.
Дело в том, что сейчас все прогрессивное человечество, в едином порыве, переползает на 64 разрядный Intel, и подобный переход довольно серьезно влияет на относительно высокоуровневые алгоритмы. У Oracle есть нехилый опыт написания под под подобную архитектуру на спарках, чего не скажешь про MS и даже, как говорят, про команду разработчиков DB2 UDB (хотя по идее уж IBM'ерам-то опыта не занимать).
Кстати, думаю, что по большей части именно в этом и кроется причина успеха 10g в tpc-c тестах, на фоне провального выступления девятки. Там уже давно 64 процессорные машины, и, судя по всему вовремя почуяв момент, Оракл воспользовался своим опытном и весьма удачно реализовал спарковские наработки.

A>Все это мое IMHO и переубеждать меня в этом безполезно.
Да я и не собираюсь..

с огромным интересом прочитал ваш ответ. много думал ...

но поскольку думал во сновном о всяких пошлостях все же решил перечитать ваш пост и знаете, понял что пост этот чо-то не несет информации

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

можно все таки хоть несколько аргументов, с учетом SQLJ
http://www.osp.ru/os/1999/09-10/061.htm
допустим sql
select count(*) from table
коренным образом отличается от
select myjavafunction(*) from table
т.к. ...


Gt_

Здравствуйте, <Аноним>, Вы писали:

А>с огромным интересом прочитал ваш ответ. много думал ...
Видимо не помогло..

А>можно все таки хоть несколько аргументов
Я все еще жду определения RDBMS.

Здравствуйте, Alexey_ch, Вы писали:

A_>Здравствуйте, Merle, Вы писали:

А>>>чо-то непонял этой возможности для T-SQL нет ? или инстрементария нет ?
M>>Я могу повторить еще раз, что T-SQL не предназначен для описания бизнес-логики.

A_>Т.е. в хранимых процедурах не бизнес логика? А что?

Physical two-tier implementation with a fat server
In a physical two-tier implementation with a fat server, business logic and presentation services are deployed from the server database. In this implementation, business logic is generally written as stored procedures and triggers within the database. For example, in the TPC-C benchmarks published for Microsoft SQL Server, the core transaction logic is coded as Transact–SQL stored procedures in the server. Many internally-developed corporate applications also make extensive use of stored procedure logic. Microsoft uses this implementation to handle internal business functions, such as customer information tracking.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsqlsg/html/msdn_designeff.asp

ну зачем заострять внимание, кому это интересно в этой ветке уже давно все поняли

Gt_

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, <Аноним>, Вы писали:

А>>с огромным интересом прочитал ваш ответ. много думал ...
M>Видимо не помогло..

А>>можно все таки хоть несколько аргументов
M>Я все еще жду определения RDBMS.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/architec/8_ar_cs_3jar.asp

только у меня просьба — подверждайте ссылками хотябы на МС

Relational Database Components
The database component of Microsoft® SQL Server™ 2000 is a Structured Query Language (SQL)–based, scalable, relational database with integrated Extensible Markup Language (XML) support for Internet applications. Each of the following terms describes a fundamental part of the architecture of the SQL Server 2000 database component:

Database

A database is similar to a data file in that it is a storage place for data. Like a data file, a database does not present information directly to a user; the user runs an application that accesses data from the database and presents it to the user in an understandable format.

Database systems are more powerful than data files in that data is more highly organized. In a well-designed database, there are no duplicate pieces of data that the user or application must update at the same time. Related pieces of data are grouped together in a single structure or record, and relationships can be defined between these structures and records.

When working with data files, an application must be coded to work with the specific structure of each data file. In contrast, a database contains a catalog that applications use to determine how data is organized. Generic database applications can use the catalog to present users with data from different databases dynamically, without being tied to a specific data format.

A database typically has two main parts: first, the files holding the physical database and second, the database management system (DBMS) software that applications use to access data. The DBMS is responsible for enforcing the database structure, including:

Maintaining relationships between data in the database.


Ensuring that data is stored correctly, and that the rules defining data relationships are not violated.


Recovering all data to a point of known consistency in case of system failures.
Relational Database

Although there are different ways to organize data in a database, relational databases are one of the most effective. Relational database systems are an application of mathematical set theory to the problem of effectively organizing data. In a relational database, data is collected into tables (called relations in relational theory).

A table represents some class of objects that are important to an organization. For example, a company may have a database with a table for employees, another table for customers, and another for stores. Each table is built of columns and rows (called attributes and tuples in relational theory). Each column represents some attribute of the object represented by the table. For example, an Employee table would typically have columns for attributes such as first name, last name, employee ID, department, pay grade, and job title. Each row represents an instance of the object represented by the table. For example, one row in the Employee table represents the employee who has employee ID 12345.

When organizing data into tables, you can usually find many different ways to define tables. Relational database theory defines a process called normalization, which ensures that the set of tables you define will organize your data effectively.



Structured Query Language

To work with data in a database, you have to use a set of commands and statements (language) defined by the DBMS software. Several different languages can be used with relational databases; the most common is SQL. The American National Standards Institute (ANSI) and the International Standards Organization (ISO) define software standards, including standards for the SQL language. SQL Server 2000 supports the Entry Level of SQL-92, the SQL standard published by ANSI and ISO in 1992. The dialect of SQL supported by Microsoft SQL Server is called Transact-SQL (T-SQL). T-SQL is the primary language used by Microsoft SQL Server applications.

Extensible Markup Language

XML is the emerging Internet standard for data. XML is a set of tags that can be used to define the structure of a hypertext document. XML documents can be easily processed by the Hypertext Markup Language, which is the most important language for displaying Web pages.

Although most SQL statements return their results in a relational, or tabular, result set, the SQL Server 2000 database component supports a FOR XML clause that returns results as an XML document. SQL Server 2000 also supports XPath queries from Internet and intranet applications. XML documents can be added to SQL Server databases, and the OPENXML clause can be used to expose data from an XML document as a relational result set.


Gt_

Здравствуйте, <Аноним>, Вы писали:

А>только у меня просьба — подверждайте ссылками хотябы на МС
Я не просил описания что такое MSSQL, я просил определение RDBMS и, в частности, что в Вашем понимании означает термин Relation.

Здравствуйте, Alexey_ch, Вы писали:

A_>Т.е. в хранимых процедурах не бизнес логика? А что?
http://www.rsdn.ru/forum/Message.aspx?mid=501767&amp;only=1

Автор: Merle
Дата: 09.01.04

Здравствуйте, <Аноним>, Вы писали:

А>ну зачем заострять внимание, кому это интересно в этой ветке уже давно все поняли
Вот уж действительно, сложно не согласиться.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, <Аноним>, Вы писали:

А>>только у меня просьба — подверждайте ссылками хотябы на МС
M>Я не просил описания что такое MSSQL, я просил определение RDBMS и, в частности, что в Вашем понимании означает термин Relation.

ну ... вы меня разочаровываете, зачем нам демагогия или мое понимае или чем то источник msdn не подходит ? так мы его запросто сменим на оракловый мы сравниваем 2 конкретные СУБД, я человек наивный — безрасудно верю M$ и Oracle ... вот МС огласило, что по их мнению входит в Relational Database Components, они врут ?
нет ? тогда может тут кто-то (не будем говорит кто хотя это был кролик (С) Винни Пух) тут чо-то нетого ?

итак давайте соберемся и ответим гнусным анонимусам не трогая бедалагу Кодда !

Gt_

Здравствуйте, Merle, Вы писали:
M>В том, что T-SQL работает только с реляционными данными и по другому не умеет, да и не должен.
M>Ява же работает с объектами, и для преобразования реляционных данных в объекты нужен хотя бы минимальный ORM. При этом непосредственно к данным обращается все равно SQL.
M>Ровно с тем же успехом все Яву можно использовать на клиенте, а вот SQL от сервера оторвать уже не полчится.
Ну, зерно поинта суть в том, что все-таки T-SQL ежели честно позиционируется как язык для написания BL. Увы, в настоящее время ограничиться только хранением состояния (например реляционной алгеброй) могут себе позволить только академические СУБД. Промышленное производство требует возможности реализовывать поведение в рамках СУБД. Именно это давление привело к появлению зоопарка процедурных расширений SQL. Когда-то даже триггеры были страшной экзотикой .
Причины очевидны — недостатки чистой клиент-серверной модели видны невооруженным глазом.
Отлично, ребята, если ваше приложение на Delphi начинает неприлично распухать — нет проблем, ставтье Middle-tier и все в порядке. "Но я ведь всего лишь хотел сделать так, чтобы при вставке итема в ордер пересчитывалась сумма ордера...". Те производители СУБД, которые встроили поддержку триггеров, резко вырвались вперед — с точки зрения движка, это почти ничего не стоит. Зато пользователю не нужно удваивать стоимость системы путем приобретения среднего слоя. Кроме того, теперь можно учить на один язык меньше.
В настоящее время мы имеем ту же ситуацию. Некоторые производители СУБД встраивают поддержку языков общего назначения, чтобы стать "ближе к народу". Действительно, все эти диалекты SQL со страшной силой сливают языкам общего назначения там, где требуется функциональность м... общего назначения . Несмотря на то, что все то же самое можно реализовать в клиенте/среднем слое, и, как правило, без особой потери производительности, а на крайний случай всегда есть доступ изнутри СУБД к внешнему коду, эта неожиданная мутация сервера хранения представления в сервер реализации поведения является неизбежным следствием тенденций индустрии.
Кстати, заявки MS на этом фронте выглядят очень и очень неплохо. Дело в том, что .NET заранее обложился кастом-метаданными, которые могут позволить объединить лучшие черты оптимизаторов реляционных запросов с оптимизацией языков общего назначения. Теоретически уже сейчас видны намеки на то, каким образом они смогут обеспечить более высокую эффективность применения встроенного CLR кода по сравнению с 3-tier и импортами из DLL (расходы на коммуникацию и "переключение контекста" в расчет не берем — ребята, на практике это фикция. Траблы начинаются ровно в том, что дата-сервер знает всё об особенностях хранения данных, апп-сервер — об особенностях поведения объектов, но пока язык общения между ними ограничен SQL, суммарный результат не будет идеальным. Сервер данных вынужден делать ровно то, что ему говорят, (а мог бы и соптитмизироваться, если бы знал зачем ему это говорят), а апп-сервер вынужден говорить все это (а мог бы соптимизироваться, если бы знал, что там "внизу"))
Я с большим интересом жду выхода MS SQL Server 9.0 final или публикации его результатов на www.tpc.org (whaterver comes first). Там мы посмотрим, чей сахар слаще — джава в Oracle или C# в Yukon

Здравствуйте, Sinclair, Вы писали:

S>Ну, зерно поинта суть в том, что все-таки T-SQL ежели честно позиционируется как язык для написания BL. Увы, в настоящее время ограничиться только хранением состояния (например реляционной алгеброй) могут себе позволить только академические СУБД.
Ну позиционировать-то они его могут как угодно, но реально за рамки реляционной алгебры T-SQL далеко не выполз, да и не смог бы. Естественно низкоуровневая часть БЛ реализуется на уровне SQL'я, но основная часть все равно ложится на клиента.
А вот введение ОО языка в БД для обработки данных — это уже качественный выход из рамок чистой БД.

S>Отлично, ребята, если ваше приложение на Delphi начинает неприлично распухать — нет проблем, ставтье Middle-tier и все в порядке. "Но я ведь всего лишь хотел сделать так, чтобы при вставке итема в ордер пересчитывалась сумма ордера...". Те производители СУБД, которые встроили поддержку триггеров, резко вырвались вперед — с точки зрения движка, это почти ничего не стоит.
Ну вот здесь-то по большому счету триггеры и не нужны. Да и сами по себе триггеры не выходят за границы "просто БД", все-таки работа идет с реляционными данными, и тут все "по честному".

S>В настоящее время мы имеем ту же ситуацию. Некоторые производители СУБД встраивают поддержку языков общего назначения, чтобы стать "ближе к народу".
Вообщем-то да, но это качественно другой уровень. А в целом согласен.

Здравствуйте, <Аноним>, Вы писали:

А>ну ... вы меня разочаровываете, зачем нам демагогия или мое понимае
А зачем мы тогда вообще здесь время теряем?

А>нет ? тогда может тут кто-то (не будем говорит кто хотя это был кролик (С) Винни Пух) тут чо-то нетого ?
Тем более, зачем мы здесь теряем время на Ваш искрометный юмор?

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

Здравствуйте, Merle, Вы писали:
M>Ну позиционировать-то они его могут как угодно, но реально за рамки реляционной алгебры T-SQL далеко не выполз, да и не смог бы.
Merle мне друг, но истина дороже Операторы ветвления, циклы, введение переменных и операции с курсорами — это все процедурное программирование (as opposed to декларативный SQL). Равно как и ХП и оператор execute. Увы и ах.
M>А вот введение ОО языка в БД для обработки данных — это уже качественный выход из рамок чистой БД.
Неа. Это качественный выход из рамок процедурного сервера приложений
M>Ну вот здесь-то по большому счету триггеры и не нужны. Да и сами по себе триггеры не выходят за границы "просто БД", все-таки работа идет с реляционными данными, и тут все "по честному".
Неа. Путем триггеров наша СУБД имеет наглость обладать поведением. Вместо того, чтобы чисто хранить то, что в нее положили. Упс.
M>Вообщем-то да, но это качественно другой уровень.
Можно и так сказать. Хотя я как-то больше склоняюсь к тому, что это скорее количественное изменение. Уж очень там ОО ограничено.

Здравствуйте, Merle, Вы писали:

M>Я все еще жду определения RDBMS.

Кстати, это еще в будущем, о чем я сейчас собираюсь сказать, для нас разработчиков. Но у нас будет неплохой шанс очень приятно и свободно использовать Оракл как Объектную БД. На сегодняшний день уже восьмерка стала Объектно-Реляционной БД. И появление Java далеко не случайность. Уже есть смысл спрашивать определение ORDBMS.

Здравствуйте, theOne, Вы писали:

O> Но у нас будет неплохой шанс очень приятно и свободно использовать Оракл как Объектную БД. На сегодняшний день уже восьмерка стала Объектно-Реляционной БД.
Не думаю, по крайней мере не в ближайшее время. Есть вполне объективные причины того, что не смотря на победное шествие ОО по всей планете, реляционные БД не собираются сдавать свои позиции.

O>И появление Java далеко не случайность. Уже есть смысл спрашивать определение ORDBMS.
Для начала надо определиться с тем, что такое ОО, а потом уже приплести к этому DBMS и, возможно, R. На сколько мне известно даже четкого определения, что такое ОО, по сути не существует, все интуитивно понимают, что это такое, но сформулировать никто не может.

Здравствуйте, Sinclair, Вы писали:

S>Merle мне друг, но истина дороже


S>Операторы ветвления, циклы, введение переменных и операции с курсорами — это все процедурное программирование (as opposed to декларативный SQL). Равно как и ХП и оператор execute. Увы и ах.
Ок, сойдемся на том, что истина посередине. Признаю, что немного увлекся теоретизированием, глупо было бы отрицать, что T-SQL не чисто декларативный язык. Но опять-таки далеко оттуда он не уполз.

S>Неа. Это качественный выход из рамок процедурного сервера приложений
Хм... Чур меня. Это выход из рамок БД, умеющей интеллектуально распихивать данные по табличкам (можно конечно назвать это процедурным app-сервером, но я бы не стал ). Причем именно данные, а не объекты. Для такой БД из объектов данные делает тот дядька..

S>Неа. Путем триггеров наша СУБД имеет наглость обладать поведением. Вместо того, чтобы чисто хранить то, что в нее положили. Упс.
Ну я ж говорю, интеллектуальное хранение того, что в нее положили. Из рамок реляционного хранилища это не вылезает.

Вообще все эти границы очень и очень размыты. Никогда нельзя сказать на сто процентов: "вот здесь у меня data layer, здесь business, а здесь presentation". Но более-менее акценты расставить можно.
В app-БД business уровень смещен в сторону хранилища, в "чистой" же БД, как правило, необходимо наличие ярковыраженного среднего слоя.

Здравствуйте, theOne, Вы писали:

O>Здравствуйте, Merle, Вы писали:

M>>Я все еще жду определения RDBMS.

O>Кстати, это еще в будущем, о чем я сейчас собираюсь сказать, для нас разработчиков. Но у нас будет неплохой шанс очень приятно и свободно использовать Оракл как Объектную БД. На сегодняшний день уже восьмерка стала Объектно-Реляционной БД. И появление Java далеко не случайность. Уже есть смысл спрашивать определение ORDBMS.
Ребята, возможность объявить статический метод класса хранимой процедурой не делает из RDBMS ODBMS. Вот когда будет работать что-то типа
Select from * where IAmountable.Amount() > 100.0 and ISecuredObject.AllowsAccess((Context.User as Employee).Manager)
можно будет вернуться к этому разговору.