пример поиска SQL соединения, который удаляет записи о нарушении (удаление строк, очистка строк SQL соединение)

Question

Рассматриваемый механизм SQL - это SSMS (SQL Server Management Studio V18.5), хотя я сомневаюсь, что версия актуальна для этого запроса.

У меня есть таблица A, которая является источником информации . Также есть таблица B, которая представляет собой журнал результатов сложного запроса X, содержащего около шести соединений. Инструмент обрабатывает выходные данные этого запроса для выполнения sh рабочего усилия во внешнем инструменте, а затем записывает эти рабочие данные в таблицу C.

Итак, мы имеем:

• Таблица-A: источник данных
• Complex-Query-X: запрос с несколькими соединениями, создающий список рабочих элементов (Таблица-A является одним из многих источников для этого)
• Таблица-B: список результатов вывода из Complex-Query-X с течением времени
• Table- C: список рабочих элементов из Complex-Query-X, над которыми были выполнены трудозатраты, выполненная работа, результаты эта работа, et c

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

Я не новичок в SQL, но я никогда раньше не пробовал удалять записи с объединениями. Множество ссылок в Интернете посвящено SQL присоединениям, способам и причинам их использования, но ни один из них не описывает удаление данных способом, который, как я видел, соответствует нашим целям.

Это также пришло в голову Мне кажется, что я стар и мне может не хватать чего-то очевидного, если я только добавляю данных к моему большому запросу соединения, поэтому мой запрос здесь (например, - чтобы его не нужно было удалять). Здесь я запнулся?

Answer 1

Ответ в итоге оказался набором параметров, из которых я выбрал третий:

• ограничить исходный запрос, чтобы «данные для удаления» не присутствовали после выполнения основного запроса - этот вариант было немного сложно представить, учитывая способ объединения данных (сотни тысяч строк, около семи (7) источников), однако это было, по крайней мере, мыслимо.
• критерий левого соединения в конце структура соединения запроса, которая принудительно использует идентификаторы с нулевым ключом для несовпадающих строк (что позволяет легко игнорировать их с помощью инструментов, которые используют указанный запрос)
• предложение where, которое автоматически удаляет целевые строки - это был самый простой и также был, по крайней мере, сравнительно эффективен в анализе с обоими другими вариантами запроса - так, как указано выше, это было фактически выбранное нами направление вместе с левым соединением по причинам, которые здесь не будут подробно описаны

Моя личная благодарность всем как за вклад, так и за критику, такую ​​как они были. Мои личные извинения за то, что я не более откровенен в отношении того, что именно происходит с фактическими источниками и образцами данных, учреждение, которое нанимает меня, довольно скрытно в этом виде вещей, и я был слишком занят / ленив, чтобы выдумать достаточно примеров, когда у меня были другие варианты.

Тем не менее, вопросы этого типа действительно более академичны c и не должны требовать жестких примеров, и я говорю это, зная, что если бы я был на месте читателя, я бы сам на самом деле предпочитаю пример, если бы у меня была возможность. Я действительно составил быструю схему линий для вечеринки, которая в конечном итоге привела к моему окончательному выбору, но даже это больше, чем я бы предпочел опубликовать в контексте publi c.