B/S错在哪里？

现在正在做一个项目，关于后台管理的系统，框架采用Struts+Hibernate+Spring

原来部门同事都是用PB开发程序，数据库设计出问题了：
1.据说是不用外键关联照样可以做代码表的维护
我们一个UserInfo表中的主键在10多个表里做外键
2.复合主键需要维护
例如：
客户报文标准 pk fk
中心报文标准 pk fk
中心标准代码 pk fk
客户EDI代码  pk
发送标志     pk
这几个字段都有可能被维护
3.本来一个字段就可以做主键，非要再拉一个外键来做复合主键，理由是意义上不完整
例如：
用户代码        pk fk
发送方邮件地址  pk
本来发送方邮件地址就可以做主键了，却要拉个用户代码来做复合主键

在他们看来原来用PB开发不存在这3个问题，因为我选用了ssh框架这些问题出现了
似乎这是矛盾根源

唉，被弄糊涂了，问题是出在选用ssh框架？

业务主键与逻辑主键没有分开。PK是业务主键，一般不用来当罗辑主键

那要改数据库设计的话 就麻烦了吧

我觉得这个问题好处理
在映射方面多想想

用实体之间的关联关系表示外键,hibernate映射时指定这个关系.关系只要做到many to one 就可,不需要做倒one to many,

数据库表结构已经改了10多个了，其中包括字典表

我真服了

能凑或用，就凑或用，完成任务是第一的

恕我直言，原来的数据库设计方式实在差劲，基本是刚毕业的水平，这种做法确实能实现功能，但是是不规范、作坊式的，开发倒是爽了，后期一旦数据一致性出问题，或者出现垃圾数据和持续增长的非必要数据冗余，系统的性能、可维护性就是噩梦，真是无知者无畏！

那就让他们用PB来做web-based的应用好了