dp3初期讨论

[renyh]

dp3是数字平台第三代图书馆系统，继续坚持开源思想。

dp3初创人员

谢老师顾问，任**初期开发主管，公司开发人员（包括兼职），合作伙伴开发人员和测试人员，编目专家。

协作开发流程

各位开发者Fork dp3，编写代码，提交PR，初期暂时由任**合并。
https://github.com/DigitalPlatform/chord/wiki/Github%e5%8d%8f%e4%bd%9c%e5%bc%80%e5%8f%91

服务器模块

包括数据库底层和系统接口。
服务器模块用.NET Core开发，支持跨平台
数据库选用MongoDB。
MARC存储采用中间格式，同时保存原来的unimarc或usmarc。
服务器模块出来，用一个简单的工具把dp2系统的数据导入导出。
服务器模块是dp3的基础核心模块，优先开发。

希望在五一期间，把程序框架搭起来。
先建一个.NET Core访问MongoDB的实验程序

阅读分析模块

在新服务器模块的基础上，实现读者借阅统计报告。

dp3 开发进程到阅读分析模块出来以后，其实阅读分析的报表不是全部，应该还包含现在内务的报表模块的所有报表。而且这个阅读分析和报表模块应该是能在阿里云服务器上独立自动运行的，到时候就可以省掉人工去创建和上传报表的操作了。

红小老师提出，增加图书类型的借阅排行

[renyh]

新建一个.NET Core命令行程序，引用MongoDB.Bson包不成功。

检测到包降级: System.Reflection.Emit.Lightweight 从 4.3.0 降级到 4.0.1。直接从项目引用包以选择不同版本。 
 ConsoleApp1 -> MongoDB.Bson 2.6.0 -> NETStandard.Library 1.6.1 -> System.Linq.Expressions 4.3.0 -> System.Reflection.Emit.Lightweight (>= 4.3.0) 
 ConsoleApp1 -> MongoDB.Bson 2.6.0 -> System.Reflection.Emit.Lightweight (>= 4.0.1)
程序包还原失败。正在回滚“ConsoleApp1”的程序包更改。

这篇文章说，.NET Core也可以使用MongoDB了，找RaisingStudio.MongoDB.***这种包。
http://www.cnblogs.com/zhongzf/p/5616971.html#3503575
从NuGet上搜了一下，有这几个包，可以安装。

源代码地址 https://github.com/zhongzf/mongo-csharp-driver

---

后来经伙伴推荐，可以使用mongocsharpdriver，.NET Core可以正常引用
http://www.cnblogs.com/solo/archive/2011/09/27/2193345.html

---

经检查 ，用一个全新的.net core项目，仅仅引用MongoDB.Bson包，发现下级lignweight有版本不一致的问题。原来是.NET Core平台下的MongoDB.Bson包有问题，他引用的NETStandard.Library 1.6.1模块引了Lignweight4.3，但MongoDB.Bson包自己引用的Lignweight是4.0.1，两者不一致。

---

经谢老师指导，明白使用MongoDB，只需要引用MongoDB.Driver这一个最上级包就行了，MongoDB.Driver会自动引用依赖的MongoDB.Driver.Core、MongoDB.Bson等，不需要再另外引用MongoDB.Bson等下级包。
.NET Core引用MongoDB.Driver包成功，编译也通过，没有问题了。

[renyh]

创建.NET Core命令行项目或者类库时，会自动加入依赖项/SDK/Microsoft.NETCore.App，里面有很多dll。

.NET Core不像.NET Framework需要单独另外引用程序集。

[renyh]

谢老师留言：

做一些试验项目，比如学习 .NET Core 的用法等等。但 dp3 这个项目，先要花精力进行分析，可以带着参与者一起分析。不要狭隘地理解为开始写代码才是开始

分析期间，要写一系列的 Issue，把数据结构和模块流程基本弄清楚。就是纸上谈兵，不要急着编写程序代码

