|
|
|
Supreme Being
участник
Last Login: 01.06.2003 18:26
Сообщ.: 263,
Visits: 2 905
|
|
Ситуация следующая:
есть таблица с расчетными счетами предприятия, многие таблицы используют ее по ИД счета. Несколько раз в год эта таблица перестраивается из R3, т.к. R3 отвечает за эту предметную области. Мне необходимо после изменения таблицы со счетами в связанных таблицах изменять ИД счетов, если они их поменяли в базовой. Связанных таблиц много и записей в них по несколко сот тысяч. Что будет работать быстрее Update или Delete c Insert. БД работает под ораклом.
|
|
|
|
|
новичок
участник
Last Login: 20.12.2001 14:37
Сообщ.: 8,
Visits: 89
|
|
Я так понимаю, что если ты задаешь этот вопрос, то в таблице установлено каскадное правило обновления дочерних таблиц.
Зачем же тогда мучиться и писать сложные запросы?. Ведь эти немеренные тысячи сот связанных записей при удалении родительской надо где-то запомнить. Я не думаю что это будет быстрее.
|
|
|
|
|
Supreme Being
участник
Last Login: 01.06.2003 18:26
Сообщ.: 263,
Visits: 2 905
|
|
| вот именно, что никакого каскадного обновления нет (плохой стиль проектирования БД), связи между документами определяются в хмл описании, при закачке которого, строится таблица со взаимосвязанными полями, т.е. несколько полей: реквизиты документов использующие реквизиты справочников. Поэтому нетрудно вытащить завязанные на эту сущность связанные таблицы. Можно написать функцию на динамическом PL\SQL, которая будет сравнивать записи существующей таблицы счетов и полученной из R3, и будет делать Update выбранным полям завязанных таблиц. Мне интересно знать, что будет быстрее работать: Update или Delete c Insert (список остальных полей из докуменов тоже можно выдернуть из хмл описания в БД, если сначала удалять запись и потом втыкать ее с новом ИДом счета). В некоторых таблицах на поле ИДа счета стоит индекс.
|
|
|
|
|
новичок
участник
Last Login: 20.12.2001 14:37
Сообщ.: 8,
Visits: 89
|
|
Я бы не стал судить о каскадном обновлении как об однозначно плохом стиле проектирования. Оно существует как раз для таких случаев. И потом, все хорошо когда в меру.
Что же касается твоей дилеммы, то я думаю так: Вставка нового значения в индексируемое поле (это происходит при операциях Isert and Update) сама по себе долгая процедура, поэтому, если ограничения целостности позволяют, то лучше пользоваться операцией Update, не задумываясь над другими вариантами.
|
|
|
|
|
Supreme Being
участник
Last Login: 18.03.2003 10:55
Сообщ.: 83,
Visits: 914
|
|
А не проще менять ID в "новой" таблице на "старые" значения ?
Или иметь таблицу соответствия между "новыми" и "старыми" ID ? И не думать о быстродействии.
Хотя, если операция происходит 1 раз в год и занимает менее 4 - х часов (половина рабочего дня) то вопрос переходит в чисто теоретическое русло.
|
|
|
|