|
Действия ...
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
01.02.2005, 16:02
|
|||
|---|---|---|---|
|
|||
INSERT and UPDATE |
|||
|
#18+
Такой вопрос: есть таблица. С некоторой периодичностью данные в этой таблице должны обновляться. При этом могут появиться дополнительные строки, т.е. использование только оператора UPDATE не допустимо. Подскажите как правильно реализовать эту систему? 1. SELECT * FROM table 1 WHERE col='значение' 2. проверка на то, успешна была выборка или нет 3. в зависимости от проверки выполнять или INSERT или UPDATE Или есть все-таки более рациональные варианты? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.02.2005, 16:09
|
|||
|---|---|---|---|
INSERT and UPDATE |
|||
|
#18+
Как я понимаю, зависит от БД. Например, в Oracle 8 выглядело так (PL/SQL) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. В Oracle 9 появилась команда MERGE, которая делает это с пом. только SQL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.02.2005, 16:16
|
|||
|---|---|---|---|
INSERT and UPDATE |
|||
|
#18+
_grifon_Такой вопрос: есть таблица. С некоторой периодичностью данные в этой таблице должны обновляться. При этом могут появиться дополнительные строки, т.е. использование только оператора UPDATE не допустимо. Подскажите как правильно реализовать эту систему? 1. SELECT * FROM table 1 WHERE col='значение' 2. проверка на то, успешна была выборка или нет 3. в зависимости от проверки выполнять или INSERT или UPDATE Или есть все-таки более рациональные варианты? А что такого сложного. Обычно эти insert и update довольно сильно отличаются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.02.2005, 16:18
|
|||
|---|---|---|---|
|
|||
INSERT and UPDATE |
|||
|
#18+
Да, прошу прощения забыл сказать про БД: используется MySQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.02.2005, 16:21
|
|||
|---|---|---|---|
|
|||
INSERT and UPDATE |
|||
|
#18+
Dogen А что такого сложного. Обычно эти insert и update довольно сильно отличаются. Абсолютно ничего сложного нет. Просто хочется узнать единственный ли способ обновления таблицы, который я написал, или все-таки существуют ещё. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.02.2005, 16:24
|
|||
|---|---|---|---|
INSERT and UPDATE |
|||
|
#18+
_grifon_ Dogen А что такого сложного. Обычно эти insert и update довольно сильно отличаются. Абсолютно ничего сложного нет. Просто хочется узнать единственный ли способ обновления таблицы, который я написал, или все-таки существуют ещё. Не единственный. Используйте только INSERT, а активную версию записи выбирайте по дате или еще как-нибудь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.02.2005, 16:33
|
|||
|---|---|---|---|
INSERT and UPDATE |
|||
|
#18+
IMHO первоначальный - самый оптимальный вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.02.2005, 16:37
|
|||
|---|---|---|---|
|
|||
INSERT and UPDATE |
|||
|
#18+
Dogen Не единственный. Используйте только INSERT, а активную версию записи выбирайте по дате или еще как-нибудь. Я думаю засорять таблицу лишними записями не имеет смысла. Но спасибо за вариант :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.02.2005, 16:40
|
|||
|---|---|---|---|
|
|||
INSERT and UPDATE |
|||
|
#18+
tru55Как я понимаю, зависит от БД. Например, в Oracle 8 выглядело так Зависит. В ASA можно сделать так: Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.02.2005, 16:41
|
|||
|---|---|---|---|
INSERT and UPDATE |
|||
|
#18+
_grifon_ Dogen Не единственный. Используйте только INSERT, а активную версию записи выбирайте по дате или еще как-нибудь. Я думаю засорять таблицу лишними записями не имеет смысла. Но спасибо за вариант :) Я не предлагаю хранить лишнее. Если Вам не нужно хранить версии записей, используйте Ваш вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.02.2005, 19:43
|
|||
|---|---|---|---|
INSERT and UPDATE |
|||
|
#18+
Допустим, что новые записи находятся в TMP, а старые в TABLE. Имеется ключ, определяющий однозначную связь между записью из TMP и TABLE->Key. Имеется признак в TABLE, который ограничивает множество записей, которому соответствует набор в TMP. Если время не критично, то проще всего удалить сначала из Table те записи, множество которых относится к обновлению, и затем вставить из TMP в TABLE. Это также исключает возможность остаться старой записи, которая была удалена (в этом случае только Insert или Update недостаточно. Если критично время, тогда следует позаботиться о том, что бы не было лишней работы для перестрйки индексов и записей в журнал транзакций. Для индексов - не делать Update для тех записей, в которых не поменялись ключевые поля, т.е. входящие в индексы. Для журнала транзакций - не делать Update для тех записей, которые вообще не поменялись. В целом можно это сделать за несколько шагов - Отметить в TMP полностью сопадающие записи (отметка в TMP не занимает время) - Обновить записи с совпадающими ключевыми полями (индексы не меняются, время на запись в журнал транзакций) - удалить из TABLE записи, для которых соответствующих ключей в TMP - Вставить из TMP в TABLE не использованные записи из TMP ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=32&tablet=1&tid=1546075]: |
0ms |
get settings: |
6ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
44ms |
get topic data: |
5ms |
get forum data: |
1ms |
get page messages: |
25ms |
get tp. blocked users: |
1ms |
| others: | 258ms |
| total: | 352ms |
| 0 / 0 |