比如前一段提到的中立书目格式，到底是一个什么样的格式，可以把结构写出来。然后听听编目老师等等的意见。

有了基本的这些准备以后，可以开始写一些非常简单的代码。如果这些代码质量高，最后可以保留到正式产品中，如果质量不高，但能达到摸清情况的目的，也是可以的，后面可以重写这部分代码。

[renyh]

关于架构，谢老师留言：

所以说设计系统，根本上还是面对自己的职业良心，为未来着想，为自己留个余地和退路。很多人觉得只要面对用户就可以，满足用户的口头需求。甚至对用户的态度也是蛮好的。一切看起来都不错

但用户自己是不清楚自己的需求的。就好像一个婴儿哭闹，你问他他说不出哪儿不舒服；小孩子有交流能力了，但他喜欢吃糖，大人也不能完全满足他，要从他的长远利益考虑来安排生活才对。用户就是孩子，你关切他，但不能盲目听他的

所以经常出现用户对自己说过的话反悔的情况。或者看到另一个软件，觉得那个更好，就不顾以前自己的“承诺”了，要你去模仿那个软件。所以我们说需求，是一个上帝视角，第三者神圣视角的需求。永远不可能看清楚这个终极需求，只能想办法拷问出这个需求的冰山一角，逐渐接近这个需求

所以我们会设计一个柔性的系统，对后期的大规模功能变化做好准备。那些本质上适用各种情况的柔性的方案，是我们追求的专业性目标

这样能把技术债务控制在一个可接受的范围。一边成长，一边使用。不会在某天出现突然崩塌

[renyh]

1）ISO2709 -> 中立格式
2）Search API 检索中立格式
3）借书，还书
4）订购记录
5）期记录

[renyh]

关于长期保存的业务数据中立格式 讨论

Jason.Liao(271095962) 17:18:09
@数字平台谢* dp3的架构会考虑从业务去驱动吗？DDD

数字平台谢*(2820725526) 18:34:49
@Jason.Liao DDD 的概念了解过一点，但没有经过系统培训。也许我们的系统里面有一些原始的领域驱动的思想。

数字平台谢*(2820725526) 18:36:19
dp2 系统设计的时候，是比较看重“图书馆业务数据”的。数据是按照方便业务来设计、组织、安排的。比如读者记录是 XML 格式，里面存储了很多状态或者流程信息，而不是把各种信息切碎了放到各种 SQL 表中。这个思想是优先业务的，不是优先数据库的。

数字平台谢*(2820725526) 18:37:30
有了业务和 XML 数据之间的关系模型以后，再想办法去把 XML 剖开对应到 SQL 的概念。但后面这一层是隔离的，不会影响到前者的设计。也就是说后者不影响前者实现即可，后者可以有多种处理方法，不是唯一的方法。

数字平台谢*(2820725526) 18:40:03
图书馆界有一种数据"长期保存"的研究领域。它主要是关注几十年上百年之间，系统不断升级迁移的时候，数据能长期保持稳定，而不会出现数据跟着系统被埋葬的情况。所以这种数据一定是非常豁达和超前的，不受所谓 SQL Server 的局限，基本上是按照图书馆业务术语来书写的数据格式，多半是半结构化的数据。

我们设计系统时候也受到这种影响。所以设计数据结构时候，希望数据结构保持中立。能几十年保持不变。或者虽然变了但很容易映射和迁移。

关于书目中立格式

数字平台谢*(2820725526) 18:40:03
其实 ISO2709 格式保存的书目数据就是个好例子。在各行各业中，图书馆行业的标准化是做得比较好的。

前几天和任**聊到，dp3 我希望设计一种中立格式，给 mongodb 使用。同时也基本上是系统的内部重要格式，比如我们提取书目信息的时候，优先用这种中立格式，就非常方便，可以大大节省开发成本。

