Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
GG2
Guest
gardenman
2 Ggg_old

некоторые оговорки
Вложенный SQL плохо (отвратительно) реализован в MSSQL, Sybase ASE, PostgreSQL, MySQL(нет вообще). Про Sybase ASA - ничего не могу сказать (не смотрел) но думаю ASA не далеко ушла от ASE. Относительно приемлемо реализован а Oracle, и нормальня реализация - только в DB2.
Раз не можете сказать, так и не говорите.
11 апр 05, 14:59    [1457510]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
а мааааленький такой пример кода приведи?...
11 апр 05, 15:00    [1457517]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
Хитый портняжка
Guest
gardenman

Вложенный SQL плохо (отвратительно) реализован в MSSQL, Sybase ASE, PostgreSQL, MySQL(нет вообще). Про Sybase ASA - ничего не могу сказать (не смотрел) но думаю ASA не далеко ушла от ASE. Относительно приемлемо реализован а Oracle, и нормальня реализация - только в DB2.

Что за хрень?! А почему, к примеру, про InterBase не упомянули? Там тоже разбираться нужно, сразу не запустишь! :))
11 апр 05, 15:12    [1457566]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
к сожалению ни разу в жизни FB или Интербейз не ставил... руки не дошли.
11 апр 05, 15:17    [1457603]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
gardenman
а мааааленький такой пример кода приведи?...

MyProc.Parameters.ParamValue['@i']:=i;
MyProc.ExecSQL;
i:=MyProc.Parameters.ParamValue['@i'];
пойдёт?
11 апр 05, 17:01    [1458190]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
не-а не пойдет... приведи примерчик полностью, как полагается, с объявлением переменных (их типов), с возвратом итоговой выборки...
чтоб был полностью весь код виден. Я ж тоже могу написать:
Par=10;
EXEC SQL CALL MyProc(:Par);
Не страшнее вашего получится.
Реально - нужен примерчик покрупнее. Чтоб было что сравнивать. Мне что, придумать тестовое задание что-ли?...
11 апр 05, 17:16    [1458266]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
Хитрый портняжка
Guest
Ну, тебе и привели код. Что, нужно было указать объявление TADOStoredProc?
Инициализацию его, причем обязательно в рантайме?

Или код коннекта к базе? Или сам код ХП? Или весь фреймворк - со схемой организации доступа клиента к базе?

Я могу привести тебе код работы в ECO:
 MyECOSystem.Active := true; // Это коннект к базе
 fMyClass.Attr_Name := 'Первый атрибут'; // Вот занесли значение атрибута в объект
 tmpString := fMyClass.Attr_Name // Вот занесли извлекли значение атрибута объекта

 MyECOSystem.update; // Вот апдейт в persistemce - область

 MyECOSystem.Active := falsa; // Это дисконнект
И все. Или нужно переменные объявлять/классы генерить/инициализировать атрибуты? Что ты хочешь-то?
11 апр 05, 17:33    [1458323]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
не-а не пойдет... приведи примерчик полностью, как полагается, с объявлением переменных (их типов), с возвратом итоговой выборки...
чтоб был полностью весь код виден.

Это и есть весь код :))
Это же Дельфи - там все само делается, компонентами :))
Ну еще я перед этим в свойство sql пропишу:
exec MyStoredProc :i, :Name
А потом уже
MyProc.ParamByName['i'].asinteger := 1;
MyProc.ParamByName['Name'].asstring := 'Вася';
MyProc.Open;
--или еще можно так:
MyProc.ExecSQL;
Вот и все. Чего еще?
Чего там, в MyStoredProc, делается, клиента не касается.


-- Tygra's --
11 апр 05, 17:35    [1458334]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Кто-нить покажет как в дельфях проволятся операции с блобами?
Ну там - вставить в табличку запись с полем BLOB или вытащить?
11 апр 05, 18:06    [1458476]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Ну вытащить то каие проблемы? Пиши в select нужное поле - оно и приедет в Дельфу. Дальше делай, чего хочешь.

А если сохранить на сервер, то вот тут: Как добавить картинку в базу данных?

-- Tygra's --
11 апр 05, 18:13    [1458508]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
gardenman
Кто-нить покажет как в дельфях проволятся операции с блобами?
Ну там - вставить в табличку запись с полем BLOB или вытащить?

Т.е. насчет передачи обычных переменных через параметры Вы убедились что сложностей нет?

Про БЛОБы ничего не могу сказать, не работал, но думаю и там не намного больше писать
11 апр 05, 18:25    [1458535]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Однако как апетиты растут :)

15:00
gardenman
А каким образом передаются параметры для ХП? а каким образом возвращаются?
а мааааленький такой пример кода приведи?...


17:16
gardenman
Реально - нужен примерчик покрупнее. Чтоб было что сравнивать. Мне что, придумать тестовое задание что-ли?...


