Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 24   вперед  Ctrl
 Re: Покритикуйте Оракл 10г  [new]
Из НИИ
Guest
komandarm
Ну ведь в любой научной 8) работе (я пишу диссер повнедрению в лаборатории хранилища данных) надо обосновать, почему я использую Оракл Экспресс Эдишн (на самом деле, потому что его на работе юзаю да и с компонентами в дельфи знаком). Но это не научно, вот и надо аргументировано показать что бывает "как в оракле" и "как неправильно"

Странный подход к диссертации. Обоснование выбора СУБД - хорошая задача для диплома. В диссертации нужны какие-то новые научные результаты, сформулированные в общем виде. Результаты должны допускать реализацию на разных языках программирования с разными базами данных. Про реализацию максимум одна глава, где можно просто указать: разработан комплекс программ на основе СУБД Oracle и умеет делать такие-то вещи. Выбором СУБД в диссертации Вы создадите у рецензентов и оппонентов впечатление, что Вам нечего больше было написать.
Если все-таки очень хочется вставить выбор СУБД, тогда желательно сделать следующее:
1. Определить требования ВАШЕЙ РАЗРАБОТКИ к СУБД. Если у вас ВУЗ или НИИ - тогда очень важно, чтобы СУБД была бесплатной. Требования по объему, количеству подключений, операций и т.п. Возможно, Вам нужны какие-то специфические возможности типа semantic web (модная сейчас технология, недавно двое знакомых защитили диссертации по близким темам). Какая нужна надежность?
2. Провести анализ соответсвия СУБД ВАШИМ требованиям. Например, составить табличку: в столбцах СУБД, в строках фичи, в ячейках значения поддерживается/неподдерживается. Сразу будут видны достоинства и недостатки СУБД именно с точки зрения реализации ВАШЕЙ РАЗРАБОТКИ, что наиболее важно в диссертации.
3. На основе анализа выбрать наиболее подходящую СУБД.

При творческом подходе требования можно сформировать так, чтобы им соответсвовала СУБД, которая больше нравится. Например, такой аргумент: у Oracle есть как бесплатная реализация для небольших баз (XE), так и промышленный вариант. Бесплатную можно использовать в ВУЗе, промышленную - на крупном предприятии. Это обеспечивает широкий круг применения результатов диссертации, что очень важно.

Отдельная тема: достижение максимальной эффективности. Например, комплекс программ был реализован с помощью СУБД Oracle, MS-SQL и MySQL. Далее перечислить критерии оценки эффективности реализации, провести испытания и показать, что реализация на Oracle наиболее эффективная. Но это значительно усложняет работу.

