大数据场景下SQL触发器与接口层if语句的执行速度对比咨询

相同逻辑下，接口层（Python侧实现的判断、转换）的运行速度一定比PostgreSQL触发器更快，核心原因如下：

• 你之前对触发器的机制存在误解：PostgreSQL的触发器是插入动作的同步逻辑，不存在「独立休眠线程、不占用主流程时间」的特性，每插入一条数据，触发器都会在数据库的工作线程上同步执行，还要额外承担SQL解析、数据库上下文切换的开销，本身就比应用层直接做内存运算要慢
• 你提到的完整性规则金字塔，适用场景是多数据源写入同一张表的企业级场景：如果有多个不同业务系统都要往目标表写数据，用数据库做统一校验可以避免各系统重复开发规则，是优先级最高的方案。但你的项目只有爬虫一个写入源，完全不需要考虑多源一致性问题，接口层处理反而更简单高效

你们最终选择在Python层用字典做单位转换的方案，比触发器方案性价比高得多：

• 开发成本更低：你作为新手写、调试Python逻辑的成本远低于写PostgreSQL触发器，后续要修改单位转换规则直接改Python代码即可，不需要调整数据库结构，也不会出现触发器写错导致表锁、数据误改的问题
• 性能提升空间更大：Python侧可以轻松实现多线程/多进程异步流程，比如爬取的原始数据先丢队列，多个消费线程并行做转换，再批量入库，这个性能提升空间远大于在数据库侧做优化
• 字典映射本身比if/switch判断性能更高：Python的字典是哈希表结构，查找时间复杂度为O(1)，不管有多少种单位换算规则，查找耗时都是固定的，比串行的if判断效率高得多

你现在贴的代码里measures字典定义在for tile in tiles循环内部，每次循环都会重新初始化一次，数万次运行下来会产生不必要的开销，把这个字典提到循环外部即可，修改后参考代码如下：

# 单位映射表提到循环外部，全局仅初始化一次
measures={
    "lt":(1,'l'),
    "dl":(10,'l'),
    "cl":(100,'l'),
    "ml":(1000,'l'),
    "kg":(1,'kg'),
    "gr":(1000,'kg'),
    "un":(1,'un')
}

for tile in tiles:
    nameElement = tile.find_element_by_css_selector('.ct-tile--description')
    priceElement = tile.find_element_by_css_selector('.ct-price-formatted')
    # 用find_elements可以避免元素不存在时报错，不需要额外捕获异常
    discountElements = tile.find_elements_by_css_selector('.ct-discount-amount')
    quantityElement = tile.find_element_by_css_selector('.ct-tile--quantity')

    measureKey = quantityElement.text[-2:]
    rawQuantity = float(quantityElement.text.split()[1].replace(',','.'))

    data = {
        "url": nameElement.get_attribute('href'),
        "name": nameElement.text,
        "price": priceElement.text[1:],
        # 网站折扣字段前缀为「Desconto Imediato: 」，转换为小数方便后续分析
        "discount": 0 if len(discountElements)==0 else float(discountElements[0].text[19:-1])/100,
        "measure": measures[measureKey][1],
        "quantity": rawQuantity/measures[measureKey][0]
    }

    print('collected: '+ str(data))

内容的提问来源于stack exchange，提问作者Imeguras