Golang Go语言 sqlz - 极简 SQL 拼接库

htzhanglong 1楼•1 天前

直接拼字符串…永远不是好的选择

更多关于Golang Go语言 sqlz - 极简 SQL 拼接库的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html

nodeper 2楼•1 天前

你这种情况用 goqu 似乎更理想： https://github.com/doug-martin/goqu

itying888 3楼•1 天前

虽然看不太懂，但感觉挺好的
再解决一下 where in 场景，以及分表表名拼接，以及动态拼接查询字段的问题可能就更好了

vueper 4楼•1 天前

个人觉得，将 sql 和业务代码混在一起，拼来拼去，挺恶心的~

vueper 5楼•1 天前

sql 和业务耦合太糟糕了

phonegap100 6楼•1 天前

理论上 sql 是持久化层的实现细节，而业务层独立于持久化层，在分层设计良好的情况下，sql 和业务代码不会混在一起

eggper 7楼•1 天前

干的活本质相同，都是 sql 拼接，但是goqu粉饰了一下，假装自己不是 sql 拼接～😄

sinazl 8楼•1 天前

demo 有点让人难受

eggper 9楼•1 天前

我来替楼主说 2 句，这是一个 sql builder ，类似的实现有很多。至于是不是和业务代码混在一起，取决于你怎么使用它。一般会遵从分层设计，在业务层之外设计 repo 层，或者 dao 层，使用该层去操作持久化数据。repo 或者 dao 层的实现，可以用 sql builder 或者 orm 等，不存在和业务的耦合。

caililin 10楼•1 天前

我还是用 sqlbuild 吧

nodeper 11楼•1 天前

沃日，你们不知道有种东西是 plan cache 吗？这种硬拼接的 SQL ，每次数据库优化器都要解析一次，非常影响性能。

caililin 12楼•1 天前

如果真是像你所说的“硬拼接”，首先该想到 sql 注入的问题，而不是性能问题 :)

caililin 13楼•1 天前

点错按钮了。SQL 注入和性能问题不冲突吧？

sinazl 14楼•1 天前

是的，大可放心，我这库没有这样的问题

gougou168 15楼•1 天前

关于Golang中的sqlz——极简SQL拼接库，这里有一些专业的见解供你参考。

sqlz作为一个极简的SQL拼接库，在Go语言项目中确实有其独特优势。首先，它极大地简化了SQL语句的拼接过程，减少了手动拼接字符串可能带来的SQL注入风险。通过库提供的函数和接口，开发者可以更加安全、高效地构建SQL查询。

其次，sqlz的设计哲学强调简洁和易用。它避免了复杂的语法和配置，使得开发者能够快速上手，并专注于业务逻辑的实现。这对于提高开发效率和代码可读性都是非常有帮助的。

然而，值得注意的是，尽管sqlz提供了便利的SQL拼接功能，但在实际项目中，我们仍然需要根据具体需求选择合适的ORM（对象关系映射）框架或SQL拼接库。对于简单的查询和更新操作，sqlz可能是一个不错的选择；但对于更复杂的数据库操作，可能需要考虑功能更为全面的ORM框架，如GORM等。

此外，无论使用何种SQL拼接库或ORM框架，我们都应该始终关注SQL注入等安全问题，确保数据库操作的安全性。

综上所述，sqlz作为一个极简的SQL拼接库，在Go语言项目中具有一定的应用价值。但在选择和使用时，我们需要根据具体需求和安全考虑进行权衡和决策。希望这些信息能对你有所帮助！