z**********8
发帖数: 2049 | 1 我们有个11万以上的contact的数据库，但是pk是用的机器产生的id，而无法用诸如ssn
之类的。问题是，duplication问题，还有contact转换职业，location，或者通讯地址
等，比较难以及时update，辨别。
很多activities,可能是同名但是不同人，同人但是不同公司或者org， 不同id却是同
一个人。 data entry的输入如果出错，就以为是不同人等等。
类似数据库，如何尽量避免这一问题，有啥好建议，谢谢。
市场上有成熟的crm的数据库，比如raiser's edge， IMIS，不知道他们处理类似问题
的思路是怎样的 |
s********e
发帖数: 893 | 2 你说的这种情况要把这一个table分成多个。比如一个是每个record都unique的基本信
息表包括SSN，姓名等。 PK就是SSN。
然后建一个location/address表。同样一个人可以有多个地址。比如From_Date=10/01/
2008 To_Date=07/30/2012是一个地址，From_date=07/31/2012,To_Date is null 是另
一个地址。
如果是地址更新就只增添一个记录在这个表格。每次保证current地址的To_Date is
null。
如果有电话信息，也可以再建立一个专门存电话的table。电话又分固定电话和cell，
那就在表里加一个Type field。
电话也会和地址有关系。通常搬家了电话也换了，所以可以给每个地址加个sequence。
电话和地址通过这个sequence连接起来。
同样也可以建立一个职业表格，包括每个SSN不同时间段的职业title，employer，起
始日期等。 |
s**********o
发帖数: 14359 | 3 不能用SSN做PK，因为你不能保证人给的你就是LEGAL的SSN，
比如有非法移民胡编一个SSN，有不愿意把SSN给人的老美就乱说一个，
通常用SSN+BIRTHDATE做一个MATCH，以防止有重复，但PK还
是另外加的。基本信息用一个TABLE, EMPLOYMENT, ADDRESS,PHONE
都是不同的TABLE，你这个看似是个简单的CONTACT TABLE，但
其实是个复杂的CRM系统，建议你去查CRM系统，看看别人是怎么
设计的，所以数据库并不像你想象的那么简单，很多人是要吃饭的，
比如说性别，男女，但可能出现变性的，男变女，女变男的，如果
是医院的话就要保存这个变化，看似简单的问题，其实也是复杂的，
设计数据库的时候就要考虑到，我设计过一个CRM系统，如果你对
数据怎么使用不是很熟悉的话，会有问题出现。 |
i*******d
发帖数: 81 | 4 要解决duplicate的问题必须解决 name matching 和 address matching。
这两个问题是很核心的问题，看你要求精确到什么程度。
如果就糊弄一下用string match 和regular expression可以做些事情。真要搞的很精
确的话，不是一己之力能搞定的。你如果能搞定，应该可以赚大钱。
你search一下，name matching 有很多 paper。我读了几篇，也没什么简单易行的办法
，因为名字太随意，不容易标准化。
address matching因为容易标准化，倒是比较容易了，有很多商业软件。很成熟了。思
路就是把地址分成标准的parts，然后对各个part进行对比。USPS, Pitney Bowes都卖
这种软件。
ssn
【在 z**********8 的大作中提到】
: 我们有个11万以上的contact的数据库，但是pk是用的机器产生的id，而无法用诸如ssn
: 之类的。问题是，duplication问题，还有contact转换职业，location，或者通讯地址
: 等，比较难以及时update，辨别。
: 很多activities,可能是同名但是不同人，同人但是不同公司或者org， 不同id却是同
: 一个人。 data entry的输入如果出错，就以为是不同人等等。
: 类似数据库，如何尽量避免这一问题，有啥好建议，谢谢。
: 市场上有成熟的crm的数据库，比如raiser's edge， IMIS，不知道他们处理类似问题
: 的思路是怎样的
|
n****f
发帖数: 905 | 5 基本上是二楼 sunnystone 说的。 具体问题要再根据需要适当变通。 |
s**********o
发帖数: 14359 | 6 问题是你11万的CONTACT是干嘛的，以前卖东西的公司有30万个CUSTOMER，
这种就只能是跟ORDER挂起钩来，11万如果是选民，那SSN,BIRTHDATE，地址
职业啥的准确性要求就比较高。地址MATCH有QAS，人名MATCH就比较复杂了，
不但有JAMES TO JIM,还有 JUNIOR SENIOR，一个名字可能一家三代用 |
a9
发帖数: 21638 | 7 contact用ldap搞
ssn
【在 z**********8 的大作中提到】
: 我们有个11万以上的contact的数据库，但是pk是用的机器产生的id，而无法用诸如ssn
: 之类的。问题是，duplication问题，还有contact转换职业，location，或者通讯地址
: 等，比较难以及时update，辨别。
: 很多activities,可能是同名但是不同人，同人但是不同公司或者org， 不同id却是同
: 一个人。 data entry的输入如果出错，就以为是不同人等等。
: 类似数据库，如何尽量避免这一问题，有啥好建议，谢谢。
: 市场上有成熟的crm的数据库，比如raiser's edge， IMIS，不知道他们处理类似问题
: 的思路是怎样的
|
c*******r
发帖数: 3289 | 8 这是BI里面著名的slowly change dimension吧, 找本data warehouse的书看看。 |