对比起来，dp2 系统是直接存储 UNIMARC 和 USMARC 两种具体的 MARC 方言格式的。比如 UNIMARC 200 是题名与责任者字段，而 USMARC 是 245。那么 dp2 前端很多时候拿到两种 MARC，需要用两种处理模块去装配为可以显示的书目摘要格式，感觉很累。

如果把相关 API 中，获取一种好用的数目摘要的格式，也就是说 UNIMARC 和 USMARC 都通用的共同格式，比如 ISBD 格式，这个过程推给 dp2library 来做，那就减轻了前端的负担。这时候其实已经有一种中立格式的萌芽思想了。

dp3 打算进一步发展这个思想。干脆在系统里面给这种中立格式一个合法体面的地位。这样，在 mongodb 数据库存储每一条书目记录的时候，同时存储具体的 MARC 记录原始信息，和转换为中立格式的信息。这个动作是一个原子操作，可以认为两类格式是二位一体的。作为一种基础的设计。

从使用频率来说，可能 99% 情况下会提取中立格式去满足图书馆业务，1% 情况下去提取原始 MARC 格式。

我们考虑一下有些小型的图书馆系统，它们不是很严格要求使用 MARC。所以我们这个设计，可以产生一种副产品用法，就是可以让小型图书馆系统，直接让用户输入中立格式，保存中立格式，完成图书馆业务，中间任何一环都不涉及到原始 MARC 格式。要给这种用法一个名分的话，我们可以认为这个中立格式是兼容 DC 元数据格式的一种格式，这样就具有某种合法性了。

Jason.Liao(271095962) 18:59:53
每个行业都有自己的数据格式，可能就跟EDI一样，我看到marc.iso文件的时候第一感觉这是个flatfie，然后要考虑去怎么解析他，甚至怀念了一把微软的BizTalk。做一个中立格式或者说canonical的document是很有必要的。

书目中立格式设计

数字平台任**(474381593) 7:07:41
谢老师，我想着该怎么开头设计书目中立格式，您上次提到考虑兼容DC

数字平台谢*(2820725526) 14:23:48
**DC 格式有最简单的，就是 XML 元素名用它的元素名。**有一些同类的字段，无法区分细节。比如各种题名都叫 title。稍微复杂一点，就是加入修饰词。其他的手段我还不是太了解。一般来说加上修饰词就比较细致了

我们开发的时候，可以从最简单的开始，逐步根据需要决定采用较为复杂的方式。主要是让这个中立格式能复杂到可以满足图书馆业务即可。也就是说，审视一下 dp2 的所有功能，看看后端和前端拿到书目 MARC 记录以后都做了一些什么变换，生成了什么其他格式的数据？dp3 里面的中立格式能满足这些需求即可

其中使用频率最高的就是书目摘要格式，和各种表格显示的书目信息。基本上用中立格式能生成这两类格式即可。还有就是尝试单独用中立格式进行搜索，看看能否满足现在内务、dp2OPAC 等所有书目检索的需求。

其实中立格式以外还有一种更简单的格式，**就是 dp2kernel 的书目库的 keys 表里面的检索点。**这个是纯粹用来满足检索需求的，不是用来显示和打印的。如果中立格式在实现检索功能的时候，不足以实现现有 dp2 的所有功能，可以考虑再增设一个 keys 格式，这个格式最好是从中立格式转化而来(似乎不应该要求从原始 MARC 转化而来，因为那样复杂度较高)。

我们换一个角度，看看册记录的 XML 格式。基本上 dp3 用现在 dp2 的册记录格式是够用的。dp2 检验过了这个格式。但不是 100% 完美。可以把这个看作册记录的中立格式。倘若有些功能，需要从这个 XML 格式中变换出来一些新的字段满足功能需要，也是可以再给中立格式添加新字段或者新(并行)格式的。

也就是说，有些字段是基本字段，导入数据的时候要确保这些字段存在；另外一些字段是为了方便某些处理而动态根据其他字段组合变换生成的冗余字段。我们说的中立格式，主要包括前一类字段。后一类我们可以取个名字叫做“工作字段”。