18:06
gardenman
Кто-нить покажет как в дельфях проволятся операции с блобами?
Ну там - вставить в табличку запись с полем BLOB или вытащить?
11 апр 05, 18:30    [1458551]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
2 SergSuper
Та какие там апетиты?))...
11 апр 05, 18:35    [1458566]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
Ggg_old
Guest
2gardenman:
Промежуточный итог.
Если с БД можно работать в стиле
TDatabase.connect
TQuery.SQL="select ..."
a=TResultSet.Field['field_name']
Причем без разницы, как будет называться фреймворк, который обеспечивает это (BDE, ADO), то ни один разработчик не будет работать с БД в стиле:
-написать промежуточный cxx код
-прогнать его через макрокомпилятор
-почитсить глюки с помощью батничка
-забинидить bnd файл на SQL сервер
и.т.д как вы написали в
[url=http://]www.sql.ru/forum/actualthread.aspx?tid=91031[/url]

Когда я предлагал создать этот топик очень надеялся, что появится человек, который объяснит инженерным языком, в каких случаях и на каких задачах более сложное программирование на EmbedSQL оправдано. Я действительно не понимаю, зачем писать на EmbedSQL, при наличии более человеческого способа работы с базой. И судя по всему остальный считают также (ИМХО).
11 апр 05, 18:49    [1458601]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
NewYear
Member

Откуда: Большой адронный коллайдер
Сообщений: 2203
two-phase транзакции можно писать на этом вашем ADO?

например, я хочу записать 1 строку в DB2, одну в Oracle, одну в MSSQL, ну и так далее, в одной транзакции. Например, с TXSeries.
на ESQL я этот трюк делал.
11 апр 05, 20:21    [1458765]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Есть еще одна фича в ESQL. Она называется COMPOUND SQL. Это нечто среднее между SQL c рабочей станцией и хранимой процедурой.
11 апр 05, 20:58    [1458795]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
NewYear
two-phase транзакции можно писать на этом вашем ADO?

например, я хочу записать 1 строку в DB2, одну в Oracle, одну в MSSQL, ну и так далее, в одной транзакции. Например, с TXSeries.
на ESQL я этот трюк делал.


И кто координатором распределённой транзакции выступал?
11 апр 05, 23:13    [1458939]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
gardenman
Есть еще одна фича в ESQL. Она называется COMPOUND SQL. Это нечто среднее между SQL c рабочей станцией и хранимой процедурой.


Если ESQL реализуется посредством препроцесоора, то кто помешает выполнить ту же задачу без препроцессора, с использованием любой технодогии доступа к СУБД?
11 апр 05, 23:16    [1458945]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
c127
Guest
2 gardenman

>Вложенный SQL плохо (отвратительно) реализован в MSSQL, Sybase ASE, PostgreSQL, MySQL(нет вообще). Про Sybase ASA - ничего не могу сказать (не смотрел) но думаю ASA не далеко ушла от ASE. Относительно приемлемо реализован а Oracle, и нормальня реализация - только в DB2.

А поподробнее можно? Я работал с вложенным скл-ем в АСА, постгре, оракле и ДБ2, правда не очень много, и существенных различий не обнаружил.

Как мне показалось тут основная проблема проблема не в СКЛ сервере, а в проблемах реализации связки СКЛ<->процедурный_язык, в данном случае С. Кстати та же проблема в языках типа Т-СКЛ: все хорошо пока не начинаешь работать с курсорами.
12 апр 05, 04:50    [1459126]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Ggg_old
Когда я предлагал создать этот топик очень надеялся, что появится человек, который объяснит инженерным языком, в каких случаях и на каких задачах более сложное программирование на EmbedSQL оправдано. Я действительно не понимаю, зачем писать на EmbedSQL, при наличии более человеческого способа работы с базой. И судя по всему остальный считают также (ИМХО).

ESQL очень даже удобно, код гораздо читабельней, чем через компоненты, плюс во время его компиляции ESQL сразу же проверяется на сервере, параметры легко передавать, получать прямо в переменные, обьявленные в коде, легко вызывать ХП, организовывать локальные курсоры по полученным наборам данных с запросов и ХП, и т.д. Все это, например, есть в PowerBuilder, причем в нем ESQL не заточен под определенную СУБД, а работает под поднятой сверху сессией/сессиями, которые могут идти через ODBC, ADO, OLEDB, ADO.NET, JDBC, ...

gardenman
Вложенный SQL плохо (отвратительно) реализован в MSSQL, Sybase ASE, PostgreSQL, MySQL(нет вообще). Про Sybase ASA - ничего не могу сказать (не смотрел) но думаю ASA не далеко ушла от ASE. Относительно приемлемо реализован а Oracle, и нормальня реализация - только в DB2.

Сам я с реализацией ESQL в ASA не работал, так как считаю дурным тоном рисовать клиентские мордочки на C, но думаю что судя по описаниям ESQL и примерам кода в BOL, его реализация в ASA более чем удовлетворительная ;)
12 апр 05, 06:04    [1459154]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
tygra
Это же Дельфи - там все само делается, компонентами :))


Не надо о грустном Тут маааленький UDP сервер писал на Delphi. После этого решил для себя больше никогда не использовать эти клятые компоненты. Легче самому с WinSock-ом работать.
12 апр 05, 08:03    [1459253]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
protector
Member

