У меня есть таблица, содержащая информацию о клиентах. Каждому клиенту присваивается идентификатор клиента (их SSN), который они сохраняют при открытии большего количества учетных записей. Два клиента могут находиться на одной учетной записи, каждый со своим идентификатором. Номера счетов не упорядочены по дате.
Я хотел бы найти самую последнюю учетную запись для каждого клиента или группы клиентов. Если два клиента когда-либо были в аккаунте вместе, я хочу вернуть самую последнюю учетную запись, на которой был включен клиент.
Вот примерная таблица с некоторыми из возможных случаев.
Пример таблицы ACCT:
acctnumber date Cust1ID Cust2ID
10000 '2016-02-01' 1110 NULL --Case0-customer has only ever had
--one account
10001 '2016-02-01' 1111 NULL --Case1-one customer has multiple
10050 '2017-02-01' 1111 NULL --accounts
400050 '2017-06-01' 1111 NULL
10089 '2017-12-08' 1111 NULL
10008 '2016-02-01' 1120 NULL --Case2-customer has account(s) and later
10038 '2016-04-01' 1120 NULL
10058 '2017-02-03' 1120 1121 --gets account(s) with another customer
10002 '2016-02-01' 1112 NULL --Case3-customer has account(s) and later
10052 '2017-02-02' 1113 1112 --becomes the second customer on another
10152 '2017-05-02' 1113 1112 --account(s)
10003 '2016-02-02' 1114 1115 --Case4-customer and second customer
7060 '2017-02-04' 1115 1114 --switch which is first and second
10004 '2016-02-02' 1116 1117 --Case5-second customer later gets
10067 '2017-02-05' 1117 NULL --separate account(s)
10167 '2018-02-05' 1117 NULL
50013 '2016-01-01' 2008 NULL --Case5b -customer has account(s) & later
50014 '2017-02-02' 2008 2009 --gets account(s) with second customer &
50015 '2017-04-04' 2008 NULL --later still first customer gets
100015 '2018-05-05' 2008 NULL --separate account(s)
30005 '2015-02-01' 1118 NULL --Case6-customer has account(s)
10005 '2016-02-01' 1118 NULL
10054 '2017-02-02' 1118 1119 --gets account(s) with another
40055 '2017-03-03' 1118 1119
10101 '2017-04-04' 1119 NULL --who later gets separate account(s)
10201 '2017-05-05' 1119 NULL
30301 '2017-06-06' 1119 NULL
10322 '2018-01-01' 1119 NULL
10007 '2016-02-01' 1122 1123 --Case7-customers play musical chairs
10057 '2017-02-03' 1123 1124
10107 '2017-06-02' 1124 1125
50001 '2016-01-01' 2001 NULL --Case8a-customers with account(s)
50002 '2017-02-02' 2001 2002 --together each later get separate
50003 '2017-03-03' 2001 NULL --account(s)
50004 '2017-04-04' 2002 NULL
50005 '2016-01-01' 2003 NULL --Case8b-customers with account(s)
50006 '2017-02-02' 2003 2004 --together each later get separate
50007 '2017-03-03' 2004 NULL --account(s)
50008 '2017-04-04' 2003 NULL
50017 '2018-03-03' 2004 NULL
50018 '2018-04-04' 2003 NULL
50009 '2016-01-01' 2005 NULL --Case9a-customer has account(s) & later
50010 '2017-02-02' 2005 2006 --gets account(s) with a second customer
50011 '2017-03-03' 2005 2007 --& later still gets account(s) with a
--third customer
50109 '2016-01-01' 2015 NULL --Case9b starts the same as Case9a, but
50110 '2017-02-02' 2015 2016
50111 '2017-03-03' 2015 2017
50112 '2017-04-04' 2015 NULL --after all accounts with other customers
50122 '2017-05-05' 2015 NULL --are complete, the original primary
--customer begins opening individual
--accounts again
Желаемые результаты:
acctnumber date Cust1ID Cust2ID
10000 '2016-02-01' 1110 NULL --Case0
10089 '2017-12-08' 1111 NULL --Case1
10058 '2017-02-03' 1120 1121 --Case2
10152 '2017-05-02' 1113 1112 --Case3
7060 '2017-02-04' 1115 1114 --Case4
10167 '2018-02-05' 1117 NULL --Case5
100015 '2018-05-05' 2008 NULL --Case5b
10322 '2018-01-01' 1119 NULL --Case6
10107 '2017-06-02' 1124 1125 --Case7
50003 '2017-03-03' 2001 NULL --Case8a result 1
50004 '2017-04-04' 2002 NULL --Case8a result 2
50017 '2018-03-03' 2004 NULL --Case8b result 1
50018 '2018-04-04' 2003 NULL --Case8b result 2
50011 '2017-03-03' 2005 2007 --Case9a
50122 '2017-05-05' 2015 NULL --Case9b
В качестве альтернативы, я бы принял Case 7, выводящий две отдельные группы клиентов:
10007 '2016-02-01' 1122 1123 --Case7 result 1
10107 '2017-06-02' 1124 1125 --Case7 result 2
Поскольку Cases 8a & 8b будут представлять компанию, признающую, что клиенты достойны проведения отдельных счетов, мы хотели бы затем рассмотреть их группу как разделение, поэтому у нее есть отдельные наборы результатов.
Кроме того, в большинстве сценариев клиенты имеют множество учетных записей, а также смешивают и сопоставляют вышеуказанные случаи сверхурочной работы. Например, у одного клиента может быть пять учетных записей (случай 1), а затем открывается одна или несколько учетных записей другим клиентом (случай 3), иногда переключение основного владельца учетной записи (случай 4), после чего первый клиент снова начинает открытие индивидуальных счетов ( Случай 5b).
Я попытался присоединиться к таблице к копии самого себя, когда acctnumbers уникальны, и любой из идентификаторов Cust ID. Тем не менее, это удаляет клиентов, у которых была только одна учетная запись, поэтому я добавил объединение сдерживания, которое не имеет совпадений по custid или номеру учетной записи и группам custid.
К сожалению, вторая часть не только включает custids из случая 0, но есть некоторые custids, которые исключаются вместе, что не должно быть.
select
max(date1) as date,
cust1id1 as cust1id
from
(
select
acctnumber as [acctnumber1],
date as [date1],
cust1id as [cust1id1],
cust2id as [cust2id1]
from
acct
) t1
join
(
select
acctnumber as [acctnumber2],
date as [date2],
cust1id as [cust1id2],
cust2id as [cust2id2]
from
acct
) t2
on t1.date1 > t2.date2 and
(t1.cust1id1 = t2.cust1id2 or
t1.cust1id1 = t2.cust2id2 or
t1.cust2id1 = t2.cust2id2)
Group by
cust1id1
union
select
max(date1) as date,
cust1id1 as cust1id
from
(
select
acctnumber as [acctnumber1],
date as [date1],
cust1id as [cust1id1],
cust2id as [cust2id1]
from
acct
) t1
join
(
select
acctnumber as [acctnumber2],
date as [date2],
cust1id as [cust1id2],
cust2id as [cust2id2]
from
acct
) t2
on (t1.acctnumber1 != t2.acctnumber2 and
t1.cust1id1 != t2.cust1id2 and
t1.cust1id1 != t2.cust2id2 and
t1.cust2id1 != t2.cust2id2)
group by
cust1id1
Обновить
Благодарим вас за отличные ответы и комментарии. Я тестировал запросы и сравнивал результаты.
@VladimirBaranov привел редкий случай, который я ранее не рассматривал в комментариях к другим ответам.
Как и в случае 7, это будет бонус, если Case8 обрабатывается, но не ожидается.
Случай 9 важен, и результат для 9a и 9b должен быть обработан.
Обновление 2
Я заметил проблемы с моим оригинальным набором из 7 случаев.
В более поздних учетных записях, когда клиент больше не находится на счете, он всегда оставался вторым заемщиком. Это было совершенно непреднамеренно, вы можете посмотреть на любой из этих примеров, и любой клиент может потенциально быть оставшимся клиентом на самой последней учетной записи.
Кроме того, каждый случай имел минимальное количество учетных записей, чтобы отображать, что именно тестировалось, но это не является обычным явлением. Обычно на каждом шаге каждого случая может быть 5, 10, 15 или более учетных записей, прежде чем клиент переключится на добавление второго клиента, и эти два могут одновременно иметь много учетных записей.
Просмотрев ответы, я вижу, что многие из них имеют индекс, создание, обновление и другие условия, характерные для возможности редактирования базы данных. К сожалению, я нахожусь на стороне потребителя этой базы данных, поэтому у меня есть доступ только для чтения, и программа, которую я могу использовать для взаимодействия с базой данных, автоматически отвергает их.