用检索来举例：题名里面常有非用字，比如一些书名号，英文的冠词 the 什么的。**中立格式首先应该包括这些符号，不要去做去除加工。**因为首先要保证这些字段拿来给前端显示的需求。去掉容易，还原就不容易了。

但检索时候常常要忽略这些非用字。那怎么办呢？分成两种流派处理。
第一种以传统的关系数据库为代表。SQL 语句中无法嵌入扫描脚本(函数)，只能用通配符描述此类需求，非常难用。比如用 like %中国% 表示希望匹配 “《中国》”这样的字段内容(或者用正则表达式，SQL 中的正则一般不是充分的正则)。然后就逼得人们发明一种办法，就是在 SQL 表字段中放去掉非用字以后的字段内容，这样实现忽略非用字风格的检索

上面提到的 keys 表就是这种方法的代表。进入 keys 表里面的 key 是先去除了非用字的。

第二种流派，是现在的一些 NoSQL，可以在检索式中定制扫描脚本函数，比如对每一个 key 都先用 javascript 语句瞬间去掉非用字以后再和检索词比较。等于虽然数据库中存储的是含有非用字的字符串，但扫描的时候忽略了非用字。当然这种方法每一次比较都会损失一点时间，不如上述 keys 方法快速。有时间和空间之间的交换交易。

概括出这两种流派，那么第二种流派是可能做到不创建 keys 字段和表的，直接用包含非用字的中立格式字段来满足各种检索需求。类似于非用字问题，ISBN ISSN 的加工后再比较(13位和 10 位通检)，也是类似道理。甚至繁简体通检也可以用这种方式做到。但我个人感觉不如 keys 方法简单成熟。

在真正开发以前做出判断，我觉得可以模糊一点，先尝试用一种方法，后期发现不行用第二种方法来在某些场合少量补充。比如基本上用 keys 方法，在万一某个检索点没有 key 的情况下用上述 NoSQL 的脚本方法。

所以现在说不清除了中立格式以外是否还要准备一个 keys 表(若干 keys 字段)。有可能是要的。另外这个方法也可以把 keys 都融入到中立格式中，比如 title 后面跟一个 title_key 字段。

既然说到这里，也还可以有些小动作方法，比如第一次扫描需要的当时触发动态创建这个 key 字段，一次都用不到的就暂时没有。相当于一种 cache 字段了。

上面的描述过程中，我也发现其实书目记录和册记录本质上是类似的，可以统一考虑和处理。

再补充一下。**书目中立格式靠近或者完全采纳 DC 是为了取得标准化的某种合法性。但既然这个格式是中立格式，还是一个机内格式，那么一旦我们发现 DC 给我们带来的麻烦超过自己定义，或者我们暂时理解不透 DC 格式，随时可以转为用自己定义的私有格式。**总之是先把系统做出来再说。反正输入输出格式有 MARC 在，系统并不是不符合标准化要求

但目前我想到的 MARC 和中立格式的捆绑关系，**希望是 MARC -->中立格式的，单向创建关系。**就是说每次前端调出来编辑的还是 MARC 格式，然后发送给服务器保存，服务器动态刷新这一条 MARC 捆绑的中立格式。暂时不处理 中立格式 -->MARC 的任务。这一点要强调一下

为啥用单向创建，不用双向刷新？**主要是考虑开发成本问题。单向基本上够用了。**单向的缺点是，永远只能调出 MARC 进行修改，不允许调出中立格式直接修改中立格式。可以调出中立格式用于实现各种功能，显示，等等，都没有问题。打个比方，就是 dp2 你可以取书目摘要。但你不能要求保存回你修改过的书目摘要

