提醒一下帖主，这里的主流似乎是认为国家级项目的技术含量相对更低。因为没有市场检验.....

这个公司的 CTO 叫做周昌印, 毕业于哥伦比亚大学的计算机视觉专业博士，主要的研究领域似乎是视频和图像处理。后来在 Google X 工作过一段时间，看简历技术背景非常强，但是主要从事的是研究性的工作。另外一个合伙人叫做卢毅女士。
这个公司没有官网，看不出来盈利模式会是什么，也找不到到底有哪些现有的或者潜在的客户。从上面的帖子给出的薪资来看，在互联网行业也不算高，看上去更接近与传统行业的工资水平。
我个人的建议是可以先了解一下背景，从技术上来看这家公司从事的领域专业性很强，这同时也表示技术难度也比较高。可以理解 CTO 对于技术人员的期望很高。

深圳地铁远没有广州，北京，上海挤。

其实，从项目走向产品化一点也不神秘。一开始所有的软件都是从项目产生的。
所谓高度定制化的软件产品其实就是项目。
面向特定行业的软件其实都是从项目演化来的。
我认为，软件的功能其实就是一整套对于具体业务支持的代码实现，目前看来包括用户界面+业务逻辑+数据存储。
软件项目和软件产品的区别，其实在于对于不同业务的支持能力。
所以你会看到，大多数的软件产品其实会专注比较简单而重要的功能，而软件项目则会让开发者感觉自己对于功能实现没有支配权。但是最终的目标，其实都是要支持相应的业务运作。为此，行业软件现在有 2 个发展方向：
1. 实现尽可能多的功能，以使得自己的软件能满足尽可能多的用户需求，这里需要指出的是，行业软件的需求其实来之不易。
2. 只实现经过筛选的主要功能，在提供给不同的用户使用时，进行针对性的定制化开发。
思路其实就是:
1. 找出哪些功能应该是核心（其实就是很多项目都要反复使用的功能），用大量的精力管理这些功能，每次修改这些功能的时候，都异常谨慎，同时对这些功能保持完整的文档追踪。
2. 为了项目实现新功能的时候，就把新功能视为扩展，只有在发现这些新功能用到很多个项目上才考虑整合到核心功能中。
从实现技术上来看，其实今天大家在讨论的所谓先进技术，在楼主所处的行业很难用得上。倒是可以考虑引入一些可以加快开发和部署速度的方法，以降低工作量，有更多的时间来考虑产品转化。
不要怕修改数据库，与修改代码的代价比，修改数据库根本不算事。所以我一直不推荐搞所谓的预留字段，对于 Oracle 这样的公司搞的那种预留 Property1~propertyN 这样的作法，我一直嗤之以鼻，因为这并不能避免变更，纯粹增加了后期维护的难度。

阿联酋....厉害了！土豪国家啊

我希望可以实现真正的智能。
其实，我们现在还没弄明白到底什么才能叫做"真正的智能"。
但是我觉得机器学习完全可以代替人类的推理过程，其主要优点就是思考速度和记忆能力与人类比较都不是一个数量级的。

原则上我同意 @wu67 在 31 楼的观点。单纯的显示，例如从某个名字换成另外一个，这种事情应该由前端实现。但是如果需要计算平均值，求和，甚至搞不好还要搞机器学习，这种东西应该后端来干。
所以 1 应该前端干（当然，假如你的翻译还需要用到另外一个后端数据库甚至 NLP，那就是另外一个故事了）。2 和 3 都应该由后端来干。
我不太了解这是不是属于架构层面的事情......

人类一开始，从来就不是为了有用而学习的。
哪怕只是为了了解自己对所学是不是有兴趣，都是值得一学的。

可以讲系统设计,也可以讲走的弯路，以及你是怎么解决问题的。
这其实不是暴露缺点，而是展示自己分析和解决问题的思路。
没人是完美无缺的。

假设最极端的情况：你的功能有 100 个，但是每个功能都可能用到 100 个医院的不同特性，这个时候实际上就是 10000 个功能。
这种规模的系统肯定是没法管理代码的。
于是折中的方法就是提取出有共性的 80 个功能，这些功能针对 100 个医院使用同样的代码。而剩下的还是有 2000 个....
但是功能的总数量下降到 2080 个，这是一个极大的进步了。
再继续用上面的方法。使得功能下降到可以接受进行版本管理的程度，然后加入开关。但是如果你这套系统最终有 200 个开关，实际上也是一场噩梦。
其实这套办法完全取决于你的系统有多少个功能.......我感觉开源软件其实就是这么干的。开源项目最大的优点是有几乎无限的开发资源...所以最后什么功能需要接受就成了一个最重要的事情。
我也是搞类似的系统的，目前确实没啥好办法。

@xiaomayi2012 前面的意思确实是需要用外键的，只是不在数据库里明确地定义 FK，只是在程序里或者 SQL 脚本里用外键，实际的程序步骤和 @zdnyp 提到的是完全一样的，其实你完全可以提前把整个 categoty 表都读到内存 /缓存里，然后用程序来判定该不该写入 2 个表。

你们说的不用外键，但是在 info 表里面还是插入 category_id 吗?如果是，那是不是还是按照二楼的做法来，只是显式的外键定义应该取消？

存储过程主要的问题不是难写，而是难以理解和维护。
如果假设一个软件是由一个头脑清醒的人一直编写和维护，在整个软件的生命周期内理论上存储过程其实更简单。
如果所有的软件都是基于定制开发的，存储过程其实不算是个坏的方案。但是现在大家不是都要搞产品化吗？
正如前面网友的距离，换个数据库，所有的存储过程基本都要重写一遍。并且更严重的问题是重写之后你要搞单元测试还很费劲。

首先，我要举报，楼主是个男生。
其次，我觉得你的办法比较好，虽然我不懂 redis......为了这种事在数据库里建表，实际上就是我过去 10 年的干法。这不是什么好事，关键是很难把文档维持到跟代码甚至跟表保持一致......

这个建议是要多次查询这个表，不建议完全用 SQL.

还需要知道你用的是什么样的语言。

这东西应该一行行分析，直到你用简单的逻辑无法分析再考虑正则。
问问题的正确方式应该是:我这个输入是...（你写出来了）
我想要的结果是:(这个你没写)
然后再说你尝试过什么方法。
最后说你想要得到一个什么样的解决办法