Чем заменить distinct в sql
COUNT DISTINCT и оконные функции
Мы без проблем можем посчитать общее количество ПК для каждого производителя, а также количество уникальных моделей данного производителя в таблице PC:
|
Если нам требуется получить детальную информацию о каждой модели, наряду с их общим количеством для каждого производителя, то можно использовать оконную функцию:
|
Теперь представим, что нам требуется дополнить эту информацию количеством уникальных моделей. Естественная попытка
Использование ключевого слова DISTINCT не допускается с предложением OVER.
Сообщение об ошибке ясно описывает проблему. Вопрос в том, как её обойти.
Использование подзапроса
|
Использование DENSE_RANK
Что быстрее, выберите DISTINCT или GROUP BY в MySQL?
если у меня есть таблица
и я хочу получить все уникальные значения profession поле, что было бы быстрее (или рекомендуется):
15 ответов
они по существу эквивалентны друг другу (на самом деле это как некоторые базы данных реализации DISTINCT под капотом).
когда в сомнении, тест!
если у вас есть индекс на profession эти два слова-синонимы.
GROUP BY на MySQL результаты разные. Вы даже можете сделать:
и получить ваши профессии отсортированы в DESC порядок.
DISTINCT создает временную таблицу и использует его для хранения дубликатов. GROUP BY делает то же самое, но сортирует различные результаты впоследствии.
все ответы выше верны, для случая DISTINCT на одном столбце vs GROUP BY на одном столбце. Каждый движок БД имеет свою собственную реализацию и оптимизацию, и если вы заботитесь о очень маленькой разнице (в большинстве случаев), то вам нужно протестировать против конкретного сервера и конкретной версии! Как реализации могут измениться.
но, если вы выбираете более одного столбца в запросе, то DISTINCT существенно отличается! Потому что в этом случае это будет сравнить все столбцы всех строк, а не только один столбец.
Так что если у вас есть что-то вроде:
Это распространенная ошибка думать, что ключевое слово DISTINCT различает строки по первому столбцу, который вы указали, но DISTINCT является общим ключевым словом таким образом.
таким образом, люди, Вы должны быть осторожны, чтобы не принимать ответы выше как правильные для всех случаев. Вы можете запутаться и получить неправильные результаты, в то время как все, что вы хотели, было оптимизация!
well distinct может быть медленнее, чем group by в некоторых случаях в postgres (не знаю о других dbs).
равна
похоже, что запросы не совсем одинаковы. По крайней мере для MySQL.
второй запрос дает дополнительно «использование filesort» в Extra.
(более функциональное Примечание)
есть случаи, когда вам нужно использовать GROUP BY, например, если вы хотите получить количество сотрудников на работодателя:
в таком случае DISTINCT u.employer работает неправильно. Возможно, есть способ, но я просто не знаю его. (Если кто-то знает, как сделать такой запрос с DISTINCT, пожалуйста, добавьте Примечание!)
Если вам не нужно выполнять какие-либо групповые функции (sum, average и т. д., Если вы хотите добавить числовые данные в таблицу), используйте SELECT DISTINCT. Я подозреваю, что это быстрее, но у меня нет ничего, чтобы показать это.
в любом случае, если вы беспокоитесь о скорости, создать индекс по столбцу.
после тяжелых испытаний мы пришли к выводу, что GROUP BY быстрее
выберите sql_no_cache opnamegroep_intern От telwerken Где opnemergroep IN (7,8,9,10,11,12,13) группа по opnamegroep_intern
635 totaal 0.0944 сек Weergave van records 0-29 (635 totaal, query duurde 0.0484 sec)
выберите sql_no_cache distinct (opnamegroep_intern) От telwerken Где opnemergroep IN (7,8,9,10,11,12,13)
635 totaal 0.2117 секунд ( почти 100% медленнее ) Weergave van records 0-29 (635 totaal, query duurde 0.3468 sec)
в моем проекте когда-то я использую group by и другие distinct
вот простой подход, который будет печатать 2 разных времени для каждого запроса.
Он просто отображает количество миллисекунд, необходимых для анализа, компиляции и выполнения каждого оператора, как показано ниже:
SELECT DISTINCT всегда будет одинаковым или быстрее, чем GROUP BY. В некоторых системах (например, Oracle) он может быть оптимизирован так же, как и для большинства запросов. На других (например, SQL Server) это может быть значительно быстрее.
Если проблема позволяет это, попробуйте с EXISTS, так как она оптимизирована для завершения, как только результат будет найден (и не буферизуйте какой-либо ответ), поэтому, если вы просто пытаетесь нормализовать данные для предложения WHERE, как это
более быстрый ответ был бы:
это не всегда возможно, но при наличии вы увидите более быстрый ответ.
Оператор SELECT
Наиболее используемым, но и самым сложным оператором является оператор выборки SELECT. Он позволяет производить выборку данных из таблиц и преобразовывать к нужному виду полученные результаты.
Результатом выполнения оператора SELECT является таблица. К этой таблице может быть снова применен оператор SELECT и т.д., то есть такие операторы могут быть вложены друг в друга. Вложенные операторы SELECT называют подзапросами.
Синтаксис оператора SELECT использует следующие основные предложения:
Кратко пояснить смысл предложений оператора SELECT можно следующим образом:
База данных для примеров
Дальше будет много примеров и логично постоянно использовать одну и ту же БД, что бы не рисовать каждый раз новые. На основании базы данных ниже будут продемонстрированы все примеры, не только в этой статье, но и в других.
Постановка задачи: пусть требуется разработать БД для предметной области «Поставка деталей»!
Требуется хранить следующую информацию:
Значения таблицы P:
| pnum | pname |
|---|---|
| 1 | Иванов |
| 2 | Петров |
| 3 | Сидоров |
| 4 | Кузнецов |
Значения таблицы D:
| pnum | dname | dprice |
|---|---|---|
| 1 | Болт | 10 |
| 2 | Гайка | 20 |
| 3 | Винт | 30 |
Значения таблицы PD:
| pnum | dnum | volume |
|---|---|---|
| 1 | 1 | 100 |
| 1 | 2 | 100 |
| 1 | 3 | 300 |
| 2 | 1 | 150 |
| 1 | 2 | 250 |
| 3 | 1 | 1000 |
Блок помощи
Предложение SELECT
После служебного слова SELECT перечисляются имена столбцов, значения которых будут входить в результат выполнения запроса.
Если имя столбца содержит пробелы или разделители, то его необходимо заключить в квадратные скобки.
Предложение FROM
Пример 1.
Вывести список наименований деталей из таблицы D (“Детали”).
Пример 2.
Получить всю информацию из таблицы D (“Детали”).
Получить результат можно двумя способами:
В результате и первого и второго запроса получаем новую таблицу, представляющую собой полную копию таблицы D (“Детали”).
Можно осуществить выбор отдельных столбцов и их перестановку.
Пример 3.
Получить информацию о наименовании и номере поставщика.
Пример 4.
Определить номера поставщиков, которые поставляют детали в настоящее время (то есть номера тех поставщиков, которые присутствуют в таблице PD (“Поставки”)).
| pnum |
|---|
| 1 |
| 1 |
| 1 |
| 2 |
| 2 |
| 3 |
Дополнительно о SELECT
Агрегатные функции
В операторе SELECT можно использовать агрегатные функции, которые дают единственное значение для целой группы строк в таблице.
Агрегатная функция записывается в следующем виде: ( )
Пользователю доступны следующие агрегатные функции:
Пример 15.
Определить общий объем поставляемых деталей.
Столбцы результирующей таблицы, которых не существовало в исходных таблицах, называются вычисляемыми. Таким столбцам СУБД присваивает системные имена, что не всегда является удобным.
Следует запомнить, что агрегатные функции нельзя вкладывать друг в друга. Такая конструкция работать не будет: `MAX(SUM(VOLUME))`
Переименование столбца
Например, присвоить новое имя вычисляемому столбцу в предыдущем примере позволит выполнение следующего запроса.
Пример 16.
Определить количество поставщиков, которые поставляют детали в настоящее время.
Несмотря на то, что реальное число поставщиков деталей в таблице PD равно 3, СУБД возвращает число 6. Такой результат объясняется тем, что СУБД подсчитывает все строки в таблице PD, не обращая внимание на то, что в строках есть одинаковые значения.
Операция DISTINCT
Операция TOP
Итоговый набор записей, получаемых после выполнения запроса можно ограничить первыми N строками или первыми N процентами от общего количества строк результата.
Пример 23.
Определить номера первых двух деталей таблицы D.
Предложение WHERE
После служебного слова WHERE указываются условия выбора строк, помещаемых в результирующую таблицу. Существуют различные типы условий выбора:
Типы условий выбора:
Сравнение
Пример 5.
Определить номера деталей, поставляемых поставщиком с номером 2.
Пример 6.
Получить информацию о поставщиках Иванов и Петров.
Строковые значения атрибутов заключаются в апострофы.
Проверка на принадлежность множеству
Операция IN проверяет, принадлежит ли значение атрибута заданному множеству.
Пример 7.
Получить информацию о поставщиках ‘Иванов’ и ‘Петров’.
Пример 8.
Получить информацию о деталях с номерами 1 и 2.
Проверка на принадлежность диапазону
Операция BETWEEN определяет минимальную и максимальную границу диапазона, в которое должно попадать значение атрибута. Обе границы считаются принадлежащими диапазону.
Пример 9.
Определить номера деталей, с ценой от 10 до 20 рублей.
Пример 10.
Вывести наименования поставщиков, начинающихся с букв от ‘К’ по ‘П’.
Буква ‘Р’ в условии запроса объясняется тем, что строки сравниваются посимвольно. Для каждого символа при этом определяется код. Для нашего случая справедливо условие: ‘П’ LIKE используется для поиска подстрок. Значения столбца, указываемого перед служебным словом LIKE сравниваются с задаваемым после него шаблоном. Форматы шаблонов различаются в конкретных СУБД.
Для СУБД MS SQL Server:
Множество символов в квадратных скобках можно указывать через запятую, либо в виде диапазона.
Пример 11.
Вывести фамилии поставщиков, начинающихся с буквы ‘И’.
Пример 12.
Вывести фамилии поставщиков, начинающихся с букв от ‘К’ по ‘П’.
Проверка на наличие null-значения
Пример 13.
Определить наименования деталей, для которых не указана цена.
Пример 14.
Определить номера поставщиков, для которых указано наименование.
Предложение GROUP BY
Использование GROUP BY позволяет разбивать таблицу на логические группы и применять агрегатные функции к каждой из этих групп. В результате получим единственное значение для каждой группы.
Обычно предложение GROUP BY применяют, если формулировка задачи содержит фразу «для каждого…», «каждому..» и т.п.
Пример 18.
Определить суммарный объем деталей, поставляемых каждым поставщиком.
| pnum | sum |
|---|---|
| 1 | 600 |
| 2 | 400 |
| 3 | 1000 |
Выполнение запроса можно описать следующим образом: СУБД разбивает таблицу PD на три группы, в каждую из групп помещаются строки с одинаковым значением номера поставщика. Затем к каждой из полученных групп применяется агрегатная функция SUM, что дает единственное итоговое значение для каждой группы.
Рассмотрим два похожих примера.
В примере 1 определяется минимальный объем поставки каждого поставщика. В примере 2 определяется объем минимальной поставки среди всех поставщиков.
Результаты запросов представлены в следующей таблице:
| pnum | min | max |
|---|---|---|
| 1 | 100 | 100 |
| 2 | 150 | |
| 3 | 1000 |
Следует обратить внимание, что в первом примере мы можем вывести номера поставщиков, соответствующие объемам поставок, а во втором примере – не можем.
Пример 19.
Для каждой из деталей с номерами 1 и 2 определить количество поставщиков, которые их поставляют, а также суммарный объем поставок деталей.
| dnum | COUNT | SUM |
|---|---|---|
| 1 | 3 | 1250 |
| 2 | 2 | 450 |
Чтобы организовать вложенные группировки, после GROUP BY следует указать несколько группирующих столбцов через запятую. В этом случае реальный подсчет данных будет происходить по той группе, которая указана последней.
Предложение HAVING
Пример 20.
Определить номера поставщиков, поставляющих в сумме более 500 деталей.
| pnum | SUM |
|---|---|
| 1 | 600 |
| 3 | 1000 |
Пример 21.
Определить номера поставщиков, которые поставляют только одну деталь.
Предложение ORDER BY
При выполнении запроса СУБД возвращает строки в случайном порядке. Предложение ORDER BY позволяет упорядочить выходные данные запроса в соответствии со значениями одного или нескольких выбранных столбцов.
Пример 22.
Отсортировать таблицу PD в порядке возрастания номеров поставщиков, а строки с одинаковыми значениями pnum отсортировать в порядке убывания объема поставок.
| pnum | volume | dnum |
|---|---|---|
| 1 | 300 | 3 |
| 1 | 200 | 2 |
| 1 | 100 | 1 |
| 2 | 250 | 2 |
| 2 | 150 | 1 |
| 3 | 1000 | 1 |
Пример 24.
Определить номера первых двух деталей с наименьшей стоимостью.
Следует отметить, что если в таблице D будут две детали без указания цены, то именно их и отобразит предыдущий запрос.
Чем заменить distinct в sql
Здравствуйте, dvd00, Вы писали:
D>Коллеги! Мне нужно оптимизировать SELECT запрос, который использует keyword DISTINCT так, чтобы этого кейворда не было, но повторяющиеся записи не выбирались. Подозреваю, что это мона сделать с помощью хитрых join-ов, но не могу их придумать. Мот кто сталкивался с такой проблемой — подскажите пжлст.
Универсальный метод один — использовать вместо DISTINCT GROUP BY.
На деле же необходимость в DISTINCT как правило означает некорректный запрос либо плохо спроектированную базу. В первую очередь надо понять, откуда идет дублирование записей. Достаточно часто это результат некорректной структуры запроса, в который втягиваются лишние записи (которые потом и приходится подавлять).
Если же причина в данных — тут так или иначе надо давить дубли. Постановка задачи заставляет предположить, что этот запрос необходимо втиснуть в прокрустово ложе какого-то стандартного генератора, поэтому ключевой вопрос — а какие еще ограничения?
 | От: | PPA | http://flylinkdc.blogspot.com/ |
| Дата: | 20.09.04 08:55 | ||
| Оценка: |
Здравствуйте, dvd00, Вы писали:
D>Коллеги! Мне нужно оптимизировать SELECT запрос, который использует keyword DISTINCT так, чтобы этого кейворда не было, но повторяющиеся записи не выбирались. Подозреваю, что это мона сделать с помощью хитрых join-ов, но не могу их придумать. Мот кто сталкивался с такой проблемой — подскажите пжлст.
Не совсем очевидна твоя «проблема».
А какой смысл избавится от этого слова. ухо режет 
?
Дубли убрать из набора данных без кей слова DISTINCT можно так:
1.
select a,b,c from t
group by a,b,c
2.
select a,b,c from t
union
select a,b,c from t where 1=2
3.
джойном(даже хитрым) имхо это сделать нельзя.
 | От: | dvd00 |
| Дата: | 20.09.04 09:19 | |
| Оценка: |
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, dvd00, Вы писали:
D>>Коллеги! Мне нужно оптимизировать SELECT запрос, который использует keyword DISTINCT так, чтобы этого кейворда не было, но повторяющиеся записи не выбирались. Подозреваю, что это мона сделать с помощью хитрых join-ов, но не могу их придумать. Мот кто сталкивался с такой проблемой — подскажите пжлст.
S>Универсальный метод один — использовать вместо DISTINCT GROUP BY.
S>На деле же необходимость в DISTINCT как правило означает некорректный запрос либо плохо спроектированную базу. В первую очередь надо понять, откуда идет дублирование записей. Достаточно часто это результат некорректной структуры запроса, в который втягиваются лишние записи (которые потом и приходится подавлять).
S>Если же причина в данных — тут так или иначе надо давить дубли. Постановка задачи заставляет предположить, что этот запрос необходимо втиснуть в прокрустово ложе какого-то стандартного генератора, поэтому ключевой вопрос — а какие еще ограничения?
На самом деле моя задача состоит в рефакторинге сторед-процедуры с целью увеличения ее быстродействия. Править структуру БД низя никоим образом — она кривая и клиент будет против 
Поэтому вот главные ограничения: структуру таблиц не трогать, скорость работы процедуры увеличить (это скорее требование). Все что мона было в этой процедуре я поправил, стало немного быстрее, и вот осталось убрать энтот дистинкт, чтобы работало еще быстрее.
 | От: | Softwarer | http://softwarer.ru |
| Дата: | 20.09.04 09:46 | ||
| Оценка: |
Здравствуйте, dvd00, Вы писали:
D>На самом деле моя задача состоит в рефакторинге сторед-процедуры с целью увеличения ее быстродействия. Править структуру БД низя никоим образом — она кривая и клиент будет против Поэтому вот главные ограничения: структуру таблиц не трогать, скорость работы процедуры увеличить (это скорее требование). Все что мона было в этой процедуре я поправил, стало немного быстрее, и вот осталось убрать энтот дистинкт, чтобы работало еще быстрее.
Оптимизация запроса — это вообще отдельная песня. Насколько я помню, кто-то здесь говорил, что в MS SQL distinct то ли заметно быстрее group by, то ли наоборот. В Oracle, например, они не то что одинаковы — физически одинаково выполняются.
Из общих соображений — надо все-таки посмотреть, из данных ли идет это дублирование, либо из плохо сконструированного запроса. Поскольку бывает, что в запросе оказывается что-нибудь типа select distinct master_id from details. На самом деле я не помню ни одного случая, когда мне приходилось в программе использовать distinct — каждый раз оказывалось, что вместо этого надо аккуратнее написать запрос.
 | От: | Strong |
| Дата: | 21.09.04 13:18 | |
| Оценка: |
Здравствуйте, dvd00, Вы писали:
D>Коллеги! Мне нужно оптимизировать SELECT запрос, который использует keyword DISTINCT так, чтобы этого кейворда не было, но повторяющиеся записи не выбирались. Подозреваю, что это мона сделать с помощью хитрых join-ов, но не могу их придумать. Мот кто сталкивался с такой проблемой — подскажите пжлст.
Это можно сделать с помощью EXISTS.
Причем вариант 2 работает значительно быстрее, тк без Distinct нет необходимости в сортировке строк.
Чем заменить distinct в sql
Альтернатива SELECT DISTINCT
Я не слишком хорошо разбираюсь в SQL-запросах, но заметил значительное снижение производительности при выполнении запроса с помощью Select Distinct. Я запускаю SQL Server 2008 R2. Ниже приведен мой запрос:
Кто-нибудь знает, как отредактировать этот запрос, не используя select select, чтобы ускорить запрос, возвращая те же результаты? Любая помощь приветствуется. спасибо.
Вам нужно только DISTINCT из-за JOIN.
Поэтому не используйте JOIN: используйте EXISTS и нажимайте все таблицы, которые вы фактически не выбираете из предложения EXISTS
Чем заменить distinct в sql
Здравствуйте, dvd00, Вы писали:
D>Коллеги! Мне нужно оптимизировать SELECT запрос, который использует keyword DISTINCT так, чтобы этого кейворда не было, но повторяющиеся записи не выбирались. Подозреваю, что это мона сделать с помощью хитрых join-ов, но не могу их придумать. Мот кто сталкивался с такой проблемой — подскажите пжлст.
Универсальный метод один — использовать вместо DISTINCT GROUP BY.
На деле же необходимость в DISTINCT как правило означает некорректный запрос либо плохо спроектированную базу. В первую очередь надо понять, откуда идет дублирование записей. Достаточно часто это результат некорректной структуры запроса, в который втягиваются лишние записи (которые потом и приходится подавлять).
Если же причина в данных — тут так или иначе надо давить дубли. Постановка задачи заставляет предположить, что этот запрос необходимо втиснуть в прокрустово ложе какого-то стандартного генератора, поэтому ключевой вопрос — а какие еще ограничения?
| От: | PPA | http://flylinkdc.blogspot.com/ |
| Дата: | 20.09.04 08:55 | |
| Оценка: |
Здравствуйте, dvd00, Вы писали:
D>Коллеги! Мне нужно оптимизировать SELECT запрос, который использует keyword DISTINCT так, чтобы этого кейворда не было, но повторяющиеся записи не выбирались. Подозреваю, что это мона сделать с помощью хитрых join-ов, но не могу их придумать. Мот кто сталкивался с такой проблемой — подскажите пжлст.
Дубли убрать из набора данных без кей слова DISTINCT можно так:
1.
select a,b,c from t
group by a,b,c
2.
select a,b,c from t
union
select a,b,c from t where 1=2
3.
джойном(даже хитрым) имхо это сделать нельзя.
| От: | dvd00 |
| Дата: | 20.09.04 09:19 |
| Оценка: |
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, dvd00, Вы писали:
D>>Коллеги! Мне нужно оптимизировать SELECT запрос, который использует keyword DISTINCT так, чтобы этого кейворда не было, но повторяющиеся записи не выбирались. Подозреваю, что это мона сделать с помощью хитрых join-ов, но не могу их придумать. Мот кто сталкивался с такой проблемой — подскажите пжлст.
S>Универсальный метод один — использовать вместо DISTINCT GROUP BY.
S>На деле же необходимость в DISTINCT как правило означает некорректный запрос либо плохо спроектированную базу. В первую очередь надо понять, откуда идет дублирование записей. Достаточно часто это результат некорректной структуры запроса, в который втягиваются лишние записи (которые потом и приходится подавлять).
S>Если же причина в данных — тут так или иначе надо давить дубли. Постановка задачи заставляет предположить, что этот запрос необходимо втиснуть в прокрустово ложе какого-то стандартного генератора, поэтому ключевой вопрос — а какие еще ограничения?
На самом деле моя задача состоит в рефакторинге сторед-процедуры с целью увеличения ее быстродействия. Править структуру БД низя никоим образом — она кривая и клиент будет против Поэтому вот главные ограничения: структуру таблиц не трогать, скорость работы процедуры увеличить (это скорее требование). Все что мона было в этой процедуре я поправил, стало немного быстрее, и вот осталось убрать энтот дистинкт, чтобы работало еще быстрее.
| От: | Softwarer | http://softwarer.ru |
| Дата: | 20.09.04 09:46 | |
| Оценка: |
Здравствуйте, dvd00, Вы писали:
D>На самом деле моя задача состоит в рефакторинге сторед-процедуры с целью увеличения ее быстродействия. Править структуру БД низя никоим образом — она кривая и клиент будет против Поэтому вот главные ограничения: структуру таблиц не трогать, скорость работы процедуры увеличить (это скорее требование). Все что мона было в этой процедуре я поправил, стало немного быстрее, и вот осталось убрать энтот дистинкт, чтобы работало еще быстрее.
Оптимизация запроса — это вообще отдельная песня. Насколько я помню, кто-то здесь говорил, что в MS SQL distinct то ли заметно быстрее group by, то ли наоборот. В Oracle, например, они не то что одинаковы — физически одинаково выполняются.
Из общих соображений — надо все-таки посмотреть, из данных ли идет это дублирование, либо из плохо сконструированного запроса. Поскольку бывает, что в запросе оказывается что-нибудь типа select distinct master_id from details. На самом деле я не помню ни одного случая, когда мне приходилось в программе использовать distinct — каждый раз оказывалось, что вместо этого надо аккуратнее написать запрос.
| От: | Strong |
| Дата: | 21.09.04 13:18 |
| Оценка: |
Здравствуйте, dvd00, Вы писали:
D>Коллеги! Мне нужно оптимизировать SELECT запрос, который использует keyword DISTINCT так, чтобы этого кейворда не было, но повторяющиеся записи не выбирались. Подозреваю, что это мона сделать с помощью хитрых join-ов, но не могу их придумать. Мот кто сталкивался с такой проблемой — подскажите пжлст.
Это можно сделать с помощью EXISTS.
Причем вариант 2 работает значительно быстрее, тк без Distinct нет необходимости в сортировке строк.
SQL Server 2014 Заменить Distinct? Деидентифицировать данные
Я собираюсь снова объяснить, что я пытаюсь сделать, в надежде, что вы можете помочь.
Таблица 1 содержит 4061 строку со столбцами, включающими [Имя], [Адрес1], [Адрес2], [Адрес3], [Город], [Штат], [Почтовый индекс], [Страна], [Телефон] и 20 других столбцов. Таблица 1 — это данные, которые необходимо деидентифицировать. Таблица 1 содержит 1534 отдельных строки [Имя] из 4061 строки.
Таблица 2 содержит автоматически сгенерированные данные, которые включают те же столбцы. Я хотел бы заменить вышеупомянутые столбцы в таблице 1 данными из таблицы 2. Я хочу выбрать разные на основе [Имя] из таблицы 1, а затем [Имя], [Адрес1], [Адрес2], [Адрес3], [ Город], [Штат], [Почтовый индекс], [Страна], [Телефон] с новым набором отдельных данных из таблицы 2.
Я не хочу просто обновлять каждую строку новым адресом, так как это нарушит согласованность данных. Заменив только отдельные, это позволит мне сохранить согласованность данных при изменении данных строки в таблице 1. Когда я закончу, я хотел бы иметь 1534 отдельных новых обезличенных [Имя] [Адрес1], [Адрес2], [Адрес3 ], [Город], [Штат], [Почтовый индекс], [Страна], [Телефон] в таблице 1 из таблицы 2.
2 ответа
Вот как я это сделал. Сначала я запустил оператор, чтобы выбрать отдельные, и вставил его в таблицу.
Затем я добавил столбец name2 в APMAST2 и использовал оператор для создания последовательного поля идентификатора в APMAST2.
Теперь у меня есть отдельная информация плюс пустое поле имени и поле последовательного идентификатора в APMAST2. Теперь я могу присоединиться к этой дате со своей таблицей fakenames, из которой я сгенерировал. ЗДЕСЬ, используя их массовый инструмент.
Используя оператор соединения, я объединил свои поддельные данные с APMAST2
Теперь у меня загружены поддельные данные, но я сохранил свое исходное поле Name, чтобы я мог перезагрузить эти данные в свою полную таблицу ARMAST, чтобы теперь я мог выполнить соединение между ARMAST2 и ARMAST.
Теперь в моей исходной таблице есть все фальшивые данные, но она сохраняет целостность, которую она имела, ну и большую часть, поэтому данные выглядят хорошо при составлении отчетов, но не идентифицируются. Теперь вы можете удалить APMAST2 или оставить его, если позже вам потребуется сопоставить его с другими данными. Я знаю, что это долго, и я уверен, что есть лучший способ сделать это, но я сделал это так, предложения приветствуются.