但，OCLC 这个公司他们的系统确实实现过双向同步。这个比较厉害。是上图的纪**老师给我介绍的，他们曾经研究过一段 OCLC 的 Web 编目界面。
OCLC 能在调出 DC 格式数据以后，修改它，保存回去，你再检索 MARC 格式，会发现 MARC 格式中刚才在 DC 里面修改的那些字段也兑现修改了，比如题名。

但我们现在要示弱和守拙么，这个功能不要去较劲。等后期机会成熟了我们单独开一个小课题解决了，然后加入 dp3 即可。

还有一种方式就是我提到过，小型图书馆用特殊方式使用 dp3，就是直接保存中立格式，不曾有过 MARC 格式。那这种情况可以允许前端直接修改中立格式。这时 dp3 退化为一个小型版。这是好事
这时候给 dp3 草草加一个从中立格式到 MARC 的导出模块即可，基本上满足 MARC 的某些要求

[renyh]

关于系统迁移

Jason.Liao(271095962) 18:59:53
有各朋友问如果把他们现在的系统迁移到dp2，需要做哪些准备。迁移的数据包括哪些实体呢？除了做各种数据的映射转换，还需要哪些呢？

我能明显看到的有图书信息，有册信息，有读者信息，用户信息。事务记录信息。
这些信息应该都要迁移过来。

数字平台谢*(2820725526) 19:02:46
dp2 系统核心的数据就是“书目库”。书目库是那个大书目库概念，就是说它下面包含了几个功能库：
数字平台谢*(2820725526) 19:03:19

书目库，也就是那个小书目库，好理解，就是 MARC 格式记录存储的地方，负责书目信息，就是一种图书的“种”的信息存储。小书目库下属的这些数据库，我用实体库举例说明一下。

实体库是保存册信息的。每一条册记录负责保存一个册的信息。如果一种图书有一千册，那就要一千个册记录。册记录里面有个 parent 元素，和书目记录勾连起来了。parent 元素里面是书目记录的 ID。但书目记录不记载它下属册的 ID。也就是说儿子知道自己父亲是谁就行。父亲不知道。要通过检索册记录的 parent 元素才能知道到底有哪些儿子。

为了完整保存这个大书目库的信息，便于迁移，内务提供了“导出到 .bdf 文件”的功能，后面您有空可以看看。这个 .bdf 格式，用 XML 聚集了书目记录和下属册、订购、评注等记录，保存起来，是一个我们的“长期保存”格式。非常便于在系统之间迁移数据

换句话说，就是第三方图书馆系统，只要能把自己系统内的信息，组织起来保存到 .bdf 文件就可以了

.dbf 格式就是有廖工说的 DDD 思路的萌芽。就是说系统不是乱设计的，是有个 master data format 的

数字平台任**(474381593) 19:08:16

有各朋友问如果把他们现在的系统迁移到dp2，需要做哪些准备。迁移的数据包括哪些实体呢？除了做各种数据的映射转换，还需要哪些呢？

@Jason.Liao 其它系统迁移到dp2系统，如果其它系统书目是marc格式，dp2有一些统计方案，可以将marc中的馆藏信息转换成册记录。
也可以将图书信息及册信息、订购信息等，转成dp2的一种中间.bdf（书目转储文件），然后将.bdf转入dp2系统。

Jason.Liao(271095962) 19:09:23
嗯，数目信息和册记录可以这么做了。
接下来是不是导入用户信息，这个有什么指定的格式吗？

数字平台谢*(2820725526) 19:09:56
而读者数据，本身内部格式就是 XML 的。第三方系统输出到符合 dp2 要求的读者 XML 文件格式即可
有些元素是必备的，但大部分是可选的。

数字平台任**(474381593) 19:10:30
读者信息，也可以用excel导入。
工作人员帐户一般数量不多吧，目前好像没有格式转入
@Jason.Liao

Jason.Liao(271095962) 19:10:29
然后还有图书馆的系统日志。这个您以前做迁移的时候会考虑迁移吗？
比如交易日志
借还记录

数字平台谢*(2820725526) 19:11:15
日志这个比较麻烦。dp2 系统有庞大的日志记录格式族。但从进化角度，比较原始，我估计第三方要转换为这个格式，会累死的

这次 dp3 也就是要试图更好解决这个头疼的问题

Jason.Liao(271095962) 19:12:15
其实我觉得他应该要的是他的一些历史数据

Jason.Liao(271095962) 19:11:36
借还记录导入是随书目数据还是随读者记录来导入呢？

数字平台谢*(2820725526) 19:12:16
册记录里面和读者记录里面有互相对照的，在借图书的信息，足够了。但历史借书信息，要从操作日志里面取得

数字平台谢*(2820725526) 19:13:01
@Jason.Liao > 其实我觉得他应该要的是他的一些历史数据
我们可以打个折扣，让借书和还书的历史信息进入 dp2 系统即可。其实其他日志记录不是很重要

Jason.Liao(271095962) 19:13:04
他考虑的时候也会希望能提供阅读分析，相关性分析

数字平台谢*(2820725526) 19:13:12
对，阅读分析很重要

dp3 这次，刚出来模块的时候，肯定无法代替 dp2。但可以首先解决阅读分析问题。这也是我们的一个步骤方面的想法，让新开发的系统尽早发挥作用

dp3 一开始开发，就要有同步功能，从 dp2 日志里面，把几乎全部信息同步过来到 dp3 里面。这样，一个 dp2 系统和一个 dp3 系统，可以形成双机同步状态

然后，dp3 系统可以作为阅读分析系统率先投入使用。因为 dp2 系统的结构，导致做统计分析异常困难。所以我们就转移阵地，让初生的 dp3 来满足这个需求

所以我们设计 dp3 的时候，设计 mongodb 数据格式的时候，很早就要用阅读分析模块来考验它。必须要先满足统计需求

如果数据格式不方便进行统计，就要把它改到可以方便统计为止。

Jason.Liao(271095962) 19:17:12
准备好干粮轻装上路吧，说来这个系统确实蛮大的

数字平台谢*(2820725526) 19:17:26
如果说 2004 年左右我们设计 dp2 的时候，还比较卑微，觉得能满足图书馆借书等业务就很不错了；那么现在 2018 年我们设计系统，首先要满足统计和分析。基本借书功能不在话下

上面提到的基本数据格式，迁移的话题，也很有价值。对其他系统迁移到 dp2 或者 dp2 反过来迁移到其他系统，都是很实际的考量

因为用户很关注数据安全，所以在使用一个系统前，就要了解这个系统内的数据可以迁出。所以我们要给用户一个交代

我们设计系统，一开始就是容易迁出数据的系统。这是个优点

dp3 在设计和开发周期内，肯定是和 dp2 并行推广的，两个系统肯定要并存很长很长时间。我们不但要开发好 dp3，而且要在中间阶段让它尽早和 dp2 互相交融。

[renyh]

用阅读分析模块去验证dp2底层模块

数字平台谢*(2820725526) 19:24:01
记得 2004 年的时候，开始开发 dp2 系统，先是做了 dp2kernel，然后用 dp2BBS 验证了一下它的能力。然后，开始做图书馆业务功能。dp2Circulation 这个名字，就是因为当时一开始就做了流通(circulation)功能，当时还没有编目功能。

然后 dp2OPAC 也做得较早。所以 dp2 系统可以认为是面向流通和公共查询的。能看得出当时比较担忧这两个模块的实际效果，所以把它们排在了前面。

现在开始做 dp3 系统，我们是比较忧虑阅读分析模块，心里不是太有底，所以把报表模块放在最开始开发。这样也好，毕竟有个重点，避免目标太大而失去具体目标。

[renyh]

关于dp3全文检索使用lucene的一些讨论

Jason.Liao(271095962) 16:45:56
SQL在全文检索或者内容匹配的时候性能咋样？

