大型ERP数据库系统常见的几种设计有什么(ERP系统设计)

采用自增长主要是性能

早期的数据库系统，经常采用某种编号，比如身份z号码，公司编号等等作为数据库表的

然而，很快，大家就发现其中的不利之处

比如早期的医院管理系统，用身份z号码作为病人表的

然而，第一，不是每个人都有身份z；第二，对于国外来的病人，不同国家的病人的证件号码并不见得没有重复

因此，用身份z号码作为病人表的是一个非常糟糕的设计

考虑到没有医生或者护士会刻意去记这些号码，使用自增长是更好的设计

公司编号采用某种特定的编码方法，这也是早期的数据库系统常见的做法

它的缺点也显而易见：很容易出现像千年虫的软件问题，因为当初设计数据库表的时候设计的位数太短，导致系统使用几年后不能满足要求，只有修改程序才能继续使用

问题在于，任何人设计系统的时候，在预计某某编号多少位可以够用的时候，都存在预计不准的风险

而采用自增长则不存在这种问题

同样的道理，没有人可以去记这些号码

使用自增长另外一个原因是性能问题

略有编程常识的人都知道，数字大小比较比字符串大小比较要快得多

使用自增长可以大大地提高数据查找速度

2

避免用复合主键(compound)这主要还是因为性能问题

数据检索是要用到大量的值比较，只比较一个字段比比较多个字段快很多

使用单个从编程的角度也很有好处，sql语句中where条件可以写更少的代码，这意味着出错的机会大大减少

3

双主键双主键是指数据库表有两个字段，这两个字段独立成为主键，但又同时存在

数据库系统的双主键最早用在用户管理模块

最早的来源可能是参照 *** 作系统的用户管理模块

*** 作系统的用户管理有两个独立的主键： *** 作系统自己自动生成的随机ID(Linux,windows的SID),loginid

这两个ID都必须是唯一的，不同的是，删除用户test然后增加一个用户test,SID不同，loginid相同

采用双主键主要目的是为了防止删除后增加同样的loginid造成的混乱

比如销售经理hellen本机共享文件给总经理peter,一年后总经理离开公司，进来一个普通员工peter，两个peter用同样的loginid,如果只用loginid作 *** 作系统的用户管理主键，则存在漏洞：普通员工peter可以访问原来只有总经理才能看的文件

*** 作系统自己自动生成的随机ID一般情况下面用户是看不到的

双主键现在已经广泛用在各种数据库系统中，不限于用户管理系统

4

以固定的数据库、表应付变化的客户需求这主要基于以下几个因素的考虑：4

1大型EPR系统的正常使用、维护需要软件厂商及其众多的合作伙伴共同给客户提供技术服务，包括大量的二次开发

如果用户在软件正常使用过程中需要增加新的表或者数据库，将给软件厂商及其众多的合作伙伴带来难题

4

2软件升级的需要

没有一个软件能够让客户使用几十上百年不用升级的

软件升级往往涉及数据库表结构的改变

软件厂商会做额外的程序将早期版本软件的数据库数据升级到新的版本，但是对于用户使用过程中生成的表进行处理就比较为难

4

3软件开发的需要

使用固定的数据库库表从开发、二次开发来说，更加容易

对于用户使用过程中生成的表，每次查找数据时都要先查表名，再找数据，比较麻烦

举例来说，早期的用友财务软件用Aess作数据库，每年建立一个新的数据库

很快，用户和用友公司都发现，跨年度数据分析很难做

因此这是一个不好的设计

在ERP中，很少有不同的年度数据单独分开

一般来说，所有年份的数据都在同一个表中

对于跨国公司甚至整个集团公司都用同一个ERP系统的时候，所有公司的数据都在一起

这样的好处是数据分析比较容易做

现在大多数数据库系统都能做到在常数时间内返回一定量的数据

比如，Oracle数据库中，根据在100万条数据中取10条数据，与在1亿条数据中取10条数据，时间相差并不多

5

避免一次取数据库大量数据，取大量数据一定要用分页

这基本上是现在很多数据库系统设计的基本守则

ERP系统中超过100万条数据的表很多，对于很多表中的任何一个，一次取所有的会导致数据库服务器长时间处于停滞状态，并且影响其它在线用户的系统响应速度

一般来说，日常 *** 作，在分页显示的情况下面，每次取得数据在1-100之间，系统响应速度足够快，客户端基本没有特别长的停顿

这是比较理想的设计

