blocks|key|4123985|text|我自己也写过这样的系统，如果可能的话，我建议你避免使用它。用户搞砸这样一个系统的方式有很多，特别是当用户是销售团队的时候。一个名为Act！的CRM系统(您可能很熟悉)在过去提供过这样的同步选项，也许他们现在仍然这样做。每当我的公司销售给一直在使用Act！的同步系统的公司时，该公司总是抱怨数据库损坏和不同步。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4123986|如果您真的需要这样做，那么我建议使用数据库级别的复制(在我们编写同步应用程序的时候还不能使用)。许多数据库都提供复制功能，包括MS-SQL+Server。您可以通过跟踪数据库级别的更改，并让数据库负责将这些更改传输到远程数据库，从而消除我们遇到的许多问题。|4123987|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Having written just such a system myself, I'd recommend avoiding it if possible. The ways that users can mess up such a system are legion, particularly when the users are the sales team. A CRM system named Act! (you are probably familiar with) has offered such a sync option in the past, and maybe they still do. Whenever my company is selling to a company that has been using Act!'s sync system, the company always complains of corrupted and mis-synced databases.

If you really need to do such a thing, then I'd recommend database-level replication (which wasn't available at the time we wrote our sync application). Many databases offer replication, including MS-SQL Server. You can eliminate many of the problems we experienced by tracking changes at the database level, and making the database responsible for transporting those changes to a remote database.

blocks|key|897002|text|为什么要重新发明轮子呢？有许多优秀的CRM应用程序都提供了此功能。有些甚至是开源的，所以你可以扩展它们。但是，如果您只需要一个具有离线功能和同步功能的客户端数据库，那么许多CRM应用程序都提供了这一功能。对于客户端数据库，Highrise将是完美的，但我认为没有离线/同步功能。也许可以看看SugarCRM、24SevenOffice或Salesforce|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|897003|构建同步应用程序是困难的，因为有一堆问题需要通过数据合并来解决。如果你仍然需要这样做，那么看看SyncML，这是一个开放的同步标准。Funambol提供了一些可供安装的工具。|897004|entityMap|0|LINK|mutability|MUTABLE|url|http://highrisehq.com/|1|http://sugarcrm.com/|2|http://24sevenoffice.com/|3|http://salesforce.com/|4|http://en.wikipedia.org/wiki/SyncML|5|https://www.forge.funambol.org/download/^0|33|8|0|41|8|1|4A|D|2|4O|A|3|0|1B|6|4|1U|8|5|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]|$A|11|B|12|1|13]|$A|14|B|15|1|16]|$A|17|B|18|1|19]]|C|$]]|$1|D|3|E|5|6|7|1A|8|@]|9|@$A|1B|B|1C|1|1D]|$A|1E|B|1F|1|1G]]|C|$]]|$1|F|3|-4|5|6|7|1H|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]|P|$5|I|J|K|C|$L|Q]]|R|$5|I|J|K|C|$L|S]]|T|$5|I|J|K|C|$L|U]]|V|$5|I|J|K|C|$L|W]]]]

Why reinvent the wheel? There are many good CRM applications available that offers this functionality. Some are even open-source so you can extend them. But if you just need a client database with offline capabilities and sync then many CRM applications offer that. For just the client database <a href="http://highrisehq.com" rel="nofollow noreferrer">Highrise</a> would be perfect but I think there are no offline/sync features. Maybe look at <a href="http://sugarcrm.com" rel="nofollow noreferrer">SugarCRM</a>, <a href="http://24SevenOffice.com" rel="nofollow noreferrer">24SevenOffice</a> or <a href="http://salesforce.com" rel="nofollow noreferrer">Salesforce</a>?

And building a sync application is difficult as there are heaps of issues to resolve with data merging. If you still need to do it then have a look at <a href="http://en.wikipedia.org/wiki/SyncML" rel="nofollow noreferrer">SyncML</a> which is an open standard for syncing. Some ready to install tools are available from <a href="https://www.forge.funambol.org/download/" rel="nofollow noreferrer">Funambol</a>.

blocks|key|891969|text|您可能想看看Microsoft+Synch+Framework。我还没有用过它，所以我不能给出我个人的看法。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|891970|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/sync/default.aspx^0|6|P|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You might want to take a look at the <a href="http://msdn.microsoft.com/en-us/sync/default.aspx" rel="nofollow noreferrer">Microsoft Synch Framework</a>. I haven't used it yet, so I cannot give a personal opinion on it though.

blocks|key|57708|text|MS+CRM+4.0与Outlook配合使用时具有脱机功能：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|57709|http://www.microsoft.com/dynamics/crm/product/overview.mspx|offset|length|57710|离线有它自己的一组奇怪之处(确保你在离开你良好的网络连接之前先离线)，但总的来说，它在这里工作得很好。然而，移动客户端的东西还没有出来。|style|BOLD|57711|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|1N|0|0|X|Z|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@$D|S|E|T|1|U]]|A|$]]|$1|F|3|G|5|6|7|V|8|@$D|W|E|X|H|I]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|C]]]]

MS CRM 4.0 has offline capabilities when coupled with Outlook:

<a href="http://www.microsoft.com/dynamics/crm/product/overview.mspx" rel="nofollow noreferrer">http://www.microsoft.com/dynamics/crm/product/overview.mspx</a>

Going offline has its own set of oddities (make sure you go offline before you leave your good network connection), but on the whole it's working well here. The mobile client stuff still isn't out, though.

