没意义的. 这么大一个平台, 推广, 运营, 审核, 调度, 开发都需要人. 没有个百十来号人搞不定. 而且营销投放也需要钱. 否则谁知道还有你们这么平台? 而且地图接入, 算法, 骑手培训乃至于骑手的衣服跟保温箱都是不小的成本... 更何况商家又凭啥愿意接入你? 骑手凭啥信任你? 那么这么大的投入投进去, 你就靠一单 5% 的抽成, 想啥呢? 一星期不到你的资金就枯竭了. 你又不愿意把抽成提高, 就只能拉投资. 投资人也不是傻的的, 肯定是要看你财报的, 财报没有增长你猜投资人会不会指着你鼻子骂? 而且百十来号人要升职要加薪, 业务不扩张他们哪里来的机会? 前期也许还能表面糊弄过去, 到后面投资人的压力, 员工升职加薪的企望, 都会逼着你必须增加客单价, 提高抽成, 然后变成一个跟饿了么美团没多大差别的企业.

这根本就不是个技术问题. 用 Web 几都没用.

最好是让父母来带孩子. 你跟你老婆出去上班.
至于开店我个人建议你还是慎重.
现在打工是最稳定的收入渠道.
任何形式的创业都可能会把自己创一脑袋包.

都是一样的. 玩主机游戏的瞧不起玩 PC 游戏的, 玩 PC 游戏的瞧不起玩手游的, 玩明日方舟的瞧不起玩原神的.

看到这标题我真是一口可乐喷出来了.
go 的出现本来就是为了规避这些复杂的要死的设计模式.
大道至简.
结果你把依赖注入都搬出来了.
那你为什么不直接用 ASP.NET Core 算了.

@ytll21 当然, 如果系统没有这么强的一致性要求, 用存储过程就纯属是给自己找不自在.

@ytll21 不用存储过程, 用程序处理的话, 终归会有反复与数据库交互的过程. 十次八次的还好, 像某些银行那样的系统, 一笔交易涉及各种跨库跨表查询几十个 (尤其有不少还涉及到本地服务, 如水电气缴费, 地方分行/支行企业合作业务, 自动扣费业务/罚款等), 反复与数据库交互的这个通讯的成本是很高的. 一般来说银行的各种交易必须在几百毫秒之内结束, 而且不可以出现单据不一致的情况. 这与互联网企业的最终一致性要求是不一样的. 银行, 电信系统之类的, 要求的都是实时强一致性. 在这种需求之下, 存储过程是最好的. 至于研发难度, 反正也不是老板需要面对的事情. 有难度你们研发慢慢啃去呗.

@aureole999 银行的账务逻辑比证券复杂多了.

@imnpc 不一定 好多 30 多岁的老开发, 对数据库的理解可能比 DBA 还深刻.

@tanhui2333 这个不是开历史倒车. 是有些场景下只有存储过程合适. 在大并发高一致性高实时性的场景. 比如银行. 你不可能说这边支付完了过了好几秒余额才减掉吧.

看情况. 对于互联网企业来说, 存储过程本身就是没必要的. 互联网企业本身业务非常简单, 几乎无外乎 CURD.
但是对于 SAP, 用友, 久其, 任我行那些 ERP 系统, 以及四通一达的那些 WMS 系统来说, 存储过程就是解决复杂需求的利器. 哦对, 也包括电信运营商与银行. 它们的存储过程更加复杂, 但存储过程对他们来说也往往是必然的选择.


业务逻辑越是复杂, 存储过程的就越是有存在的必要.

哦对, 铁路的 TRS 后面的业务逻辑全都是存储过程.

如果是做项目那无所谓. 如果是做产品, 国内的这些组件一律慎重考虑. 能不用就不用.

@woniu7 有很大意义. 代码写法越优雅, 后期维护难度越小.
那种一层套一层
{
{
{
{
{
{
{

的代码是最难以维护的.

所以为什么说 golang 不适合写业务呢. 不是开玩笑的. 这种表达能力极其羸弱的编程语言, 就很适合写 infr, 比如写消息队列组件, 写个 Redis 替代品, 或者写编译器. 说白了就是适合写各种重算法轻逻辑的程序. 但是如果去写业务逻辑, 尤其是那种极其复杂, 不正交的业务逻辑那就是灾难.

能支持动态任务 / 延迟 / 定时 / 状态回写不?
能保证在一秒十万个任务同时执行的情况下每个任务都能精确到秒么?
能不能提供 C++ / Java / .NET / Python / Golang SDK ?

期待一下, 我们 .NET 开发们苦 Hangfire / QuartZ 那两个屌逼东西好久了 (✧∀✧)

这玩意就跟折腾 Android 刷机一样. 趁年轻折腾吧. 等到了三十多岁你就折腾不动了, 还是找个稳定靠谱的 Windows 养老.

基本上停留在 infer 层面. 做底层, 写运维工具. 而且我们这也是要求不能只会 go. 还得会 C#. 平时 C# CURD, 必要时候用 go 写点 ops 的东西.