PS. Все IMHO
17 июл 07, 08:12    [4395908]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
softwarer
[
Лексический анализатор как правило содержит два основных блока. Первый из них непосредственно обрабатывает входной поток и выделяет интересующие последовательности символов. Второй - формирует выходной поток, для чего просматривает выделенные последовательности и предпринимает специфические действия в зависимости от типа каждой (отбрасывает комментарии, проверяет идентификаторы по таблице ключевых слов итп).

В англоязычной терминологии, как мне представляется, анализатор в целом называется lexer, первый блок - scanner, второй блок - tokenizer.


drev
Кстати, "tokenizer для него" звучит очень странно.. tokenizer для одного элемента не строится.

"Tokenizer, способный его выделить и вернуть" устроит больше?



Первое маленькое замечание:

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

Продолжение следует..
17 июл 07, 08:23    [4395926]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
softwarer



Далее.

То, что Вы описываете, это парсер "снизу-вверх". За последние годы мне не приходилось видеть такой реализации. Кстати, термин "non-terminal" не относится к этой парадигме.

В основном промышленные парсеры работают "сверху вниз". Т.е. Имеют одну или несколко точек входа, являющихся нетерминалами, т.е. грубо, "непоследними", составными синтаксическими конструкциями. Например, batch, stored_procedure, expression.

Парсер обычно генерируется из описания грамматики, которое состоит из как минимум двух частей:

- определения лексем, которое обычно называют лексер
- определения нетерминалов, которое обычно называют граммар.

На основании лексера строится токенайзер. Из граммар - собственно парсер.

Парсер идёт сверху вниз, в случае конфликтов используется "lookahead".

Если Вы готовы принять эту модель, я готов продолжить описание проблемы.
17 июл 07, 08:46    [4395975]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
(Терпеливо) Цитирую: то есть я понимаю, что можно и без нее, но особого смысла именно такой конструкции не улавливаю.


А какой на Ваш взгляд будет "особый смысл" в наличии таблицы updated? Не кажется ли Вам, что наличие этой таблицы будет избыточным? При UPDATE записи с новыми значениями полей будут в базовой таблице триггера и в таблице inserted. Записи со старыми значениями полей будут в таблице deleted. Какую дополнительную функциональность Вы хотите возложить на таблицу updated?

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


Гм... Вспоминая приведенный мной код (в котором я по невнимательности пропустил кусок):

CREATE TRIGGER it_SomeTable
FOR INSERT
AS
  UPDATE
    T
  SET
    T.SomeDate = dbo.CalcSomeDate(T.ID)
  FROM
    SomeTable T
    INNER JOIN inserted i ON
    T.ID = i.ID

Не совсем понятно, о какой информации, готовой к употреблению Вы ведете речь?! Таблицы inserted и deleted - немодифицируемые. Осмелюсь предположить, что Вы имеете ввиду примерно следующее (при наличии таблицы updated и возможности ее модификации):

CREATE TRIGGER ut_SomeTable
FOR UPDATE
  UPDATE
    updated
  SET
    colLastChanging = GETDATE()

Посмотрим, какие ресурсы для этого нужны по сравнению с вариантом:

CREATE TRIGGER ut_SomeTable
FOR UPDATE
  UPDATE
    T
  SET
    colLastChanging = GETDATE()
  FROM
    SomeTable T
    INNER JOIN inserted i ON
    T.ID = i.id

Что в первом, что во втором случаи серверу надо находить в базовой таблице (скажем по row_id или значению кластерного индекса) те записи, которые необходимо проапдейтить и в большинстве случаев это будет Nested Loops по inserted c Index Seek по базовой таблицы. М.б. предположение о требуемых дополнительных ресурсах Вы делаете из того, как Вы представляете своим ученикам INNER JOIN -> CROSS JOIN + фильтрация? Так что мне не совсем понятно, о каких ресурсах Вы ведете речь. Как мне кажется, такие же ресурсы понадобятся и Oracle, чтобы найти и изменить в базовой таблице одну запись в случаи:

create or replace trigger ......
begin
  :new.some_date := CalcSomeDate ( :new.id ) ; -- CalcSomeData - делает пару селектов и обрабатывает их результаты
end ;

Более того, приведенному мной триггеру абсолютно все равно - сколько записей будет обработано: 0, 1 или >1. Код не зависит от этого.

Тем не менее, ни кто мне не запрещаетделать примерно следующее:

CREATE TRIGGER ut_SomeTable
FOR UPDATE
--сначала set ориентированный подход
  UPDATE
    T
  SET
    colLastChanging = GETDATE()
  FROM
    SomeTable T
    INNER JOIN inserted i ON
    T.ID = i.id
--затем навигационный (при необходимости)
  DECLARE @id int 
  DECLARE Cur CURSOR FOR
    SELECT id FROM inserted
  OPEN Cur
  FETCH FROM Cur INTO @id
  WHILE @@fetch_status = 0 BEGIN
      EXEC SomeProc @id
      FETCH FROM Cur INTO @id
  END
  CLOSE Cur
  DEALLOCATE Cur

Хотя никто не запрещает в триггере реализовывать различную обработку в зависимости от числа записей:

CREATE TRIGGER intrig
ON sales
FOR INSERT AS
IF @@ROWCOUNT = 1
BEGIN
   UPDATE titles
   SET ytd_sales = ytd_sales + qty
   FROM inserted
   WHERE titles.title_id = inserted.title_id
END
ELSE
BEGIN
   UPDATE titles
   SET ytd_sales = ytd_sales +
   (SELECT SUM(qty)
      FROM inserted
      WHERE titles.title_id = inserted.title_id)
   WHERE titles.title_id IN
      (SELECT title_id FROM inserted)
END

с оптимизированным запросом в случаи обработки 1ой записи.
17 июл 07, 08:48    [4395979]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Victosha
Для алгоритма типа А) ... Размеры временных (дисковых) ресурсов хорошо фиксируются и не могут выйти далеко
за размеры InputCollection + MatchedRows.

