在R的dbplyr中处理重复ID对应多字段值的分娩类型分组计数问题

我明白你现在的困境：同一个公民ID在同一年有多条服务记录，需要根据code_born和reimburse_code的组合判断分娩类型，还要用dbplyr从SQL数据库里直接处理，而duplicated()这类R本地函数没法直接翻译成SQL。下面我给你一套兼容dbplyr的解决方案，完全在数据库端处理，不用把数据拉到本地。

核心思路：用分组逻辑替代本地函数 #

既然duplicated()没法转成SQL，我们换个思路：先给每条记录标记候选分娩类型，再按「ID+年份」分组，优先用专属报销代码（非2518）确定类型，最后统计每个年份+类型的唯一ID数量。

分步实现代码（兼容dbplyr） #

1. 预处理：提取年份并标记候选类型 #

先把period转换成年份，同时根据code_born标记每条记录的候选类型——这里用substr代替数值计算，确保dbplyr能直接翻译成SQL：

# 加载依赖包
library(dbplyr)
library(dplyr)
library(tidyr) # 用于complete函数补充缺失组合

# 如果你是从SQL数据库取数，用下面的方式连接（替换成你的数据库信息）
# con <- DBI::dbConnect(RSQLite::SQLite(), "your_database.db")
# data <- tbl(con, "your_table_name")

# 预处理步骤
data_processed <- data %>%
  mutate(
    # 从period中提取前4位作为年份，兼容SQL的SUBSTRING函数
    year = as.integer(substr(as.character(period), 1, 4)),
    # 根据code_born标记候选分娩类型
    candidate_type = case_when(
      code_born == '6.1' ~ "Normal",
      code_born == '6.2' ~ "C-section",
      TRUE ~ NA_character_
    )
  )

2. 分组筛选：优先保留专属报销代码的记录 #

同一个ID同一年如果存在非2518的报销代码（这类代码对应特定分娩类型），我们就只保留这些记录；如果所有记录都是2518或NA，就保留全部记录：

data_grouped <- data_processed %>%
  group_by(id, year) %>%
  mutate(
    # 判断当前ID+年份是否有专属报销代码
    has_specific_code = any(reimburse_code != "2518" & !is.na(reimburse_code))
  ) %>%
  # 筛选逻辑：有专属代码就留专属的，没有就全留
  filter(
    ifelse(has_specific_code, reimburse_code != "2518" & !is.na(reimburse_code), TRUE)
  ) %>%
  # 去重：同一个ID+年份+类型只留一条，避免重复计数
  distinct(id, year, candidate_type) %>%
  ungroup()

3. 统计计数：生成最终结果 #

最后按年份和类型统计唯一ID的数量，同时用complete补充缺失的年份-类型组合，确保每个年份都显示两种类型的统计（包括0值）：

final_result <- data_grouped %>%
  # 统计每个年份-类型的唯一ID数量
  count(year, candidate_type, name = "cases") %>%
  # 补充所有可能的年份-类型组合，缺失的cases填0
  complete(year, candidate_type, fill = list(cases = 0)) %>%
  # 重命名列匹配你期望的输出格式
  rename(birth_type = candidate_type) %>%
  # 按年份排序，结果更清晰
  arrange(year, birth_type)

# 如果是SQL tbl，用collect()把结果拉到本地查看
# final_result %>% collect()

本地数据测试结果 #

用你提供的本地数据（先修正period长度不一致的问题），运行后会得到完全匹配你期望的输出：

关键注意事项 #

• dbplyr兼容性：所有用到的函数（substr、case_when、group_by、distinct、count）都能被dbplyr翻译成标准SQL，完全在数据库端处理，适合大数据场景。
• 规则灵活性：如果你的报销代码规则有变化，只需要调整filter里的条件即可，比如增加更多专属代码的判断。

备注：内容来源于stack exchange，提问作者almr27