这也是大型数据库系统往往用ODBC,ADO等等通用的数据库联接组件而不用特定的速度较快的专用数据库联接组件的原因

因为系统瓶颈在于数据库(Database)方面(数据量大)，而不在于客户端(客户端每次只取少量数据)

在B/S数据库系统中，分页非常普遍

早期的数据库系统经常有客户端程序中一次性取大量数据做缓冲

现在已经不是特别需要了，主要原因有：5

1数据库本身的缓冲技术大大提高

大部分数据库都会自动将常用的数据自动放在内存中缓冲，以提高性能

5

2数据库联接组件的缓冲技术也在提高

包括ADO在内的一些数据库联接组件都会自动对数据结果集(resultset)进行缓冲，并且效果不错

比较新颖的数据库联接组件，比如Hibernate也加入了一些数据结果集缓冲功能

当然，也有一些数据库联接组件没有对数据结果集进行缓冲，比如JDBCDriver，不过几年之内情况应该有所改观

也有些不太成功的数据缓冲，比如EJB中的实体Bean，性能就不尽如人意，实体Bean数据也是放在内存中，可能是因为占用内存过多的缘故

相对来说，今天的程序员写客户端数据缓冲，能够超过以上两个缓冲效果的，已经比较难了

什么是好的数据库设计？

一些原则可为数据库设计过程提供指导。第一个原则是，重复信息（也称为冗余数据）很糟糕，因为重复信息会浪费空间，并会增加出错和不一致的可能性。第二个原则是，信息的正确性和完整性非常重要。如果数据库中包含不正确的信息，任何从数据库中提取信息的报表也将包含不正确的信息。因此，基于这些报表所做的任何决策都将提供错误信息。

所以，良好的数据库设计应该是这样的：

将信息划分到基于主题的表中，以减少冗余数据。

向Access提供根据需要联接表中信息时所需的信息。

可帮助支持和确保信息的准确性和完整性。

可满足数据处理和报表需求。

设计过程

设计过程包括以下步骤：

确定数据库的用途：这可帮助进行其他步骤的准备工作。

查找和组织所需的信息：收集可能希望在数据库中记录的各种信息，如产品名称和订单号。

划分到表中的信息：将信息项划分到主要的实体或主题中，如“产品”或“订单”。每个主题即构成一个表。

关闭信息项目导入的列确定希望在每个表中存储哪些信息。每个项将成为一个字段，并作为列显示在表中。例如，“雇员”表中可能包含“姓氏”和“聘用日期”等字段。

指定为主键：选择每个表的主键。主键是一个用于唯一标识每个行的列。例如，主键可以为“产品ID”或“订单ID”。

设置表关系：查看每个表，并确定各个表中的数据如何彼此关联。根据需要，将字段添加到表中或创建新表，以便清楚地表达这些关系。

优化您的设计：分析设计中是否存在错误。创建表并添加几条示例数据记录。确定是否可以从表中获得期望的结果。根据需要对设计进行调整。

应用规范化规则：应用数据规范化规则，以确定表的结构是否正确。根据需要对表进行调整。

我于2014年开启即时通讯的开发之路，历经从服务端到客户端，从第三方到自研，经历过诸多的研发难题，都一一破解。现将经验总结如下，希望对行业内从事IM开发的程序员有所帮助。

①P2P方式

P2P方式多用于局域网内聊天，这种方式在有种种限制和不便。一方面它只适合在线的点对点消息传输，对离线，群组等支持不够。另一方面由于 NAT 的存在，使得不同局域网内机器互联难度大大上升，在某些网络类型(对称NAT)下无法建立连接。使用P2P方式的软件在启动后一般做两件事情：

1、进行UDP广播:发送自己信息和接受同局域网内其他端信息。

2、开启TCP监听:等待其他端进行连接。

②服务器中转方式

大部分的互联网IM产品都采用服务器中转这种方式进行消息传输，相对于P2P的方式，具有有以下的优点:

1、支持更多P2P无法支持或支持不好的业务，如离线消息，群组，聊天室。

2、方便业务逻辑的拓展和新旧版本的兼容，当然它也有自己的问题，就是服务器架构复杂，并发要求高。

通过以上的比较，建议我们在开发IM系统的时候使用服务器中转的方式。

IM的网络连接方式有基于TCP的长连接和基于>

以上就是关于大型ERP数据库系统常见的几种设计有什么(ERP系统设计)全部的内容，包括:大型ERP数据库系统常见的几种设计有什么(ERP系统设计)、网站的数据库如何设计、即时通讯IM系统开发等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！