sql: УДАЛИТЕ +, ВСТАВЛЯЮТ по сравнению с ОБНОВЛЕНИЕМ +, ВСТАВЛЯЮТ
Подобный вопрос задали, но так как он всегда зависит, я прошу свою определенную ситуацию отдельно.
У меня есть страница веб-сайта, которая показывает некоторые данные, которые прибывают из базы данных, и генерировать данные из той базы данных, я должен сделать некоторых довольно сложных несколько запросов соединений.
Данные обновляются один раз в день (ночью).
Я хотел бы предварительно генерировать данные для упомянутого представления для ускорения доступа страницы.
Для этого я составляю таблицу, которая содержит точные данные, в которых я нуждаюсь.
Вопрос: для моей ситуации действительно ли разумно сделать очистку заполненной таблицы, сопровождаемую вставкой? или я должен сделать обновление, вставить?
Мудрый SQL кажется как, УДАЛЯЮТ +, ВСТАВКА будет легче (ВСТАВЬТЕ часть, единственное SQL-выражение).
Править: RDBMS: MS SQL Server 2008 Ent
7 ответов
TRUNCATE будет быстрее, чем delete, поэтому, если вам нужно очистить таблицу, сделайте это вместо этого
Вы не указали поставщика РСУБД, но некоторые из них также имеют команды MERGE/UPSERT Это позволяет обновлять таблицу, если данные существуют, и вставлять, если они не существуют
Это частично зависит от способа доступа к данным. Если у вас есть период времени, когда к нему нет (или очень мало) пользователей, то это не окажет большого влияния на исчезновение данных (между DELETE и завершением INSERT) в течение короткого времени.
Что делать, если каких-то данных, которые были вчера, больше нет? Удаление может быть более безопасным, или вы все равно можете удалить некоторые записи.
И, в конце концов, не имеет значения, какой путь вы идете. Если в случае @kevinw не упоминается
Хотя я полностью согласен с ответом SQLMenace, я хотел бы отметить, что MERGE NOT удаляет ненужные записи! Если вы уверены, что ваши новые данные будут супер-набором существующих данных, то MERGE - это здорово, в противном случае вам нужно будет либо убедиться, что вы удалили все лишние записи позже, либо использовать метод TRUNCATE + INSERT ... (Лично я все еще являюсь поклонником последнего, так как обычно это довольно быстро,просто не забудьте заранее отбросить все индексы / уникальные ограничения и перестроить их один за другом. Это имеет то преимущество, что транзакция INSERT меньше, а добавление индекса выполняется в (меньших) транзакциях позже). (**)
(**: Да, это может быть сложно в живой системе, но опять же, он уже упоминал, что это было сделано во время какой-то ночи в любом случае, я экстраполирую в то время нет доступа пользователя)
Это зависит от размера таблицы и модели восстановления в базе данных. Если вы удаляете многие сотни тысяч записей и восстанавливаете их, а не обновляете небольшой пакет из нескольких сотен и вставляете десятки строк, это добавит ненужный размер вашим журналам транзакций. Однако вы можете использовать TRUNCATE, чтобы обойти это, так как это не повлияет на журнал транзакций.
Есть ли у вас возможность MERGE/UPSERT? Если вы используете MS-SQL, вы можете использовать CROSS APPLY, чтобы сделать что-то подобное, если вы этого не сделаете.
Один из подходов к решению проблем этого типа - вставить в новую таблицу, а затем выполнить переименование таблицы. Это гарантирует, что все новые данные будут присутствовать одновременно.
Рассматривали ли вы использование материализованного представления (MSSQL называет их индексированными представлениями) вместо того, чтобы делать это вручную? Это также может иметь другие преимущества в производительности, поскольку индексированное представление дает оптимизатору запросов больше возможностей выбора при построении планов выполнения для других запросов, которые ссылаются на таблицы в представлении.