Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 14   вперед  Ctrl
 Re: использование хранимых процедур  [new]
Yo.!
Guest
DPH3

Ну, моя любимая БД - это IBM DB2. Самый развитый SQL и осознание потребностей трехзвенок :)
Oracle, похоже, по привычке считает, что все приложения - двухзвенные.


все проще, в оракле pl/sql уже лет 20 развивается и одна конструкция pl/sql часто и густо заменяет десяток строк любого языка апп-сервера. а то, что фаны дб2 любят трехзвенки - не секрет. аналог pl/sql там только появился, а до этого код на сервере приходилось реализовывать дедовским способом типа чистого С или кабола. sql/pl в db2 практически никто не использует, оно и понятно, разбираться в новом языке, который имеет лишь базовые конструкции и тучу нюансов при переносе на другую платформу никому не хочется. действительно проще взять какой-нить хибер и ипать мозг.
29 окт 09, 17:02    [7857915]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
barrabas
Member

Откуда: от махмуда
Сообщений: 10530
baracs
Э, а что, у вас каждый пользователь системы имеет отдельную учетную запись в БД? И авторизуется прямо в БД?

У нас да, БД доверяет авторизации ОСи.
29 окт 09, 17:04    [7857930]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
iscrafm
Рекомендую в материалах APIS этот вопрос посмотреть.

APICS конечно же имеется ввиду
29 окт 09, 17:05    [7857934]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
barrabas
Member

Откуда: от махмуда
Сообщений: 10530
barrabas
baracs
Э, а что, у вас каждый пользователь системы имеет отдельную учетную запись в БД? И авторизуется прямо в БД?

У нас да, БД доверяет авторизации ОСи.

на юзеров права и навешиваются.
На предыдущей работе были юзеры в таблице, и таблица с правами, а коннект под одним. По разному бывает. Сейчас, например, не нужно вставлять проверки кругом на право доступа к объекту.
29 окт 09, 17:07    [7857960]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
baracs
Member

Откуда: Москва
Сообщений: 7219
barrabas
baracs
Э, а что, у вас каждый пользователь системы имеет отдельную учетную запись в БД? И авторизуется прямо в БД?

У нас да, БД доверяет авторизации ОСи.

У нас тоже
То не я писал.
29 окт 09, 17:08    [7857973]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
DPH3
Guest
iscrafm

Это я к тому, что если Вы знаете внутренности MRP, то наверняка помните, что он конечно большой, но состоит из цепочки таких примитивов. Рекомендую в материалах APIS этот вопрос посмотреть. Из моих настольных книг в 90-е - Ландватер. Этот учебник хорош тем, что не изобилует ненужной в данном вопросе математикой, а обучает тому же самому с точки зрения пошаговой логики, которая прекрасно ложится на реляционную модель. Переводы лучше не читать, путаница в терминах и половина материала покоцана.


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

И пользователи, увы, очень любят добавлять свои эвристики и доработки алгоритмов планирования - так что все равно приходится алгоритмику генерации планов (с оптимизациями) делать очень гибкой.
Это все делается, конечно - но чистым DML не обойтись, приходится использовать хранимки, T-SQL и т.п.

P.S. А еще есть кошмар скользящего среднего и оптимизации закупок с выбором окна расчета скольжения. В общем, на любом универсальном языке это бы писалось на порядок проще и работало бы за миллисекунды.
29 окт 09, 17:09    [7857981]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
Yo.!
Guest
DPH3

И пользователи, увы, очень любят добавлять свои эвристики и доработки алгоритмов планирования - так что все равно приходится алгоритмику генерации планов (с оптимизациями) делать очень гибкой.
Это все делается, конечно - но чистым DML не обойтись, приходится использовать хранимки, T-SQL и т.п.

т.е. здесь у нас трехзвенка, здесь чуток хранимок, а это мы рыбу заворачивали
интересный подход.
29 окт 09, 17:14    [7858021]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
DPH3
Guest
Yo.!

все проще, в оракле pl/sql уже лет 20 развивается и одна конструкция pl/sql часто и густо заменяет десяток строк любого языка апп-сервера. а то, что фаны дб2 любят трехзвенки - не секрет. аналог pl/sql там только появился, а до этого код на сервере приходилось реализовывать дедовским способом типа чистого С или кабола. sql/pl в db2 практически никто не использует, оно и понятно, разбираться в новом языке, который имеет лишь базовые конструкции и тучу нюансов при переносе на другую платформу никому не хочется. действительно проще взять какой-нить хибер и ипать мозг.


Ну, Yo!, это же не серьезно, сам же все знаешь.
И что хранимки на DB2 писались (давно) на C, потом еще на пяти языках (включая какой-то PLSQL подобный), сейчас вообще реализовали оракловый PL/SQL (приделанный по просьбе мигрирующих с Оракла).
Впрочем, идеология DB2, насколько я понимаю, изначально предполагала, что бизнес-логику пишут на подходящем языке, вставляя туда SQL-операторы. Может быть и вызывая этот код прямо в контексте сервера - это уж как кому надо :)

Кстати, а чем PL/SQL мощнее какой-нибудь Java? Приведи пример.

P.S. Хибернейт (как и прочие ORM) - это зло. По крайней мере при высокой нагрузке.
29 окт 09, 17:16    [7858054]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
DPH3
Guest
Yo.!

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


В том проекте, где я делал MRP - увы, никакой трехзвенки, обычный клиент-сервер.
Это было уже лет шесть назад, что-ли. Еще MS SQL 2000...
Пара сотен таблиц (только на один модуль), тысячи хранимок. Ностальгия, переходящая в кошмар.
29 окт 09, 17:18    [7858077]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
barrabas
Member

Откуда: от махмуда
Сообщений: 10530
DPH3

Кстати, а чем PL/SQL мощнее какой-нибудь Java? Приведи пример.

в большинстве случаев кода меньше. ну и всякие bulk collect и forall, потом синтаксис проще (не нужно создавать объекты типа sqlcommand (или как он там уже) и биндить переменные) , а просто писать sql в процедуре и все.

Но многие вещи конечно удобнее сделать в яве или вообще нельзя в pl/sql.
29 окт 09, 17:23    [7858127]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
DPH3
Guest
barrabas
baracs
Э, а что, у вас каждый пользователь системы имеет отдельную учетную запись в БД? И авторизуется прямо в БД?

У нас да, БД доверяет авторизации ОСи.

Интранет?
Корпоративная система?
Небольшое число пользователей?

Просто у меня в последних проектах (что накладывает отпечаток, угу), число пользователей системы далеко за 100K...
Там все равно авторизацию на уровне БД не сделать.

Впрочем, в моих корпоративных системах тоже регулярно нужны были гибкие права, всяческие ограничения на колонки и отдельные строки по хитрым алгоритмам, так что средствами БД это не реализовать (ну, может быть через Oracle Vault, но слишком он дорого стоит).
29 окт 09, 17:28    [7858191]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
DPH3
Впрочем, в моих корпоративных системах тоже регулярно нужны были гибкие права, всяческие ограничения на колонки и отдельные строки по хитрым алгоритмам, так что средствами БД это не реализовать (ну, может быть через Oracle Vault, но слишком он дорого стоит).


М.б. просто не умеете?!
29 окт 09, 17:31    [7858223]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
barrabas
Member

Откуда: от махмуда
Сообщений: 10530
DPH3
barrabas
baracs
Э, а что, у вас каждый пользователь системы имеет отдельную учетную запись в БД? И авторизуется прямо в БД?

У нас да, БД доверяет авторизации ОСи.

Интранет?
Корпоративная система?
Небольшое число пользователей?

Просто у меня в последних проектах (что накладывает отпечаток, угу), число пользователей системы далеко за 100K...
Там все равно авторизацию на уровне БД не сделать.

Впрочем, в моих корпоративных системах тоже регулярно нужны были гибкие права, всяческие ограничения на колонки и отдельные строки по хитрым алгоритмам, так что средствами БД это не реализовать (ну, может быть через Oracle Vault, но слишком он дорого стоит).

ясно что не инет,
Сайт - один юзер, конечно.
29 окт 09, 17:32    [7858228]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
DPH3
Guest
barrabas

в большинстве случаев кода меньше. ну и всякие bulk collect и forall,

Ну, тут бы я поспорил, сильно зависит от языка и задачи. Например, наследование и лямбды позволяют написать очень компактные алгоритмы :)