...

Для алгоритма типа Б) ... В объем необходимых ресурсов нужно включать размер inserted+ deleted. Т.е. в худшем случае это учетверенный размер изменяемой таблицы.


Помилуйте о каком учетвереноом размере идет речь, если Вы говорите об UPDATE, а не об INSERT, на примере которого Вы расписывали алгоритм?! В случаи UPDATE всех записей таблицы c 1 000 000 записей:

InputCollection + MatchedRows = 2 000 000
inserted+ deleted = 2 000 000

Victosha
Механика работает однотипно и независимо от того, задействован триггерный механизм разработчиком или нет.


Это так. В MS SQL inserted и deleted "матриализуются" из лога.
17 июл 07, 09:16    [4396063]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
Я думаю, основная причина вопроса об updated есть ложная модель того, что происходит.

SQL Server не создаёт inserted, deleted. это просто программный интерфейс к используемым в других целях структурам данных.
17 июл 07, 09:20    [4396080]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Victosha
Member

Откуда: Москва
Сообщений: 2620
pkarklin
Помилуйте о каком учетвереноом размере идет речь, если Вы говорите об UPDATE, а не об INSERT, на примере которого Вы расписывали алгоритм?! В случаи UPDATE всех записей таблицы c 1 000 000 записей:

это не был "пример для инсерта".
это была попытка описать "универсальный механиз исполнителя dml", в той части, в которой это касается запуска триггера. Учетверение - подразумевался именно полный апдейт таблицы.
Дело не столько в том насколько точно увеличивается потребность в размерах временной области
(хотя и в этом тоже), сколько в вероятном общем усложнении процедур управления временными объектами.
Впрочем, вероятно softwarer как раз в этом именно моменте будет парировать привлечением механизма глобальных временных таблиц с удалением на коммит.
17 июл 07, 09:30    [4396123]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Victosha
Member

Откуда: Москва
Сообщений: 2620
drev
Я думаю, основная причина вопроса об updated есть ложная модель того, что происходит.

SQL Server не создаёт inserted, deleted. это просто программный интерфейс к используемым в других целях структурам данных.


применительно к вопросу об updated не так важно, насколько модель ложная.

Задача модели пытаться отобразить общую логику работы программы.
Привлечение updateted ненужным образом усложняет код вызова триггера, заставляя алгоритм знать, какого типа dml сейчас выполняется.
При этом нет операций, включая MERGE, где без этого нельзя было бы обойтись.

Кстати, для меня загадка - почему MERGE не реализован (как понимаю - до сих пор) в SQL Server как явный sql оператор. Какого сорта особенности сервера заставляют избегать этого.
17 июл 07, 10:02    [4396297]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Victosha
Кстати, для меня загадка - почему MERGE не реализован (как понимаю - до сих пор) в SQL Server как явный sql оператор. Какого сорта особенности сервера заставляют избегать этого.


Он уже реализован. Во всяком случаи в CTP 2008 он уже есть.
17 июл 07, 10:05    [4396309]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Victosha
Мне представляется, что это :new и inserted - «перпендикулярные» технологии.


Тут Вы правы :) В том смысле, что реализация одной из них НЕ мешает другой.
Они ортогональны

Victosha
Для алгоритма типа А) в принципе не возникает проблемы с версионностью.,
т.к. по завершению триггера не представляет проблемы вопрос – что именно является тем, что должно быть зафиксировано как новая версия строки и где оно находится. Это экземпляр new строки таблицы и находится он в оперативной памяти под управлением текущего потока исполнения.