Откуда: Иваново, Россия
Сообщений: 600

Gluk (Kazan)

Не надо о грустном Тут маааленький UDP сервер писал на Delphi. После этого решил для себя больше никогда не использовать эти клятые компоненты. Легче самому с WinSock-ом работать.

Правильно! Это же ДЕЛФИ. Тут каждый делает как ему нравится.


Posted via ActualForum NNTP Server 1.1

12 апр 05, 09:37    [1459485]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
2 c127
>А поподробнее можно? Я работал с вложенным скл-ем в АСА, постгре, оракле и ДБ2, правда не очень много, и существенных различий не обнаружил.

Различия очень существенные. Особенно это касается где и как объявлять хост - переменные. Например в DB2 это могут быть ссылки и указатели, которые могут быть членами классов.
К тому же, результат обработки препроцессором - совершенно разный. Где-то просто получается динамический SQL (PostgreSQL) а где-то - хранимая процедура специфического вида (Sybase ASE). У DB2 (как правило) - получается статический SQL с уже предопределенным планом запроса. Скорость выполнения выше в разы. Вот и получается, что статический SQL помноженный на производительность C++ - дает бешенную производительность.
12 апр 05, 10:14    [1459695]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
NewYear
Member

Откуда: Большой адронный коллайдер
Сообщений: 2203
>И кто координатором распределённой транзакции выступал?
TXSeries
12 апр 05, 10:39    [1459812]     Ответить | Цитировать Сообщить модератору
 Re: Подходы к созданию приложений для СУБД: Embedded SQL против других способов  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
gardenman
У DB2 (как правило) - получается статический SQL с уже предопределенным планом запроса. Скорость выполнения выше в разы. Вот и получается, что статический SQL помноженный на производительность C++ - дает бешенную производительность.

Вы уже не впервый раз сохранение плана запроса при компиляции ХП выдаете за этакое преимущество, что вот мне совершенно не понятно. Есть у меня БД девелоперов, она находится в разработке и содержит достаточно небольшое кол-во тестовых данных, охватывающих различные аспекты ТЗ с целью наиболее удобного тестирования бизнес-логики. После проведения изменений в ней корректирующие SQL скрипты уходят на консолидированную БД с требованием выполнится на ней и всех удаленных узлах (БД). Естественно консолидированная БД содержит информацию всех узлов. Далее после проведения сеанса репликации каждый удаленный узел так же получает корректирующий скрипт и выполняет его, помимо обычного сеанса приема/передачи изменений данных. Узлов у нас например 500. Все идут через оффлайн (почта, ftp, файловый обмен - без разницы). На каждом узле информация, принадлежащая только ему. Соотвествующе на одном узле большая БД, на другом крохотная, на одном например стоит навороченный сервер под UNIX, на другом обычный PC с W2K Prof. Внимание вопрос - это интересно как же это при компиляции ХП на девелоперской БД с учетом ее "левых" данных мы обеспечим бешеную производительность для консолидированной БД и ее удаленных узлов ? Божьим духом, принудительной перекомпиляций скриптом или запиской для "опытных" пользователей - типа войди и перекомпилируй и будет тебе счастье (причем на Си) ?

Мне кажется привязка планов к ХП есть зло, нормальная РСУБД должна сама соображать, какие планы для текущей БД на текущей момент времени оптимальны, автоматом вести статистику, корректируя ее по мере необходимости, наилучшие планы запросов не только кидать в кэш, но и записывать с кешем в БД для быстрого их подьема для быстрого рестарта сервера, а так же иметь эвристический анализатор, у которого хватает ума усомнится в актуальности "наилучших" планов и не поленится заново понастроить планы и сравнить их с используемыми, чтобы в случаях резкого изменения содержания информации (например массовый подлив данных), не просесть в лужу. Во всяком случае в Sybase ASA все это делается автопилотом, если у меня оптимизатор правильно "понимает" как я связываю в сложных запросах и в наличие удобные индексы, то это его уже проблемы, какие он планы будет строить и что там будет использоваться.

Кстати все вышесказанное к Sybase ASA в полной мере относится и к серверу Sybase IQ, который в отличие от ASA, заточеннуб для SMB, "ориентирован" на нулевое администрирование аналитических БД больших обьемов.

Так что пожалуйста уж поясните свои высказывания, почему круто писать ХП на Си, да еще и компилировать прямо в них планы запросов ? В плане скорости я отметаю сразу - в ASA например планы ХП компилируются при первом к ним обращении после запуска сервера (если их еще нет в сохраненном кэше), причем они не привязываются к ХП, а висят как просто планы к запросам, которые вызываются в том числе и из ХП. Время построения плана запросов занимает миллисекунды (если конечно не вывести уровень компиляции с нормального 9-ого уровня на максимальный 15, что уже будет соотвествовать полному перебору всех возможных видов планов запросов) - так что проблем со скоростью построения планов лично я ни разу не наблюдал, у Watcom всегда были неплохие скорости в различных решениях :)
12 апр 05, 11:56    [1460226]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить