Я пытаюсь создать отчет, в котором, среди прочего, будет указано, сколько новых пациентов было принято за определенный месяц. «Новый» пациент — это человек, которого либо 1) никогда раньше не видели, либо 2) видели раньше, но последний раз посещали более трех лет назад. В настоящее время я пытаюсь сделать это с помощью курсора, который вызывает функцию с табличным значением, которая сообщает о количестве новых пациентов, наблюдаемых в заданную дату. Курсор вызывает функцию для каждой даты посещения за последние шесть лет, а время выполнения просто ужасно. Ниже перечислена логика запроса курсора, а под ней — определение табличной функции. Я также включаю определение индексированного представления «vwKeptVisits», на которое ссылается функция. Наконец, я привожу несколько примеров результатов запроса. Эти результаты - это то, что я пытаюсь получить с помощью запроса, просто ищу более эффективный способ сделать это... Ищу идеи, как это сделать без курсора.
//КУРСОРНАЯ ЛОГИКА//
DECLARE @BEGINYEAR INT;
SET @BEGINYEAR = YEAR(GETDATE()) - 6;
DECLARE @TBLNewPts TABLE(
VisitDate SMALLDATETIME,
NewPtCount INT
)
DECLARE @VisitDate SMALLDATETIME
DECLARE TblCursor CURSOR
FAST_FORWARD
FOR
SELECT DISTINCT VisitDate
FROM dbo.Visits
WHERE YEAR(VisitDate) > @BEGINYEAR
OPEN TblCursor
FETCH NEXT FROM TblCursor INTO @VisitDate
WHILE @@FETCH_STATUS = 0
BEGIN
INSERT @TBLNewPts
SELECT
@VisitDate,
ISNULL(NewPts, 0)
FROM dbo.fnNewPatientsByVisitDate(@VisitDate)
FETCH NEXT FROM TblCursor INTO @VisitDate
END
CLOSE TblCursor
DEALLOCATE TblCursor;
///////////////////////////////////////////////////////////////////////////////////////////////
CREATE FUNCTION [dbo].[fnNewPatientsByVisitDate]
(
@VisitDate SMALLDATETIME
)
RETURNS
@tbl TABLE
(
NewPts INT
)
WITH SCHEMABINDING
AS
BEGIN
DECLARE @TBLNewPts TABLE(
VisitDate SMALLDATETIME,
PtID INT
)
INSERT @TBLNewPts
--PATIENTS WHO HAVE NEVER BEEN SEEN BEFORE @VISITDATE
SELECT
@VisitDate,
PtID
FROM dbo.vwKeptVisits
WHERE (VisitDate = @VisitDate)
AND
(PtID NOT IN
(SELECT PtID
FROM dbo.vwKeptVisits
WHERE VisitDate < @VisitDate)
)
UNION
--PATIENTS SEEN BEFORE, BUT MORE THAN THREE YEARS BEFORE @VISITDATE
SELECT
@VisitDate,
PtID
FROM dbo.vwKeptVisits
WHERE (VisitDate = @VisitDate)
AND
(PtID NOT IN
(SELECT PREVIOUS.PtID
FROM dbo.vwKeptVisits AS PREVIOUS INNER JOIN
dbo.vwKeptVisits AS CURRNT ON
CURRNT.PtID = PREVIOUS.PtID AND
CURRNT.VisitNumber > PREVIOUS.VisitNumber
WHERE (PREVIOUS.VisitDate > DATEADD(YEAR,-3,@VisitDate))
));
INSERT @tbl
SELECT
COUNT(PtID)
FROM @TBLNewPts ;
RETURN
END
/////////////////////////////////////////////////////////////////////////////////////////
/****** Object: View [dbo].[vwKeptVisits] Script Date: 6/18/2024 8:31:05 PM ******/
CREATE VIEW [dbo].[vwKeptVisits]
WITH SCHEMABINDING
AS
SELECT
COUNT_BIG(*) AS ServiceCount,
V.VisitNumber,
V.PtID,
V.VisitDate,
V.MDID,
V.ApptID,
V.DX1,
V.DX2,
v.DX3,
v.DX4,
V.DX5,
V.POS
FROM DBO.Visits V INNER JOIN
dbo.[Visit Details] VD ON
V.VisitNumber = VD.VisitNumber
WHERE (V.Void = 0) AND
(VD.[CPT CODE] <> 'No Show' AND
VD.[CPT CODE] <> 'MD Cancel' AND
VD.[CPT CODE] <> 'Pt Cancel') AND
(V.ApptID IS NOT NULL)
GROUP BY V.VisitNumber, v.PtID , v.VisitDate, V.MDID, V.ApptID,
V.DX1, V.DX2, v.DX3, v.DX4, V.DX5, V.POS
GO
GRANT SELECT ON [dbo].[vwKeptVisits] TO [db_PracManUserRole] AS [dbo]
GO
SET ARITHABORT ON
SET CONCAT_NULL_YIELDS_NULL ON
SET QUOTED_IDENTIFIER ON
SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
SET NUMERIC_ROUNDABORT OFF
GO
/****** Object: Index [PK_vwKeptVisits] Script Date: 6/18/2024 8:31:05 PM ******/
CREATE UNIQUE CLUSTERED INDEX [PK_vwKeptVisits] ON [dbo].[vwKeptVisits]
(
[VisitNumber] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 95, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [INDICESGROUP]
GO
SET ARITHABORT ON
SET CONCAT_NULL_YIELDS_NULL ON
SET QUOTED_IDENTIFIER ON
SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
SET NUMERIC_ROUNDABORT OFF
GO
/****** Object: Index [IX_vwKeptVisits_MDID] Script Date: 6/18/2024 8:31:05 PM ******/
CREATE NONCLUSTERED INDEX [IX_vwKeptVisits_MDID] ON [dbo].[vwKeptVisits]
(
[MDID] ASC
)
INCLUDE([PtID],[VisitDate]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = ON, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 95, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [INDICESGROUP]
GO
SET ARITHABORT ON
SET CONCAT_NULL_YIELDS_NULL ON
SET QUOTED_IDENTIFIER ON
SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
SET NUMERIC_ROUNDABORT OFF
GO
/****** Object: Index [IX_vwKeptVisits_PtID_VisitDate] Script Date: 6/18/2024 8:31:05 PM ******/
CREATE NONCLUSTERED INDEX [IX_vwKeptVisits_PtID_VisitDate] ON [dbo].[vwKeptVisits]
(
[PtID] ASC,
[VisitDate] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = ON, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 96, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [INDICESGROUP]
GO
////Пример результатов запроса///////
VisitDate NewPtCount
2019-01-02 00:00:00 0
2019-01-03 00:00:00 0
2019-01-04 00:00:00 0
2019-01-07 00:00:00 2
2019-01-08 00:00:00 3
2019-01-09 00:00:00 0
2019-01-10 00:00:00 4
2019-01-11 00:00:00 5
2019-01-14 00:00:00 1
2019-01-15 00:00:00 0
2019-01-16 00:00:00 0
2019-01-17 00:00:00 0
2019-01-18 00:00:00 0
2019-01-21 00:00:00 0
2019-01-22 00:00:00 1
Текущее время запроса составляет более 35 секунд.
Вместо того, чтобы ожидать, что мы проведем реверс-инжиниринг вашего кода, чтобы понять вашу бизнес-логику, включите минимально воспроизводимый пример с примерными (исходными) данными и желаемыми результатами.
^^^ С упором на минимум то, что вы опубликовали, кажется довольно сложным, поэтому вы не можете ожидать, что люди проанализируют это и поймут в этом смысл. И вряд ли это будет необходимо, потому что научиться писать полностью наборы данных для извлечения данных вместо RBAR - это скорее концепция, поэтому, вероятно, если вы создадите простой пример, на который люди смогут ответить, вы сможете масштабировать его до своих целей. фактический код. Во всяком случае, это теория.
Поскольку fnNewPatientsByVisitDate
— это функция с табличным значением, рассматривали ли вы возможность CROSS APPLY
добавить ее в исходный запрос?
Если это задача, чувствительная к производительности, рассмотрите возможность преобразования функции с табличным значением, состоящей из нескольких операторов, во встроенную функцию с табличным значением. то есть: перепишите его как один оператор с результатами на основе набора вместо вставки в промежуточную переменную @table.
Solr довольно хорошо справляется с фасетированием по диапазону дат. Может быть хорошей идеей, если вам нужна скорость и огранка. Также нашел это stackoverflow.com/questions/18347277/…
Разве профсоюз не учитывает ваших новых пациентов дважды?
@ Шонт00. Это не потому, что это союз, а не союз всех. Все это спорно, учитывая, что сам запрос был ошибочным.
Да, я думаю, мой комментарий был верным с точки зрения их двойного поиска и удаления дубликатов, но не того, что они на самом деле дважды вносили вклад в общую сумму.
Мне не понятно, почему значения заносятся в таблицу за шесть полных лет. Все, что вам нужно сделать, это убедиться, что в течение предыдущих трех лет не было посещений на даты, указанные в отчете:
select VisitDate, count(*) as NewPtCnt
from dbo.vwKeptVisits v
where VisitDate between @reportStart and @reportEnd
and not exists (
select 1
from dbo.vwKeptVisits v2
where v2.PatId = v.PatId
and v2.VisitDate between dateadd(year, -3, v.VisitDate) and dateadd(day, -1, v.VisitDate)
)
group by VisitDate;
Вам следует использовать тип date
, а не smalldatetime
. Отрегулируйте концы диапазонов по мере необходимости для сохраняемых значений.
СПАСИБО, ШОНТ00!! Я ценю, что вы нашли время углубиться в то, что я пытался сделать, и предложили такое элегантное, логичное и простое решение. И вы абсолютно правы относительно того, что нужно сделать, чтобы проверить, был ли визит к «новому» пациенту. Моя функция содержала ошибочную логику. Один вопрос: почему для этого рекомендуют дату, а не smalldatetime?
@JohnT В основном потому, что я не думаю, что временная часть актуальна, а также считаю, что smalldatetime
устарело.
Еще раз спасибо. Временная часть действительно не имеет значения. В моих базах данных используется smalldatetime, поскольку я самоучка в этом вопросе, и меня привлек меньший объем байтов.
@JohnT Я понимаю. smalldatetime
еще не устарел. Я ошибся. И я понимаю, что изменение сейчас может быть хлопотным. Отметим, что date
на самом деле использует только три байта, поэтому без компонента времени он более компактен.
Вот способ. Из-за функций в предложенииwhere ваш запрос ухудшается.
Я всегда реорганизую такой шаблон в OUTER APPLY(s), и производительность значительно улучшится. Затем вы можете фильтровать по столбцам из вашего внешнего применения в предложенииwhere.
Спасибо за вклад, MikeG. Я рассмотрю ВНЕШНЕЕ ПРИМЕНЕНИЕ в будущем. В данном конкретном случае мне удалось полностью отказаться от этой функции на основе данных ShawnT00. Время запроса теперь меньше одной секунды!
пожалуйста, также включите образец данных