想就"管家婆"数据库结构设计的,与大家讨论!

[genfuwan]

想就"管家婆"数据库结构设计的,与大家讨论!
最近从网上下载了管家婆网络版,sql版,装上研究学习.
虽然程序代码看不到.但是sql存贮过程,还有数据库表结构是可以看到的.
我发现一个现象,想与大家讨论一下.

我发现所有表都增加了一个列,做为主键,但是这个列不是自增列,而且普通varchar型列,这个列的值也是递增的,诸如:
000001
000002
000003
这种形式,很明显,这是在管家婆程序中实现的自动编号(而不是数据库表本身的自增列,再说自增列只能用int型实现)
我发现,数据的更新,删除都是以这个列做为标识列的.
举个例子,比如员工表,就有以下几列,
其中序号列就是我上面所说的那个varchar型递增列
序号列,员工编码,员工姓名,性别,部门
000001,aaa,张小人,财务
000002,bbb,王红,劳资

我想问,为何这样设计呢?我理解用员工编码就可以呀,为何再多一个序号列呢?
而且我发现,员工编码也可以改??不解中

[叶子]

这个自定义的00001 00002列，当有数据被删除，可以很清晰的发现。
估计是用于查询的。

员工编号可以更新，如果做为唯一标识，处理起来也比较麻烦，要有唯一约束。

ps：一般的唯一标识是用户不能修改也无法看到的列。

[claro]

帮顶
业务需求决定架构，先了解需求吧。

[tim_spac]

以序列号为标志，每一行都是独立的实体，各个实体的某个属性相同是因为用户登记数据时的信息一致，在用户通过GUI选择某一实体进行赋值时，其数据将更新到具体的某一条记录

[genfuwan]

[Quote=引用 6 楼 wag_enu 的回复:]
............
据我的观察:
1,基本信息表中都有一个类似于 typeid 的列,是用于标识该基本信息的一个关键字(不是数据库表的主键),整个账套中的对于该资料的引用都是用的该关键字,并且它的值是系统自动生成的(程序或存储过程中,不是数据库表自增).该字段的长短随类别级次的不同而不同(比如,你在管家婆的客户端做了一个资料的分类,那么新类别的长度就更长,并且是以父类的typeid 打头).

2,这么做的好处在于,无论你在用户端怎么…
[/Quote]

看来你对管家婆确实有点研究.

[genfuwan]

up

[zghzzy]

顶一下

[genfuwan]

up

[nalnait]

可能是想灵活吧

[liuhaifeng1976]

DING

[youzhj]

学习，并顶之！

[zghzzy]

[Quote=引用 6 楼 wag_enu 的回复:]
1,基本信息表中都有一个类似于 typeid 的列,是用于标识该基本信息的一个关键字(不是数据库表的主键),整个账套中的对于该资料的引用都是用的该关键字,并且它的值是系统自动生成的(程序或存储过程中,不是数据库表自增).该字段的长短随类别级次的不同而不同(比如,你在管家婆的客户端做了一个资料的分类,那么新类别的长度就更长,并且是以父类的typeid 打头).

2,这么做的好处在于,无论你在用户端怎么修改资料(货品,员工,部门,仓库等的编号,名称,地址,电话等的数据 .)它都以 typeid 为关键字更新,就不会对已经存在的引用引起混乱.
[/Quote]

typeid如果是更新的关键字,可是为什么没有主键呢?按道理说都是基于主键更新的呀?

[等待戈多12]

其实这个序号列也可以不用显示出来的。
批发管理软件，有时候需要生成内码等，都是根据序号来的。
如供应商000001的第一个商品就是000001000001，第99个就是000001000099，
这个序号是根据做资料的时候，也即是‘createtime’来生成的。
诸如此类，很多

[wag_enu]

[Quote=引用 18 楼 zghzzy 的回复:]

typeid如果是更新的关键字,可是为什么没有主键呢?按道理说都是基于主键更新的呀?

[/Quote]

管家婆数据库的表基本没有主键,其中,管理档案(货品,职员,仓库,往来单位等)的表中的 typeid,parid,leveal,sonnum,soncount 等字段是在管家婆在程序中管理维护的,不受用户控制.
至于那些字段至底是什么作用,建几个档案,分几个类就知道了.

[emailqjc]

1楼的朋友,不好意思了,借贵地一用:

客户要求灵活的价格体系,要求同一种商品有多个价格类型,同一价格类型在不同地区销售价格也不一样(可能会没变化)
举例:
商品会存在多个地区价格，同一地区又存在多个价格类型，不同价格类型的价格不一样，比如同样是一瓶百事可乐，
在北京的价格如下：
价格A：2.7
价格B：2.8
价格C：2.85
价格E：3.0
。。。。。。。

在拉萨的价格如下：
价格A：2.2
价格B：2.3
价格C：2.4
价格D：2.5
价格E：3.6
价格F：3.7
...


在四川的价格如下：
价格A：3.2
价格B：4.3
价格C：5.4
。。。。。。。

请问你们如何处理这个问题(在数据库设计上，是用列扩展还是行扩展)

我的初步考虑方案:
1、 在商品资料表上增加字段， 用2个字段描述商品的价格
字段A代表价格类型
字段B代表价格类型所对应的值
字段A:A,B,C,D,E,F,G,H
字段B:1,2,3.5,2.23,3.5
2、用一个表来记录各商品的价格,一个价格类型对应一行
商品编码，价格类型 ，价格
00001 A 2.3
00001 B 1.3
00001 C 7.3
00001 D 6.3
............


但是问题来了，在查询商品资料的时候，第一个方案，存在的需要转换分解(从一个字段分解成多个价格字段表示)
第二个方案，造成数据量非常大，查询速度慢
在此听听你们的高见 ！！！！！！！！！！！！！
欢迎和我讨论 QQ 110855663

[sbiaqgpyu]

管家婆的数据表结构,设计的确实相当不错.

[micsolaris]

管家婆当删除商品的时候，其实这个商品还是存在系统数据库里的。特别是管家婆里有个选项叫“编码和名称可以重复”，这样也就是说如果我们这次新增一个相关条目： 编码：11 内容：某产品 。那么如果我们这次删除了，下次还是可以创建同样编码名称的条目。系统里寻找对应的条目根本不是根据我们表面上理解的编码，而是一个管家婆里内定的自己的条码，也就是typeid

[bin394971197]

管家婆某版本全部表名，供大家分析探讨。AccountYearCfg
AreaType
ARight
Assessor
atype
atypecw
AtypecwAll
AuditingLevel
AuditingLimit
backupd
BakDly
BakDlyMen
BakDlyOrder
bakdlyxulie
BankBalanceAdjust
Basic_Ptype_Config
billdaynumber
billmonthnumber
BrandType
Btype
CB_T_BM
CB_T_CB_JSD
CB_T_CBDX
CB_T_CBDX_QCXX
CB_T_CBDX_XX
CB_T_CBXM
CB_T_CLCBSJ_QC
CB_T_FPBZ
CB_T_FPBZ_ZCP
CB_T_FPJG
CB_T_FPJG_FZ
CB_T_FPJG1
CB_T_FPSJ_ZCP
CB_T_FYSJ
CB_T_FYYS
CB_T_LW
CB_T_LW_HYL
CB_T_SYS
CB_T_TRCL
CB_T_WGCL
CB_T_WLDYB
CheckCountDetail
CheckCountNDX
code
ColConfig
Commission
CRight
CW_AutoReportALL
CW_PtypeDateReport
dairy
dairydetail
Department
DifAtype
DiscrepList
DiscrepNdx
DlyA
DlyAConcat
DlyBuy
DlyCw_InterFace
Dlyndx
Dlyndxmen
DlyndxOrder
DlyNdxRetail
DlyOther
DlyRetail
DlySale
Dlystock
DlyWaitAuditing
DRight
dtproperties
Employee
ERight
ERightLog
ETypeARAP
eventawoke
EventLog
facgoods
facsale
factgoods
factgoods00
factgoodsxu
factgoodsxu00
GatheringDly
GoodsStocks
GoodsWar
gridconfig
Group
GroupExclude
GroupLog
HKConfig
IniCommission
IniGoodsStocks
JRight
Jtype
KRight
lendborrow
lendborrow00
MRight
Mtype
operatorder
operatquestions
ORight
pbcatcol
pbcatedt
pbcatfmt
pbcattbl
pbcatvld
PosInfo
price
PRight
ptype
PtypeProdureDly
PtypeProdureNdx
pusercode
RightExclude
RightLog
Rights
SC_T_BOM
SC_T_BOM_DETAIL
SC_T_BOM_FL
SC_T_BOM_PZL
SC_T_CODE_FL
SC_T_CODE_LIST
SC_T_JLDW
SC_T_JLDWFZ
SC_T_LLD
SC_T_LLD_DETAIL
SC_T_RWD
SC_T_TABLE_FIELDS
SC_T_TABLE_FZ
SC_T_TL
SC_T_TL_DETAIL
SC_T_WLJJXX
SC_T_WLXQ
SC_T_YC_DETAIL
SC_T_YCD
SC_T_YLJH
SC_TABLE_FIELDS
ServiceTrack
ShortMessages
SRight
Stock
t_BakSerial
t_CheckCountSerialNo
T_ClassP2
T_CN_BankCheckBill
T_CN_BankDailyAccount
T_CN_CashDailyAccount
T_CN_Checkmanage
T_CN_RPBalance
T_CN_Ticket
t_Custom
T_CW_Abstract
T_CW_ASonCol
T_CW_ASonColNdx
T_CW_Atodini
T_CW_AtypeDateReport
T_CW_AtypePrint
T_CW_AutoReport
T_CW_BakDly
T_CW_BakDlysup
T_CW_BalanceFormula
T_CW_BeginData
T_CW_CommonAtype
T_CW_CustomAtypeItem
T_CW_Dly
T_CW_DlyExport
T_CW_Dlyndx
T_CW_Dlysup
T_CW_FAReportDetail
T_CW_FAReportDly
T_CW_FATypeToReport
T_CW_IntfAtype
T_CW_IntfDly
T_CW_IntfDlyndx
T_CW_IntfDlyndx_ou
T_CW_ISCW
T_CW_JZSYCon
T_CW_LimitAType
T_CW_MoneyStreamDly
T_CW_MoneyStreamType
T_CW_MyAccountBook
T_CW_ReportRelation
T_CW_ReportType
T_CW_SetAtypeList
T_CW_SetAtypeType
T_CW_SubjectContrast
T_CW_TradeSubjectContrast
T_CW_VoucherMerge
T_CW_Waibi
T_CW_WaibiRate
T_CW_zcfzarap
t_DlySerial
t_gbl_ActionList
t_gbl_BaseQueryCol
T_GBL_ColName
T_GBL_CommandFunc
t_gbl_CurrentFunc
t_gbl_DataTypeList
T_GBL_EventLog
t_gbl_FieldTypeList
T_GBL_FunctionList
T_GBL_GridConfig
T_GBL_LoginUser
t_gbl_MessageList
T_GBL_MonthProc
T_GBL_PowerRelation
t_gbl_stringlist
T_GBL_SysCon
t_gbl_sysdata
T_GBL_SysDataCW
T_GBL_UserPower
T_GBL_Vchtype
T_GBL_VoucherType
T_GD_BakDly
T_GD_Dly
T_GD_Dlyndx
T_GD_FixBasic
T_GD_FixChange
T_GD_FixDel
T_GD_FixDepDepart
T_GD_FixDepDetail
T_GD_FixDetail
T_GD_FixSide
T_GD_FixWorkdays
t_GoodsProp
T_GZ_BakDly
T_GZ_BMSalaryToCW
T_GZ_Dly
T_GZ_Dlyndx
T_GZ_IntfShengchan
T_GZ_PersonTaxRate
T_GZ_SalaryDly
T_GZ_SalaryItem
T_GZ_SalaryPiece
T_GZ_SalaryToCW
T_GZ_WorkKinds
T_GZ_WorkOrder
T_GZ_WorkOrderDetail
T_GZ_WorkOrderNdx
t_IniSeriasNo
t_jxc_DayVchtype
t_jxc_DlyFeeAllot
T_Jxc_DTS
t_jxc_feeallotdetail
t_jxc_feeitemtype
t_jxc_GroupDetail
t_jxc_GroupMain
t_jxc_PtypeTotal
t_jxc_SendjsDly
T_Jxc_VchAuditAssessor
T_Jxc_VchAuditLeveal
t_jxc_vchcolumn
t_jxc_vchitemset
t_jxc_vchtitle
T_Jxc_VchWaitAudit
t_jxc_ZCptype
T_NetShop
T_QueryTemplate
T_SC_JHZGDY
t_sc_PtypeMonth
t_SeriasNo
t_SeriasNoAdjust
t_UserPower
TABLE1
Template
Ticket
TradeAtypeCW
UDC
UserToGroup
vchcon
VchRights
VchSelf
Vchtype
VoucherMerge
VoucherType
XRight
Xtype
zcfzarap
zengsong
ZeroGoods
ZeroType

[pal2003]

TypeID
00001
0000100001
是不是为了 一条记录可以方便地找到 他的所有 儿子及下代的所有记录？

[liuyi850203]

个人的理解：序号列是有业务意义的，不能通过程序更改，也不能随便更改，因为这是有业务意义的。一旦随便更改这个有业务意义的序号，会引起数据的混乱。员工编码，这个没有业务意义的标号，也有唯一性，可以更改。

总结：同，都可以保持唯一性。
异，前者有业务意义，不能随便更改，方便查询，保持数据的稳定，不混乱。后者没有业务意义，可以更改

[标准老西儿]

呵呵,学习了,我在设计表结构的时间也常这么做,主要是为了方便,也就是业务意义!