Боюсь, что Вы СЛИШКОМ упрощаете. Механизм версионности уровня блоков (а не строк как вы пишите) также СОВЕРШЕННО ортогонален обрабатываемым триггерам. Речь может идти о снижении производительности и потреблении ресурсов для обеспечения фичи, но никак ни о том как это скажется на мехенизме версионности. Механизму версионности Oracle глубоко фиолетово то какие триггеры выполняются при выполнении DML.

Что касается потребелния ресурсов, как показал softwarer коллекции вполне уместны в данном случае, как и временные таблицы Oracle кстати.
17 июл 07, 10:39    [4396548]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
pkarklin
А какой на Ваш взгляд будет "особый смысл" в наличии таблицы updated? Не кажется ли Вам, что наличие этой таблицы будет избыточным? При UPDATE записи с новыми значениями полей будут в базовой таблице триггера и в таблице inserted. Записи со старыми значениями полей будут в таблице deleted. Какую дополнительную функциональность Вы хотите возложить на таблицу updated?


А какой тайный смысл в делении УЖЕ ИМЕЮЩЕЙСЯ информации на inserted и deleted и последующая растрата ресурсов на full outer join в триггере ???
17 июл 07, 10:42    [4396565]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
Gluk (Kazan)
pkarklin
А какой на Ваш взгляд будет "особый смысл" в наличии таблицы updated? Не кажется ли Вам, что наличие этой таблицы будет избыточным? При UPDATE записи с новыми значениями полей будут в базовой таблице триггера и в таблице inserted. Записи со старыми значениями полей будут в таблице deleted. Какую дополнительную функциональность Вы хотите возложить на таблицу updated?


А какой тайный смысл в делении УЖЕ ИМЕЮЩЕЙСЯ информации на inserted и deleted и последующая растрата ресурсов на full outer join в триггере ???


УЖЕ ИМЕЮЩЕЙСЯ ГДЕ? Кстати, а что Вы предлагаете хранить в updated? Старые или новые значения? Или она должна иметь в два раза больше колонок?
17 июл 07, 10:53    [4396635]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Gluk (Kazan)
pkarklin
А какой на Ваш взгляд будет "особый смысл" в наличии таблицы updated? Не кажется ли Вам, что наличие этой таблицы будет избыточным? При UPDATE записи с новыми значениями полей будут в базовой таблице триггера и в таблице inserted. Записи со старыми значениями полей будут в таблице deleted. Какую дополнительную функциональность Вы хотите возложить на таблицу updated?


А какой тайный смысл в делении УЖЕ ИМЕЮЩЕЙСЯ информации на inserted и deleted и последующая растрата ресурсов на full outer join в триггере ???


Постойте. Вы, как справедливо заметил drev, тоже не понимаете "физики процессов" таблиц inserted и deleted. Никакого ДОПОЛНИТЕЛЬНОГО деления нет. Это реальная существующая информация из лога. Никаких дополнительных временных хранилишь под нее не строится. Можно пример "последующей" растраты ресурсов, ибо не совсем понятно, что Вы имеете ввиду? И в качестве так же , примера, отсутствия траты "этих же ресурсов" в Oraсle. Можно в контексте триггера, как предлагал softwarer, FOR INSERT, UPDATE, DELETE.
17 июл 07, 11:09    [4396735]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
drev
УЖЕ ИМЕЮЩЕЙСЯ ГДЕ?


В логах Вы же имеете смелость предлагать всякую [никому не нужную] фигню для Oracle.
Почему бы мне (вернее softwarer-у) не предложить что нибудь для MS SQL ???

А как реализовать это пусть разработчики думают. Уверен, они ВСЕ с радостью сделают за пиццу и банку колы :)
17 июл 07, 11:12    [4396755]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
pkarklin
А какой на Ваш взгляд будет "особый смысл" в наличии таблицы updated?

В этой конструкции будет не "особый", а "естественный" смысл. Имхо при наличии операций insert/update/delete довольно естественно ожидать лог этих операций в inserted/updated/deleted, isn't it? Отступление от этого логичного порядка должно быть чем-то обосновано; чем - я пока не вижу.

pkarklin
Не кажется ли Вам, что наличие этой таблицы будет избыточным? При UPDATE записи с новыми значениями полей будут в базовой таблице триггера и в таблице inserted.

