查看: 1407|回复: 21
|
想请教有关资料库收集(Data Sync)的问题
[复制链接]
|
|
想请有这类经验的朋友们分享一下,并给点意见
最近我在做着一项project:
总公司会有一架资料库主机,储存我system的资料
将会有3间分公司必须把资料传送回来总公司
会采用MS SQL为资料库中心
我有两个计划:
1。 所有分公司的system直接连接总公司的资料库主机
- 会采用Web Base application e.g. VB.NET
- 会采用Lease Line and VPN (Broadband base)
好处:总公司容易监察用者输入资料,会减少资料重复输入的错误
坏处:要有很强的保安。如果communication中断,各分行将不能工作
2。 各分行将有各自的主机
- 会采用application base e.g. VB or VB.Net
- 总公司设定时间进行资料收集
好处:如果communication中断,各分行还可以进行资料输入的工作
坏处:不能够on time检查说输入的资料
疑问:用什么方法来data sync??
我的system是用来进行计算operator的efficiency
目前的跑法是分行是stand alone machince的资料库,我必须要求他们把资料库点又回来给我进行combine来出报告。
面对的问题是,每次每当我combine过后,一定有data duplicate key-in, 因为我们的operator会有branch transfer的case发生。。。user夜常常会输入错误资料。
请问有谁有过这类经验?我采用那里一种方法比较好?
因为没有经验,所以有点无从下手。。。 |
|
|
|
|
|
|
|
发表于 29-10-2005 09:23 AM
|
显示全部楼层
你的 unikey 如果是 branch code + running number 應該不會 duplicate 吧... |
|
|
|
|
|
|
|
发表于 29-10-2005 09:29 AM
|
显示全部楼层
会采用Web Base application e.g. VB.NET
是ASP.net吧
资料重复输入 = 这个可以用source code来解决的。好像同样的id只可以insert一次。如有同样他就会reject你。
第二的我不会。
可能其他的人可以帮你。 |
|
|
|
|
|
|
|
发表于 29-10-2005 12:56 PM
|
显示全部楼层
原帖由 flashang 于 29-10-2005 09:23 AM 发表
你的 unikey 如果是 branch code + running number 應該不會 duplicate 吧...
这是一项和大的工程,branch code + Doc No/Part Code/ 是来之ERP的Multicompany 基本概念。我觉得如果内部的人缺乏这类经验,千万不要尽信你外援的软件开发公司。询问其他的同行或者Freelance的ERP顾问,不然你公司可能会超出预算也无法达到你们的要求。 |
|
|
|
|
|
|
|
发表于 29-10-2005 02:43 PM
|
显示全部楼层
原帖由 johe07 于 28-10-2005 08:40 PM 发表
想请有这类经验的朋友们分享一下,并给点意见
最近我在做着一项project:
总公司会有一架资料库主机,储存我system的资料
将会有3间分公司必须把资料传送回来总公司
会采用MS SQL为资料库中心
我有两 ...
第一个方法当然是最好的, 减少了复杂的资料检查.
但第二个方法还是可以行得通的, 我不知道你的资料有多 critical, 也不知道各分行需不需要对照其它分行的资料, 如果只是拿来做报告, 例如一天的总结报告, 那么方法也许可以简单的多. 我的其中一个经验是每晚定时收集 SAP 的员工的资料, 包括 Lotus Notes 员工的资料回来 SQL Server, 全部输入 temporaly tables 然后进行 syncronize.
诚如你说的, 偶尔会有 duplication 发生, 通常是相关人员输入重复的资料造成的. 为了应付这个, 我在 SQL Server 写了 routine, 只要不能正确 INSERT, 就会发电邮给我, 第二天, 只要我去检查 temporaly table, 就可以知道什么资料是 duplicate 了.
但是除非你的分行全散布在国外... 否则第一个方法还是最好的. 这是我个人的建议. |
|
|
|
|
|
|
|
发表于 31-10-2005 01:01 AM
|
显示全部楼层
虽然我支持第一个方法,但是对于 tmnet boardband 的素质存在怀疑,
主机断线则全部分行都不能使用,而分行断线则该分行不能使用。
可以考虑用 1 + 2 的方法:
全部都 web based
各分行将有各自的主机
总公司设定时间进行资料收集
那么就算在其他地方也可以使用。 |
|
|
|
|
|
|
|
楼主 |
发表于 31-10-2005 01:30 PM
|
显示全部楼层
咖啡豆:
这是一项和大的工程,branch code + Doc No/Part Code/ 是来之ERP的Multicompany 基本概念。我觉得如果内部的人缺乏这类经验,千万不要尽信你外援的软件开发公司。询问其他的同行或者Freelance的ERP顾问,不然你公司可能会超出预算也无法达到你们的要求。
咖啡豆,我这个system和ERP没有关联的,将会完全由我来开发。不过,你说来自ERP的基本概念。。。怎么说呢?
我们公司的ERP我没有发言权(因为我不熟,没有充分理由反驳),一切由我上司做主。不过,还是要谢谢你的忠告。
goatstudio:
第一个方法当然是最好的, 减少了复杂的资料检查.
但第二个方法还是可以行得通的, 我不知道你的资料有多 critical, 也不知道各分行需不需要对照其它分行的资料, 如果只是拿来做报告, 例如一天的总结报告, 那么方法也许可以简单的多. 我的其中一个经验是每晚定时收集 SAP 的员工的资料, 包括 Lotus Notes 员工的资料回来 SQL Server, 全部输入 temporaly tables 然后进行 syncronize.
诚如你说的, 偶尔会有 duplication 发生, 通常是相关人员输入重复的资料造成的. 为了应付这个, 我在 SQL Server 写了 routine, 只要不能正确 INSERT, 就会发电邮给我, 第二天, 只要我去检查 temporaly table, 就可以知道什么资料是 duplicate 了.
但是除非你的分行全散布在国外... 否则第一个方法还是最好的. 这是我个人的建议.
我的资料输入是这样的:
将会输入员工的编号,所作出的成品代号与数量,工作时间(当然有日期)
未免输入错误时间或员工写错时间,所以:-
1. 我将会拿人事部slot-in/out time的资料来做比对
(也就是在user key-in时,就做检查了)
2. 由于员工会被transfer到别分公司帮忙,所以资料有时候要2边输入(早上在公司A,key-in at A, 下午在公司B,key-in at B)。为避免2边的user key-in 重复的资料,所以我才会考虑用centralize database, 而不是seperate在每个分公司的司服机。
我们的分行,2间在同一州(VPN,Broadband),另一间在北马(Lease Line).
flashang:
虽然我支持第一个方法,但是对于 tmnet boardband 的素质存在怀疑,
主机断线则全部分行都不能使用,而分行断线则该分行不能使用。
可以考虑用 1 + 2 的方法:
全部都 web based
各分行将有各自的主机
总公司设定时间进行资料收集
那么就算在其他地方也可以使用。
flashang的这个建议不错,可以加以考虑。谢谢你。
由于web base 我没有做过,所以对我将会是个考验。
[ 本帖最后由 johe07 于 31-10-2005 01:31 PM 编辑 ] |
|
|
|
|
|
|
|
发表于 31-10-2005 06:33 PM
|
显示全部楼层
原帖由 johe07 于 31-10-2005 01:30 PM 发表
我的资料输入是这样的:
将会输入员工的编号,所作出的成品代号与数量,工作时间(当然有日期)
未免输入错误时间或员工写错时间,所以:-
1. 我将会拿人事部slot-in/out time的资料来做比对
(也就是在user key-in时,就做检查了)
2. 由于员工会被transfer到别分公司帮忙,所以资料有时候要2边输入(早上在公司A,key-in at A, 下午在公司B,key-in at B)。为避免2边的user key-in 重复的资料,所以我才会考虑用centralize database, 而不是seperate在每个分公司的司服机。
我们的分行,2间在同一州(VPN,Broadband),另一间在北马(Lease Line).
这样的话... 建议如果资料流量不太大, 网络速度又够快的话... 用 centralize 主机/MS SQL 好了.
但是如果速度不允许, 资料太多, 就用第二个方法. 建立起好几个 MS SQL, 然后在特定的时间收集全部 MS SQL 的资料然后进行分析, 有错误的话才自己去检查. 这些用 MS SQL 已经可以搞定了. 建议你看看 MS SQL 的 DTS 服务, 应该足以满足你的要求. |
|
|
|
|
|
|
|
发表于 31-10-2005 11:04 PM
|
显示全部楼层
用metaframe吧, 只要有56Kbps 就够了, 我是来乱的 :p |
|
|
|
|
|
|
|
楼主 |
发表于 1-11-2005 07:09 PM
|
显示全部楼层
原帖由 goatstudio 于 31-10-2005 06:33 PM 发表
这样的话... 建议如果资料流量不太大, 网络速度又够快的话... 用 centralize 主机/MS SQL 好了.
但是如果速度不允许, 资料太多, 就用第二个方法. 建立起好几个 MS SQL, 然后在特定的时间收集全部 MS SQL 的资料然后进行分析, 有错误的话才自己去检查. 这些用 MS SQL 已经可以搞定了. 建议你看看 MS SQL 的 DTS 服务, 应该足以满足你的要求.
我们每天资料的输入平均大概有200个。
谢谢你的建议,我回去先了解什么是DTS。
原帖由 astral 于 31-10-2005 11:04 PM 发表
用metaframe吧, 只要有56Kbps 就够了, 我是来乱的 :p
那么,我就和我上司去乱乱建议,然后说,是我的“前辈”astral教的。。。:p |
|
|
|
|
|
|
|
楼主 |
发表于 9-11-2005 09:37 AM
|
显示全部楼层
决定采用centralized 资料库。
那么,我想再请问
如果我的分行用broadband/lease line连接回来总部,他们将会login进入AD server, 那么,我的application可以用Map Drive的方法来连接资料库的吗?
分行在个别分布在同一州和北马。
谢谢 |
|
|
|
|
|
|
|
发表于 9-11-2005 10:10 AM
|
显示全部楼层
为什么要用 map drive?
你会有 access right 的问题, 资料库也不能直接索取另一个 server 的资料库的资料.
只要在同一个 network 里, 可以看到对方的 server, 你的 sql server 就可以探测到另一台 sql server, 就可以直接建立一个 sql server instance. |
|
|
|
|
|
|
|
发表于 9-11-2005 10:36 AM
|
显示全部楼层
原帖由 johe07 于 1-11-2005 07:09 PM 发表
那么,我就和我上司去乱乱建议,然后说,是我的“前辈”astral教的。。。:p
其实我也不完全是开玩笑的
用metaframe也是一种折衷的方法.
[sql server] <---> [application server] <--------> multiple thin clients.
其实说穿了,就是terminal services, 和 remote desktop一样,只是它在local printing 和 data transfer上的支援比较强. 而且它的client比较多种,包括dump terminal也有...
坏处就是...和你的第一个方法有同样的问题,还有就是$$$的问题...
好处就是... 只要maintain application server上applications就可以了... 而且它也support application farm (scalable). |
|
|
|
|
|
|
|
楼主 |
发表于 9-11-2005 10:40 AM
|
显示全部楼层
原帖由 goatstudio 于 9-11-2005 10:10 AM 发表
为什么要用 map drive?
你会有 access right 的问题, 资料库也不能直接索取另一个 server 的资料库的资料.
只要在同一个 network 里, 可以看到对方的 server, 你的 sql server 就可以探测到另一台 sql server ...
呵呵,抱歉,我对这样的system 连接法没有经验,因为我们这里跑的aplication都是以map drive来连接资料库的。
在分行,我们是直接连接回来总部的SQL, 在分行那里,将不会有SQL server,sql server instance 能行得通吗? |
|
|
|
|
|
|
|
楼主 |
发表于 9-11-2005 10:54 AM
|
显示全部楼层
|
|
|
|
|
|
|
发表于 9-11-2005 11:11 AM
|
显示全部楼层
|
|
|
|
|
|
|
发表于 9-11-2005 01:38 PM
|
显示全部楼层
原帖由 johe07 于 9-11-2005 10:40 AM 发表
呵呵,抱歉,我对这样的system 连接法没有经验,因为我们这里跑的aplication都是以map drive来连接资料库的。
在分行,我们是直接连接回来总部的SQL, 在分行那里,将不会有SQL server,sql server instance ...
MS SQL 不是 file based, 所以你无法用 map drive 来连接, 你应该用 ODBC/OLE DB 连接, 两种方法都需要你的 MS SQL 的 IP. 这点, 如果你的 apps 是 vb/asp/.net/java, 应该不难办到. |
|
|
|
|
|
|
|
楼主 |
发表于 9-11-2005 03:45 PM
|
显示全部楼层
原帖由 goatstudio 于 9-11-2005 01:38 PM 发表
MS SQL 不是 file based, 所以你无法用 map drive 来连接, 你应该用 ODBC/OLE DB 连接, 两种方法都需要你的 MS SQL 的 IP. 这点, 如果你的 apps 是 vb/asp/.net/java, 应该不难办到.
哦,那我明白您的意思了。。。。
我将会用VB.Net来开发。
谢谢你。 |
|
|
|
|
|
|
|
发表于 10-11-2005 05:11 PM
|
显示全部楼层
astral 所提的metaframe 与 用 MS SQL 那个会 比较好或比较稳 ? 价格相差 ,setup 方面....还有 处理能力 ....如果 资料 都是 上百MB 甚至 到 GB ........有比较过吗 ?
我也碰到一些问题 , 那就是branch 地点 不固定.....有时 新branch要 换了几个地方 才固定下来......那段时间 资料 该如何传送 ??
[ 本帖最后由 enry98 于 10-11-2005 05:24 PM 编辑 ] |
|
|
|
|
|
|
|
发表于 11-11-2005 12:07 AM
|
显示全部楼层
metaframe (现在已经换成presentation server)只是application server
backend还是要需要database server的.
或者应该说,基本架构和一般的情况还是一样的,只是多了presentation server来serve你的client.
把它想像成web server就可以了, 只是它的输出是类似dump terminal. processing 都是集中在server 上。
eg:
<------------------ LAN -------------------------> <------- internet ------>
[database server] <-> [presentation server] < ------------- > [clients]
资料的流量都在database 和 presentation server之间 |
|
|
|
|
|
|
| |
本周最热论坛帖子
|