数字平台谢*(2820725526) 16:52:00
@Jason.Liao > SQL在全文检索或者内容匹配的时候性能咋样？
MS SQL Server 可以选择给表创建全文检索的索引。不过没有尝试过。并且由于 dp2kernel 要配合四种数据库，这种 MS SQL Server 独有的方法可能就走不通了。实际上 dp2kernel 没有开发完，还欠一些东西

Jason.Liao(271095962) 16:52:12
以前给微软做过一个项目，数据量在百万级，用户要求增加一个功能是模糊搜索，当时用ef6做了各种优化，始终不满意。后来用了微软的Azure Search, 直接支持模糊查询，我们所做的就是定期的把DB里面的增量数据同步到AzureSearch Index里面去。要是我们也用相似的原理估计效率会很高

数字平台谢*(2820725526) 16:52:42
dp2kernel 现在支持中间一致的检索，实际上就是 SQL Server 的 like %xxxx% 算法。这个要全表扫描，当然是很慢的。

Jason.Liao(271095962) 16:53:26
是的，而且我估计你这个字段不是定常，也没办法做索引

数字平台谢*(2820725526) 16:53:28
@Jason.Liao > 后来用了微软的Azure Search
这是要用它的云服务器吧？

Jason.Liao(271095962) 16:53:42
当时客户是微软。
有没有可能自己实现一个

数字平台谢*(2820725526) 16:54:40
实际上按照计划，我们会给 dp2kernel 里面添加 lucene，或者具体说是 lucene.NET。然后 dp2kernel 自动维护好

Jason.Liao(271095962) 16:55:21
lucene的语法很好

数字平台谢*(2820725526) 16:55:52
dp2kernel 对外呈现，就是好像它自己支持全文检索一般。这样, dp2kernel 的全文部分索引是要定期自动维护的，可能比 SQL 里面略微滞后一点，但由于不是用来做借书还书这样的事务操作，所以一般没有问题

Jason.Liao(271095962) 16:56:07
Azure Search就是Lucene Query

数字平台谢*(2820725526) 16:56:22
如果现在说 dp3，dp3 是 .NET Core 了，可能更好安排一些

数字平台谢*(2820725526) 16:57:01
其实早年我写中图法第四版的时候，那个时候数据库就是 dp1 的雏形，它是支持全文检索的。我自己实现的倒排索引。

Jason.Liao(271095962) 16:57:03
在opac查询里面估计会很爽

数字平台谢*(2820725526) 16:57:23
@Jason.Liao 是的。用户是很喜欢的。

数字平台谢*(2820725526) 17:00:10
我们在图书馆系统中，可以基本这样认为：事务性的东西还是丢给 SQL Server 稳妥一点。其他的可以大胆尝试用全文索引实现。这样就突然打开了一个窗口

[renyh]

关于MongoDB的安装

数字平台谢*
这里发一些感慨：类似 mongodb 这种，草草做一个安装就算了，连注册 Windows Service 都没有搞。如果安装者不是开发人员，根本是驾驭不了的。其实原来我设想的，dp2library 模块的系统管理员就是这种水平，丹诚时候就是这种水平，现在高校图书馆也还能达到。但现在的公共图书馆，企业图书馆系统管理员一塌糊涂，根本达不到这个水平，所以我们开发者必须求变，必须在这种恶劣的条件下生存下来。

对比一下，MySQL 的安装程序通俗水平就很高，也很美观。这才是一个商业软件公司的样子(虽然不太算商业软件)

所以后面我们大规模推广 mongodb 的话，弄不好还要我们自己动手写一个完整的 mongodb 安装程序。

苏州方* 2018/5/4 18:10:56
如果考虑兼容Linux系统，你们可以做成docker镜像，未来客户安装会非常便捷

数字平台谢* 2018/5/4 18:11:45
@苏州方伟东 嗯，我们也有这种想法

任*
是的，我前两天也研究一下docker，还没搞懂，我如果时间不够的话，请专人研究。