Нет, не кажется. Я не понимаю, что "новые значения полей после update" делают в inserted. Примерно аналогично я удивлялся бы, если бы поворот руля автомобиля приводил к изменению положения педали тормоза.

P.S. На всякий случай упомяну, что я нисколько не имею в виду вопросы "перехода с текущей ситуации на ситуацию с updated". Бессмысленно обсуждать то, что сделано не будет; я всего лишь констатировал, что не понимаю, нафига изначально сделали именно так. Преимуществ с точки зрения использования я не вижу, скорее недостатки; что касается удобства внутренней реализации - судить сложно, но каких-то прямых показаний опять же не видно.

pkarklin
Не совсем понятно, о какой информации, готовой к употреблению Вы ведете речь?!

В тот момент, когда выполняется оператор update (физически модифицирует данные конкретной строки) существует (тривиальнейше может быть получена) полностью готовая к использованию строка таблицы updated. Также она легко может быть получена из лога. Вместо этого информация полностью игнорируется, и практически стопроцентно необходимая "строка со старыми и новыми значениями" получается join-ом, который как минимум лень "писать каждый раз" и который, подозреваю, требует машинных ресурсов для выполнения. Ресурсы в принципе небольшие (оптимизатор, надеюсь, использует предсортированность данных), но учитывая частоту операции вряд ли стоит их тратить.

pkarklin
Таблицы inserted и deleted - немодифицируемые. Осмелюсь предположить, что Вы имеете ввиду примерно следующее (при наличии таблицы updated и возможности ее модификации):

Нет, я не имею в виду возможность модификации. Модификация - отдельный интересный вопрос.

pkarklin
Как мне кажется, такие же ресурсы понадобятся и Oracle, чтобы найти и изменить в базовой таблице одну запись в случаи:

Все, приехали. Об этом я уже писал выше - про "стоит услышать"....
17 июл 07, 11:13    [4396763]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
pkarklin
[quot Gluk (Kazan)]Постойте. Вы, как справедливо заметил drev, тоже не понимаете "физики процессов" таблиц inserted и deleted. Никакого ДОПОЛНИТЕЛЬНОГО деления нет.


Я понял, что они берутся из лога. Также понял, что из лога НЕУДОБНО доставать updated.
Так что же это как не перекладывание неудобства на плечи прикладника ?
17 июл 07, 11:18    [4396787]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Кстати, не знаю как в MS SQL, а в Oracle full outer join дорогостоящая операция
17 июл 07, 11:20    [4396799]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
drev
Первое маленькое замечание:

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

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

- здесь возможны варианты а или b
- .... идет обсуждение ....
- а вот тут у вас противоречие: то вы говорите (утверждение из обсуждения варианта а),
то вы говорите (утверждение из обсуждения варианта b)

Во-вторых, противоречия здесь нет, исключительно ссылка на стандартный вариант архитектуры со стековой организацией взаимодействия (парсер вызывает токенайзер, токенайзер вызывает сканнер, итого с точки зрения парсера "токенайзер выделил"). В позднее сформулированной системе я специально избегал подобных деталей, делая максимально универсальное изложение.
17 июл 07, 11:26    [4396840]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
softwarer
pkarklin
А какой на Ваш взгляд будет "особый смысл" в наличии таблицы updated?

В этой конструкции будет не "особый", а "естественный" смысл. Имхо при наличии операций insert/update/delete довольно естественно ожидать лог этих операций в inserted/updated/deleted, isn't it? Отступление от этого логичного порядка должно быть чем-то обосновано; чем - я пока не вижу.



И Б сидели на трубэ, А упало, Б пропало, что осталось на трубэ?"

Ваша логика слегка напоминает этот стишок.

Update - это Delete И Insert. Уберите deleted, inserted. "Что осталось на трубэ?"
17 июл 07, 11:28    [4396851]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
drev
Я думаю, основная причина вопроса об updated есть ложная модель того, что происходит.

SQL Server не создаёт inserted, deleted. это просто программный интерфейс к используемым в других целях структурам данных.

