这种场景下是开发 Excel 扩展还是自建系统呢？

[YuanJiwei]

这种场景下是开发 Excel 扩展还是自建系统呢？

场景：

现在一个小工厂企业主（生产化工材料），目前使用 Excel 存储生产配料以及工序数据。Excel 中包含业务数据和业务算法（基于 Excel) 计算公式实现。现在有一个需求，他希望提供一个查询界面输入某种生产产品，型号，一系列调节参数，然后输出生产该产品的原材料，以及生产机器参数设置， 他目前基于 Excel 已经实现上述功能逻辑。他希望员工也能使用上述功能，但不想让直接把 Excel 给员工，因为这样员工能看到所有的生产业务数据和生产逻辑（有些生产配料配比以机器参数设置是大量实验得出的，希望能保护这些数据和计算逻辑）

1. 方案设计 1 （扩展 Excel 功能）：

开发一款客户端软件（基于 Electron)，读取 excel 文件，实现前端界面，基于客户自定义查询方案，动态渲染输入项，用户填入输出项后, 软件读取并修改 Excel 中的数据（自定义查询方案输入项中包含 Excel 单元格位置），然后利用 powershell 调用操作系统打开 Excel 并保存，这样 Excel 中的公式会重新计算执行。然后软件读取查询 Excel （自定义查询方案输出项中包含单元格查询位置）然后在界面显示查询结果。这个方案是利用 Excel 存储数据并作为算法(Excel 公式)运行环境。这个方案的风险点在于需要用用外界库（如 excel.js) 打开并保存 excel, 并且利用 powershell 打开 Excel 软件并且执行，程序如何判定 Excel 的公式重新计算完成，然后读取重新计算后的结果项。会不会造成数据冲突，或者其他风险，这种方案设计的软件会不会容易出故障。

附注：初步构想的客户自定义查询方案，数据结构示例

{ 
	"input": [ // 输入
			{"输入项 1"， "Table1 ，Sheet1, CellA10"}，
			{"输入项 2"， "Table1 ，Sheet2, CellC1"}，
			{"输入项 3"， "Table2 ，Shee2, CellB10"}
		],
	"output": [ // 输出
			{"输出项 1"， "Table1 ，Sheet1, CellA1"}，
			{"输出项 2"， "Table1 ，Sheet1, CellB1"}，
			{"输出项 3"， "Table2 ，Shee2, CellB3"}
		]
}

2. 方案设计 2

劝导客户把数据和算法分离，利用 Excel 或数据库保存业务数据（数据库表设计），基于编程语言如（ JavaScript) 实现 Excel 中的计算逻辑（编程）。然后进一步实现他的查询需求。

讨论建议

基于上述，对于方案 1 的实现逻辑，大家有什么评价建议吗？ 大家在职业生涯中遇到过类似的需求和设计吗？如果基于该方案开发软件，软件如果给客户报价的话，大概可以报价多少呢？

我个人倾向这种方案 2 ，因为有很好的可扩展型。后续客户想把更多生产流程逻辑纳入这套生产管理系统。但由于客户对编程不同熟悉，对于重新实现 Excel 计算逻辑觉得需要更高成本，所以更倾向方案 1 ，我应该劝导用户吗？如何劝导呢？

或者对于这个场景，大家有什么技术和非技术的实现建议呢？希望大家给我一些建议。什么评论和建议都可以。如果有现成和比较成熟的方案，我可以付费咨询。

谢谢大家了。

[fzls]

不想让用户看到数据，只能把这部分放到服务器上吧-。-

[cyersvet]

你这方案一不还是得把整个 excel 给

[shlroland]

感觉我现在做的项目就完美适配你的需求。我们基于 excel 公式搭建了一套自动化的系统，有比较完善的权限控制。

[NewYear]

如果你是程序员，当然是写单独的程序更好啦。

[renmu]

直接把公式扔给 gpt ，就是一把 Excel 公式翻译成代码公式

[favourstreet]

我感觉 matlab 以及 simulink 那一套很好用，但对楼主的客户可能太难了。
把 excel 当底层的思路是不是不大对，难道不能把

[favourstreet]

……难道不能彻底解耦，把 excel 纯当交互界面，你的客户在 Excel 填好计算逻辑，你另写一个程序去读取计算逻辑，编译生成第三个专门用于计算的程序分发出去？把 excel 当底层计算引擎是不是太奇葩了

[YuanJiwei]

@favourstreet 如果写一个程序把 Excel 的公式提取并计算，技术上是不是难度太大，我没有调研到现成的库可以做。

[YuanJiwei]

@favourstreet 我是倾向把数据和算法解耦的，不过客户有路径依赖吧，希望基于 excel 扩展，并且觉得用编程语言重新实现 excel 中的算法有一定时间成本

[devliu1]

非广告，你可以用 seatable

[favourstreet]

@YuanJiwei 确实是难了点儿，可如果不能摆脱 excel 的话，这样对于 excel 的依赖最少，把公式读取出来之后都可由你自己控制，以后对接 excel 之外其他存储公式的格式，你也会有很多可以复用的东西。

[loading]

非广告，用 Finereport 。

[HitouchiMi]

如果你的企业是打算长期开的话，建议早日建立自己的管理系统，Excel 玩的越花，就是在越给自己挖坑。哪怕是用飞书弄个简易系统也比在 Excel 上雕花要强。

[socoollike]

Power BI

[twofox]

还是劝客户换成方案二吧

你用方案一，我觉得大坑无非就是协同编辑的时候，锁和事务的问题吧。如果是整个文件都锁起来，效率就比较低

如果是因为客户不熟悉编程，觉得自己不可控，那你就给他整一套低代码的系统。教会他怎么用

怎么样来说，后面他想要做什么数据过滤、权限控制，还是得要个数据库存起来这些东西的啊
又何必再用 excel 存储呢

倒是可以做一个导出的功能，导出所有的数据和公式
跟他自己设置的一样

[flmn]

不清楚目前的计算逻辑有多复杂，感觉用编程语言再做一遍应该不难。

最理想的方案就是将基础数据和算法都放在服务器上，操作机用浏览器或者定制的桌面程序，接受输入，调服务器接口计算，进行展现。这样程序架构可能复杂点，但是是最正统的玩法，既保护了数据，有保护了算法，体验也还不错。

次一点的方案就是把数据和算法跟界面一起打包到一个桌面程序，使用类似 Go ，Rust 这样的语言做个桌面端，基本上也能保护数据和算法。但是如果把程序拷走，也存在风险。

所以，还是放服务器最稳妥。

[mightybruce]

不清楚你的编程水平如何，如果不太好，
要么直接 方案设计 1

要么使用 access 数据库， 毕竟用 access 打开 accdb 文件就可以提供清晰的 UI ，也是所有开发成本中最低的。（写点 VBA 宏或 python 再配合 access 多种查询界面和表单足以满足权限和安全要求）

[jones2000]

做一个 excel 插件，c#,js 都可以开发 excel 插件。

[acctv2]

看了一下你的描述，最推荐的就是 Access 。

[acctv2]

如果不熟悉 VBA 的话，也可以考虑 WPF+LiteDB ，因为我看应该性能需求没多高，LiteDB 满足要求了。

WPF 拖个控件，LiteDB 不用写 SQL 直接代码一把梭，熟悉 C#的话几天就开发完了。

[tikazyq]

为啥不用 SharePoint List