потом синтаксис проще (не нужно создавать объекты типа sqlcommand (или как он там уже) и биндить переменные) , а просто писать sql в процедуре и все.

Тут конечно :) Хотя если отделить DAO от BL в коде, то особо сложности синтаксиса не видишь.
Ну и если использовать всяческий DB2 embedded sql, то там запросы тоже пишутся прямо в коде и биндинг не нужен(а потом работает препроцессор). Правда, я таким не пользовался :)

А вообще, у меня как-то в последнее время число запросов к БД (различных) все сокращается и сокращается. Даже если сложная логика, сложные данные, разнообразная обработка - удается обходиться очень компактным DAO layer. И вряд ли это следствие задач - задачи то довольно разные (правда, почти все с приличной нагрузкой).
29 окт 09, 17:39    [7858287]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
DPH3
Guest
pkarklin
DPH3
Впрочем, в моих корпоративных системах тоже регулярно нужны были гибкие права, всяческие ограничения на колонки и отдельные строки по хитрым алгоритмам, так что средствами БД это не реализовать (ну, может быть через Oracle Vault, но слишком он дорого стоит).


М.б. просто не умеете?!


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

БД - ну, например, Oracle 10.1
29 окт 09, 17:47    [7858362]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
DPH3
А еще есть кошмар скользящего среднего и оптимизации закупок с выбором окна расчета скольжения. В общем, на любом универсальном языке это бы писалось на порядок проще и работало бы за миллисекунды.

работало бы, писалось бы...
а в чем разница между 1с и 1мс при подобном планировании? Мы же не MES реального времени говорим. Конечно, некоторые фрагменты среднего слоя используют и тот же T-SQL, если требуется.
например:
+ старый MS SQL2000

BEGIN TRAN

DECLARE
        @ITEMNO VARCHAR(24) -- код позиции
        ,@CITEM VARCHAR(24) -- текущая позиция
        ,@D DATETIME -- дата периода
        ,@OH INT -- начальный остаток
        ,@OHC INT -- расчетный начальный остаток
        ,@GR INT -- плановая реализация
        ,@TR INT -- количество товара в пути
        ,@SR INT -- ожидаемый приход по утвержденным заказам
        ,@RU INT -- потребность
        ,@PA INT -- прогнозный остаток на конец периода
        ,@RO INT -- количество товара в плановом заказе
        ,@LT INT -- срок доставки
        ,@LS INT -- размер (кратность) партии поставки
        ,@ERRCODE INT -- код ошибки
        ,@SST FLOAT -- страховой запас (%)


DECLARE C CURSOR FOR

        SELECT TOP 100 PERCENT ITEMNO,PDATE,OH,GR,TR,SR,SST,LT,LS,RU
        FROM MRP01
        ORDER BY ITEMNO,PDATE

 OPEN C

    FETCH NEXT FROM C INTO @ITEMNO,@D,@OH,@GR,@SR,@TR,@SST,@LT,@LS,@RU
    SET @CITEM = @ITEMNO
    SET @OHC = @OH

    WHILE @@FETCH_STATUS = 0
    BEGIN

        SET @ERRCODE = 0

        --1 Расчет прогнозного остатка
        SET @PA = @OHC + @SR+@TR+@RU - @GR
        SET @RU = 0

        -- 2 Если прогнозный остаток менее страхового запаса, то вычисление планового заказа и запись его в план закупок
        IF @PA < @GR*@SST/100
        BEGIN
                IF @LS = 0 SET @LS = 1
                IF @LS = 1
                BEGIN
                        SET @RU =  (@GR*@SST/100) - @PA
                        SET @RO = (@GR*@SST/100) - @PA
                END ELSE
                BEGIN
                        SET @RU =  (ROUND(((@GR*@SST/100) - @PA)/@LS,0,1) + 1) * @LS
                        SET @RO = (ROUND(((@GR*@SST/100) - @PA)/@LS,0,1) + 1) * @LS
                END
                SET @PA = @OHC + @SR + @TR + @RO - @GR

                INSERT INTO MRP02 (ID,ITEMNO,ODATE,RDATE,UM,AM,TRAM,ST) VALUES (NEWID(),@ITEMNO,@D-@LT,@D,@RO,0,0,0)
                IF @D-@LT < GETDATE()
                        SET @ERRCODE = 1 -- Просроченный заказ
        END

        -- 3 Обновление остатка, прогнозного остатка и потребностей в сводной таблице
        UPDATE MRP01 SET
            OH = @OHC
            ,PA = @PA
            ,RU = @RU
            ,ERRCODE = @ERRCODE
        WHERE ITEMNO = @ITEMNO AND PDATE = @D

        SET @OHC = @PA

        FETCH NEXT FROM C INTO @ITEMNO,@D,@OH,@GR,@SR,@TR,@SST,@LT,@LS,@RU

        IF @ITEMNO <> @CITEM
        BEGIN
            -- Переход к следующей категории товара
                SET @CITEM = @ITEMNO
                SET @OHC = @OH
        END -- @ITEMNO <> @CITEM

    END -- WHILE

    CLOSE C
    DEALLOCATE C


IF @@ERROR <> 0
    ROLLBACK TRAN
ELSE
    COMMIT TRAN


К сообщению приложен файл. Размер - 0Kb
29 окт 09, 17:47    [7858364]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
Yo.!
Guest
DPH3

И что хранимки на DB2 писались (давно) на C, потом еще на пяти языках

уже перетиралось тут не раз, на С писалось у всех, но все постепенно перешли на следующую ступень - на языки 4GL. и только дб2 пропустил революцию и все кропал по старинке, в терминах оракла это завется технологией препроцессоров, говорят в оракле вымершая в 80-х годах прошлого столетия.
поняв, что на дедовских технологиях далеко не уедешь ибм выкатил sql/pl где-то лет 10 назад, но в то время как раз была мода 3-tier и подавляющее большинство действительно так его и завет "какой-то PLSQL подобный" ...

DPH3

Впрочем, идеология DB2, насколько я понимаю, изначально предполагала, что бизнес-логику пишут на подходящем языке, вставляя туда SQL-операторы. Может быть и вызывая этот код прямо в контексте сервера - это уж как кому надо :)


да не умеет дб2 ту же жаву в контексте сервера пускать, только как fenced. уже два раза обсасывали.
29 окт 09, 17:48    [7858369]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
DPH3
Объектов - сравнительно мало, где-то сотня тысяч.
Пользователей - пара десятков, совсем несерьезно.


Это имеет принципиальное значение?! К примеру:

SELECT
  SUM(rows) AS rows
FROM
  sys.partitions
WHERE
  object_id = OBJECT_ID('dbo.Object') AND
  index_id IN (0, 1)

rows
--------------------
179 418 180


SELECT
  SUM(rows) AS rows
FROM
  sys.partitions
WHERE
  object_id = OBJECT_ID('dbo.AppUnit') AND
  index_id IN (0, 1)

rows
--------------------
900

DPH3
Права пользователю выдаются на вершины, права наследуются и перекрываются. Права зависят от времени суток и дня недели (по времени пользователя, а не сервера - они в разных временных поясах, да и пояса эти разные). Расписание меняется достаточно часто (до двух раз в день - легко). Но при этом по конкретной команде конкретному пользователю на короткое время могут давать не положенные ему права :)


И... Какие, собственно, у Вас трудности, реализовать ACL средставами реляционной СУБД?!

DPH3
БД - ну, например, Oracle 10.1


Ну, как Вы поняли, у меня все это на MS SQL.
29 окт 09, 18:05    [7858492]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
DPH3
Guest
iscrafm

работало бы, писалось бы...
а в чем разница между 1с и 1мс при подобном планировании? Мы же не MES реального времени говорим. Конечно, некоторые фрагменты среднего слоя используют и тот же T-SQL, если требуется.
например:

Ну, у меня построение цепочки планов для компании на год на основании прогноза занимало до двух часов. А уточнение прогноза закупок - да, в 10 секунд помещался, хотя и повозился.
Кстати, то же на MS SQL 2000 :)

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

Ну и требовалось, например, приделать к этому игру в "что, если" (если мы сейчас закажем то-то по особой скидочной цене, то как изменится общий бюджет закупок по товарному направлению) - а тут уже требовалась производительность. А, еще и перемещения между складами филиалов.

И еще прогноз потребления считался разнообразно (разные алгоритмы вычисления среднего (скользящие с разными окнами, меняющиеся окна, смена алгоритма расчета на лету).
29 окт 09, 18:06    [7858501]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
DPH3
Там основные проблемы - в том, что план закупок еще требовал накладывания ограничений (по объему склада, по зависимости цены закупки от объема, по выбору поставщика среди альтернативных, по учету особенностей данного поставщика (разные возможные графики, разный разрыв между заказом и поставкой, разные цены, разные скидки, разные приоритеты, разные кванты доставки). И все это оптимизировать по эвристикам или перебором.

Ну и требовалось, например, приделать к этому игру в "что, если" (если мы сейчас закажем то-то по особой скидочной цене, то как изменится общий бюджет закупок по товарному направлению) - а тут уже требовалась производительность. А, еще и перемещения между складами филиалов.

И еще прогноз потребления считался разнообразно (разные алгоритмы вычисления среднего (скользящие с разными окнами, меняющиеся окна, смена алгоритма расчета на лету).


Вы кого тут хотите этим удивить?!
29 окт 09, 18:08    [7858514]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
DPH3
Guest
pkarklin

И... Какие, собственно, у Вас трудности, реализовать ACL средствами реляционной СУБД?!

Кодом на SQL/T-SQL - практически никаких (ну, с деревьями чуть помучаться, но делал и не раз).
Средствами администрирования БД и выставлением грантов на хранимые процедуры - боюсь, что никак.

Тут-то речь шла о том, что использование хранимых процедур позволяет упростить контроль прав доступа. Иногда (если можно просто отгрантовать роли на уровне администратора БД) - это так.
Но в моей практике встроенных возможностей не хватает, приходится писать код для авторизации. А тут уже разницы между средним уровнем и T-SQL не наблюдается (по крайней мере, в пользу TSQL).
29 окт 09, 18:12    [7858530]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
DPH3
Guest
pkarklin

Вы кого тут хотите этим удивить?!

Да никого :) Просто как-то сомневаюсь, что это удобнее и быстрее делать на T-SQL, нежели чем на java :)
По крайней мере, мне - точно не удобнее....
29 окт 09, 18:14    [7858540]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
DPH3
Кодом на SQL/T-SQL - практически никаких (ну, с деревьями чуть помучаться, но делал и не раз).


Все прекрасно работает на "голом" транзакте.

DPH3
Но в моей практике встроенных возможностей не хватает, приходится писать код для авторизации.


Да, приходится, но я проектирую необходимую модель и пишу его на T-SQL.
29 окт 09, 18:15    [7858549]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
DPH3
Просто как-то сомневаюсь, что это удобнее и быстрее делать на T-SQL, нежели чем на java :)
По крайней мере, мне - точно не удобнее....


Вот. Золотые слова.
29 окт 09, 18:16    [7858555]     Ответить | Цитировать Сообщить модератору
 Re: использование хранимых процедур  [new]
Favn
Member

Откуда:
Сообщений: 585
Yo.!
sql/pl в db2 практически никто не использует, оно и понятно, разбираться в новом языке, который имеет лишь базовые конструкции и тучу нюансов при переносе на другую платформу никому не хочется. действительно проще взять какой-нить хибер и ипать мозг.
Ой! То есть меня, например, практически не существует? Категорически не согласен!
Появился SQL PL в 7-й, кажется, версии, то есть он не намного моложе Java, к примеру. Или молодую Джаву тоже использовать не надо? ;)
По поводу "тучи нюансов при переносе на другую платформу" хотелось бы подробнее - я как-то всегда считал PL SQL единым для DB2 LUW, т.е. для практически всех Oracle-совместимых платформ (ну, кроме "совсем уже устаревших"(c) мейнфреймов и iSeries).
Yo.!
да не умеет дб2 ту же жаву в контексте сервера пускать, только как fenced. уже два раза обсасывали.
Ну да, теряем на переключении контекста. Зато и не лицензируем ресурсы, используемые Java. Кстати, где-то там же обсасывали, что PL/SQL тоже выполняется отдельной вирт. машиной, не зря же native-компиляцию для него придумали. Она, конечно, лучше "вписана" в СУБД, чем Java, но спасает ли это от переключения контекстов?
Кстати, о "лишь базовых конструкциях" - в последнем DB2 9.7 SQL PL в части обработки данных в БД функционально ничем не хуже PL/SQL. А остальное, ИМХО, всяко лучше на Java писать.
29 окт 09, 18:16    [7858556]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить