Обновление этого поста для большей наглядности.
Следующая проблема связана с CROSS-APPLY (я также установил CROSS-JOIN), но я не могу найти простой способ, используя внутреннее соединение или раздел
- сделать каждую запись уникальной - без дубликатов, а также
2) убедиться, что каждая уникальная запись в порядке ... 174..175, 176, 177и т.д. Я ожидаю около 3200 записей здесь, а не 174000 записей, которые я получаю.
Может ли кто-нибудь предоставить свое мнение о том, что я могу сделать, чтобы убедиться, что я привел записи в порядок?Спасибо сообществу!См. Код и данные.
После выполнения запроса ниже - я получаю следующие результаты.Как видно из приведенных ниже данных, если я заказываю по контракту, я получаю дубликаты - что я не должен делать с идентификаторами, сгенерированными для каждого перекрестного обращения.Перекрестное применение приводит к тому, что эти дубликаты одной и той же записи генерируются с разными идентификаторами - способ, которым он должен работать, - это как только запись создается с идентификатором - это должен быть единственный экземпляр этой записи.
Я также выделил жирным шрифтом те части своего кода, в которых я получаю идентификатор строки, следующий за последним максимальным экземпляром идентификатора из предыдущей выбранной строки, но вызывающий дублирование.
Так что дляустановка ожидания - изображение ниже суб-выбора говорит мне, что уже существует в таблице, с которой я ссылаюсь на логику - говорит мне, что НЕ существует
173 записей - см. изображение
Следующее изображение говорит мне, что весь мой запрос выбирает то, что НЕ СУЩЕСТВУЕТ, и генерирует записи, начиная со строки 174 - это очень хорошо, но я был встревожен тем, сколько записей я получил - есть только3875 различных контрактов, поэтому я должен получать только 3875 записей - не 174, как вы видите.
Слишком много записей - см. Изображение
Поэтому я переупорядочил запросContract_TaskOrder - и я вижу тонну дубликатов и повторное назначение дубликатов нового идентификатора.Смотрите изображение ниже.Перекрестное применение вызывает записи для каждого уникального экземпляра контракта в таблице [Stage]. [BUD_PLN_Spendpln_Dataload_Staging_E_Grouped] и создает, сколько раз оно определяется с помощью декартового произведения - это очень и очень плохо.Я пытаюсь найти способ с внутренним объединением, чтобы сделать это - но безрезультатно.
Как видите - дублирует названия контрактов - дерьмо ... смотрите это
Вот мой полный запрос - необходимо улучшить жирный шрифт, чтобы можно было удалять не только дубликаты, но и идентификатор, начиная с 174 и указывать для каждого уникального ИМЯ - привязанного к Contract-TaskOrder.Если бы я только сделал раздел, включив в него первую 1 или максимальную запись каждого комбо, у меня были бы записи с очень широко разреженными идентификаторами ACLORDER, основанными на последовательности.
SELECT * FROM
(
SELECT DISTINCT
'READWRITE' AS [ACCESSMODE],
3 AS [ACCESSMODEORDER],
**coalesce(const.maxs, 0) + row_number() over (
order by (select NULL)) AS [ACLORDER]**,
0 AS [ACLSFK],
'MEMBER' AS [FLAG],
4 AS [FLAGORDER],
'N' AS [ISUSER],
5 AS [ISUSERORDER],
('SPS-Contract-' + Contract_TaskOrder) AS [NAME],
0 AS [NAMEORDER],
Contract_TaskOrder AS [OBJECTNAME],
1 AS [OBJECTNAMEORDER],
'SL_DIMENSION' AS [OBJECTTYPE],
2 AS [OBJECTTYPEORDER],
NULL AS [PARENT],
NULL AS [PARENTORDER]
FROM
**[Stage].[BUD_PLN_Spendpln_Dataload_Staging_E_Grouped] cross apply (
select max(ACLORDER) as maxs
from [BFS_ODI_WORK].[Stage].[BUD_PLN_SECURITY_MEMBERS] ) const
)**
M
WHERE
1 = 1
AND NOT EXISTS
(
SELECT
1
FROM
[BFS_ODI_WORK].[Stage].[BUD_PLN_SECURITY_MEMBERS] k
WHERE
M.[NAME] = k.[NAME]
AND M.[FLAG] = k.[FLAG]
AND M.[OBJECTNAME] = k.[OBJECTNAME]
AND M.[OBJECTTYPE] = k.[OBJECTTYPE]
)
order by
NAME