blocks|key|4124132|text|首先--如果客户关系管理是你销售的产品，那就直接去做吧--如果是供内部使用的，我会说让其他人忍受解决这些问题的痛苦，买一个客户关系管理吧。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4124133|除了数据库级别的复制，我不认为这足以解决所有问题，你真的需要“滚你自己的”。|4124134|我加入了一个团队，计划一些类似CRM的系统组件，最初他们计划使用数据库复制，因为它看起来很容易-直到你找到了冲突解决方案。|4124135|最后，我们改为使用GUID作为唯一标识符，因为这使得处理由用户创建的新记录变得更加简单-否则，您最终只能为每个客户端系统使用这些笨拙的数字ID分区方案。地狱之路。|4124136|对于在同步之间进行更改的冲突解决方案没有任何帮助，这是一个应用程序级别的问题。数据库可能会从Bob那里获得要重放的事务列表，但如果他编辑了与Alice相同的内容-它应该使用哪个版本？时间戳是不够的，因为如果Alice边走边填写，并有一个较早的时间戳，但Bob等到他吃午饭时才得到较晚的时间戳。|4124137|我真的建议你可以阅读所有关于同步和冲突解决的文章/博客--从10000英尺的高空同步是很简单的，你可以手部挥舞，但当你陷入泥潭时就是另一回事了。|4124138|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

First off - if the CRM is going to be a product you sell, by all measn build it - if it is for internal use I'd say let soemone else endure the pain of solving these questions and just buy a CRM.

Other than database level replication, which I don't think is sufficient for solving everything, you'll really need to 'roll your own'.

I came into a team planning some CRM-like components of a system, and initially they'd planned to use database replication because it looked easy - until you hit the conflict resolution.

In the end we changed to using GUIDs as unique identifiers because it made the handling of new records created by the users much simpler - otherwise you end up with these awkward numeric ID partitioning schemes for each client system. Road to Hell.

Nothing helps with conflict resolution where changes get made between syncs, its an application level concern. The database might get a list of transactions to replay from Bob, but if he edited the same stuff as Alice - which version should it use? timestamps aren't enough because what if Alice fills hers out as she goes and has an early timestamp, but Bob waits till he's having lunch and gets a later timestamp.

I'd really suggest reading all the articles/blog entries you can on synchronisation and conflict resolution - sync is simple from a height of 10,000ft where you can be all hand wavy, but its a different story when you're down in the muck.

blocks|key|4124186|text|这是我在过去推出自己的同步解决方案时的策略。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4124187|4124188|限制系统脱机时可以执行的更改操作的数量。|ordered-list-item|4124189|避免使用自动递增整数作为主键，因为这会导致严重的问题。在过去，我为每个断开连接的客户机分配了一些唯一的ID，并将该ID与自动生成的编号结合使用，以形成一个良好且可读的主键(如XXX-YYYYYYYY)。这很容易做到，因为在非并发environment.|4124190|Keep中，创建一个序列号是微不足道的。事务日志可以“重放”到服务器上。当您的基本同步需求得到满足后，您可以围绕此日志进行优化。|4124191|您必须在客户端应用程序脱机之前决定如何准备它们。典型的解决方案是强制用户按下按钮以触发应用程序进入“脱机模式”。我发现这个解决方案很有问题，特别是当你的用户粗心和健忘的时候。|4124192|首先从最简单的操作开始构建我的解决方案，然后再按照我的方式构建更复杂的方案。(单表单记录操作、多表多记录操作、系列操作即必须充当transaction)|4124193|Make的一个冲突消解场景。请确保您的用户已批准该方案。|4124194|4124195|不用说，这是一段痛苦的旅程。如果你可以将痛苦外包给另一方(比如购买可用的CRM解决方案)，那将是最好的。|4124196|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|X|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|Y|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|Z|8|@]|9|@]|A|$]]|$1|L|3|M|5|E|7|10|8|@]|9|@]|A|$]]|$1|N|3|O|5|E|7|11|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|T|$]]

Here's my strategy in when I rolls my own synch solution in the past.

<ol>
<li>Limiting the number of change operation that can happened when the system is offline. </li>
<li>Avoid using auto increment integer as primary key as this will leads to a nasty problem. In the past, I've assigned every disconnected client with some unique ID, and uses that ID in conjunction to auto generated number to form a nice and readable primary key (Like XXX-YYYYYYYY). This is easy to do because creating a sequential number is trivial in non concurrent environment.</li>
<li>Keep a transaction log, such as every DML operation that you do during offline can be "replayed" to the server. You can optimized around this log later when your basic synchronization needs has been fulfilled.</li>
<li>You have to make a decision on how to prepare your client application before they go offline. A typical solution is forcing your user to push a button to trigger the application to enter "offline mode". I found this solution to be quite problematic, especially when your user is careless and forgetfull. A quick slap in the head from their managers usually suffice on the early stages, but you can opt to implement more intelligen intelligent solution later.</li>
<li>Build my solution from the simplest operation first, and then work my way up to a more complex scenario. (Single table single record operation, multiple tables multiple records operations, series of operation that must acts as a transaction)</li>
<li>Make a conflict resolutions scenario. Be sure the scenario is approved by your users. </li>
</ol>

Needless to say, it's a painful journey. If you can outsource the pain to another party (like purchasing available CRM solutions), that will be the best.

I need to develop a CRM system which will allow users to have a local copy of the DB which can then be synched with the main server system. The idea is that a sales team can travel to non-internet enabled areas and still operate with relatively up to date information and then synch up when they get back to the office.

Ive never done something like this before, can anyone recommend a synch solution?

Synchronisable CRM System

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我需要开发一个CRM系统，这将允许用户有一个数据库的本地副本，然后可以与主服务器系统同步。这个想法是，销售团队可以旅行到不支持互联网的地区，仍然使用相对最新的信息运营，然后当他们回到办公室时同步。我以前从来没有做过这样的事情，有人能推荐一个同步解决方案吗？

问可同步的CRM系统
EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问可同步的CRM系统EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问可同步的CRM系统
EN