"Первая ошибка программиста - плясать не от постановки задачи, а от возможности реализации". Не надо ее демонстрировать.

Как оно происходит - вопрос интересный, но второй. Сначала интересна - постановка задачи.
17 июл 07, 11:31    [4396873]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
В этой конструкции будет не "особый", а "естественный" смысл. Имхо при наличии операций insert/update/delete довольно естественно ожидать лог этих операций в inserted/updated/deleted, isn't it?


Если для Вас это естественно, то тогда какой должна быть структура предлагаемой Вами таблицы updated? Если я правильно Вас понимаю, то кол-во полей базовой таблицы х2, для реализации аналога .old и .new?

softwarer
В тот момент, когда выполняется оператор update (физически модифицирует данные конкретной строки) существует (тривиальнейше может быть получена) полностью готовая к использованию строка таблицы updated. Также она легко может быть получена из лога.


Еще раз - при обращении к inserted и deleted они "не получаются" из лога - эти таблицы и есть по своей сути сам лог, в котором для операции UPDATE фиксируется старое и новое значение. Так же как таблица sysprocesses есть отражение в табличной форме процессов сервера. Т.е. эти таблицы есть интерфейс доступа к уже имеющимся данным и для поддержания нет необходимости в дополнительных ресурсах сервера. Чего не скажешь в отношении предлагаемой Вами таблицы updated. Зачем ее каждый раз поддерживать, если:

1. Ее, как сущности данных не существует?
2. Факт наличия триггера и обращения к ней не обязателен?

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

softwarer
Вместо этого информация полностью игнорируется


Нет этой информации. Поэтому и игнорировать нечего.

автор
и практически стопроцентно необходимая "строка со старыми и новыми значениями" получается join-ом, который как минимум лень "писать каждый раз" и который, подозреваю, требует машинных ресурсов для выполнения. Ресурсы в принципе небольшие (оптимизатор, надеюсь, использует предсортированность данных), но учитывая частоту операции вряд ли стоит их тратить.


Обращение к .new .old оно не требует "машинных ресурсов для выполнения"? На поддержания этой "таблицы updated" в Oracle не требуется "машинных ресурсов"? Не уверен. Наверняка ядро также поддерживает пул старых и новых значений, предоставляя их через интерфейс .new и .old. В чем тогда принципиальная разница по сравнению с inserted и deleted тем же самым по сути интерфейсом, который не зависит от того, statement или row level триггер?
17 июл 07, 11:36    [4396908]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Gluk (Kazan)
pkarklin
[quot Gluk (Kazan)]Постойте. Вы, как справедливо заметил drev, тоже не понимаете "физики процессов" таблиц inserted и deleted. Никакого ДОПОЛНИТЕЛЬНОГО деления нет.


Я понял, что они берутся из лога. Также понял, что из лога НЕУДОБНО доставать updated.
Так что же это как не перекладывание неудобства на плечи прикладника ?


М.б. Вы потрудитесь объяснить смысл "доставания" таблицы updated - практический смысл? Только не надо в стиле логики softwarer: раз есть INSERT\UPDATE\DELETE, то должно быть inserted\updated\deleted. inserted и deleted существуют как окошко для обращения к данным в логе. Зачем доп. расходы на генерацию updated?

ЗЫ. Кстати пример триггера с full outer join и решаемой с помощью него задачи таки не приведен.
17 июл 07, 11:41    [4396940]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
softwarer
drev
Я думаю, основная причина вопроса об updated есть ложная модель того, что происходит.

SQL Server не создаёт inserted, deleted. это просто программный интерфейс к используемым в других целях структурам данных.

"Первая ошибка программиста - плясать не от постановки задачи, а от возможности реализации". Не надо ее демонстрировать.

Как оно происходит - вопрос интересный, но второй. Сначала интересна - постановка задачи.


Знаете, в чём разница между профессионалом и любителем?

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

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

Не уподобляйтесь любителю.
17 июл 07, 11:48    [4396983]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
drev
То, что Вы описываете, это парсер "снизу-вверх".

Если Вы имеете в виду "парсеры, которые строят дерево от листьев к корню", то Ваше утверждение ложно. Это описание никак не зависит от используемого подхода.

drev
За последние годы мне не приходилось видеть такой реализации. Кстати, термин "non-terminal" не относится к этой парадигме.

В любом случае, будьте добры таки более четко определять используемые термины; мы уже натолкнулись на семантически значимые различия. Что касается самого этого утверждения - оно висит в воздухе до тех пор, пока не будет ясности в ответе на предыдущий вопрос.

В основном промышленные парсеры работают "сверху вниз". Т.е. Имеют одну или несколко точек входа, являющихся нетерминалами, т.е. грубо, "непоследними", составными синтаксическими конструкциями. Например, batch, stored_procedure, expression.

drev
Парсер обычно генерируется из описания грамматики, которое состоит из как минимум двух частей:
- определения лексем, которое обычно называют лексер

Хм. Вот это столь странная фраза, что попрошу специального уточнения. Следует ли понимать Вас так, что "конфигурационный файл к Lexx" - это пример lexer-а? Подчеркну: именно конфигурационный файл (или любое другое описание лексем), а не "сгенерированный сканнер" или нечто подобное?

drev
На основании лексера строится токенайзер. Из граммар - собственно парсер.

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

drev
Парсер идёт сверху вниз, в случае конфликтов используется "lookahead".

Если хотите ограничиться только такими парсерами - не возражаю, если конечно Вы достоверно знаете, что в Oracle используется именно такой.

drev
Если Вы готовы принять эту модель, я готов продолжить описание проблемы.

Я готов использовать любую терминологию, просто хочу ее четко понимать.
17 июл 07, 11:52    [4397008]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
softwarer
drev
То, что Вы описываете, это парсер "снизу-вверх".

Если Вы имеете в виду "парсеры, которые строят дерево от листьев к корню", то Ваше утверждение ложно. Это описание никак не зависит от используемого подхода.

softwarer
Синтаксический анализатор воспринимает поток лексем и выделяет из него законченные синтаксические конструкции. Фаза похожа на предыдущую, но работающую над потоком метасимволов, каждый из которых является "словом". Ее выходом является поток семантик - директив, имеющих смысл фраз, таких как "определи переменную", "возьми элемент массива", "присвой переменной значение выражения" итп


Я продолжаю надеятся, уже совсем слабо, что вы поймёте, что описаное вами выше - "снизу вверх"

Далее, результатом работы парсера является не то, что вы описали, а некая древесная структура, обычно AST
.


drev
За последние годы мне не приходилось видеть такой реализации. Кстати, термин "non-terminal" не относится к этой парадигме.

В любом случае, будьте добры таки более четко определять используемые термины; мы уже натолкнулись на семантически значимые различия. Что касается самого этого утверждения - оно висит в воздухе до тех пор, пока не будет ясности в ответе на предыдущий вопрос.

В основном промышленные парсеры работают "сверху вниз". Т.е. Имеют одну или несколко точек входа, являющихся нетерминалами, т.е. грубо, "непоследними", составными синтаксическими конструкциями. Например, batch, stored_procedure, expression.

drev
Парсер обычно генерируется из описания грамматики, которое состоит из как минимум двух частей:
- определения лексем, которое обычно называют лексер

Хм. Вот это столь странная фраза, что попрошу специального уточнения. Следует ли понимать Вас так, что "конфигурационный файл к Lexx" - это пример lexer-а? Подчеркну: именно конфигурационный файл (или любое другое описание лексем), а не "сгенерированный сканнер" или нечто подобное?


да


drev
На основании лексера строится токенайзер. Из граммар - собственно парсер.

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

Кого Вы цитируете? Укажите, где я это говорил?

drev
Парсер идёт сверху вниз, в случае конфликтов используется "lookahead".

Если хотите ограничиться только такими парсерами - не возражаю, если конечно Вы достоверно знаете, что в Oracle используется именно такой.

drev
Если Вы готовы принять эту модель, я готов продолжить описание проблемы.

Я готов использовать любую терминологию, просто хочу ее четко понимать.
17 июл 07, 12:20    [4397227]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 24   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить