不按rails方式出招之痛 － db schema design

从技术角度讲
在整合系统里，尤其是带有后台账务系统的库表设计里，用rails的表规约去适应是非常麻烦，即使采用了compositekeys也是一样的，很多问题还是解决不了，我曾经在一个电信账务系统的整合项目里用过rails，因为表设计的问题也用了compositekeys，那种系统里有很多你想不到的情况，比如无主键，外键名字不相同等等，总之很别扭，还不如直接上其他语言
楼主不嫌麻烦的话，也可以试试其他的orm，或直接操作sql，只是个思路，我没试过

当然，不从技术角度讲，你也可以说是项目管理出了问题，什么应该持续集成，加强沟通，尽早在设计上避免问题，尽早的发现问题等等。
现实情况是，大多数情况下，你根本解决不了这个问题，除非你老爸是甲方老板，想组织会议？想持续集成？项目经理也许不听你的，也许合作厂商跟本不鸟你，就算是甲方项目经理说了我们库表要统一，那也要看厂商的实力和现场督导的能力，合作厂商就不配合你，你能咬他？说不定他关系比你还硬呢，三天两头搞的你连项目都做不下去。
这种情况下，就不要把自己用技术逼死了，灵活点，不吃亏



我也不知道你为什么没看出来，要不你试试PHP再说吧，你看怎么样

看来项目准备工作做得不够充分，不过很多项目很难准备充分再开工

尽量往SOA架构上去套，也许能让双方改动最小。

  这句很帅

忍不住说一句，这句话说的很帅.
php在处理这类问题确实要比rails要灵活，丫与sql结合的非常好。
但LZ是不是被rails惯坏了，自己在model中写配置呗

我同意,用php做web

这跟用rails 还是php有一点关系吗 ？
无非显示ActiveRecord(orm)的缺点，而直接操作sql则更为灵活

我也在做一个项目使用多种语言开发， 后台是C,JAVA，
web使用php , 客户端软件使用vc6++ ;  还加上一些脚本做一些扩展;
使用都种语言开发没有错误，怎么整合他们的优点才是做重要的；

我的表设计可能没有你那么好，比较乱, php也没有用什么框架；
c,java的使用是因为即时消息，和电话软交换系统必须的；
vc6++ 做用户界面，虽然没有c#,delphi敏捷；但vc6++做MFC界面
还是很专业的； 我现在倒不相信什么敏捷开发；只要功夫深，很复杂的问题
也可以使用比较简单的方式实现；

我也一直在跟踪rail的发展； 不过还是没有在项目中用到;

郁闷，建立模型关系真是犯难

rails的思想就是，“我的就是最简单的，我并不想做一个复杂无比包解决万事的超级平台”，如果在做一个很pure的web应用，从rails出发，ok，没有问题，但是反过来，现在要做个混合结构的系统，以传统的数据库和架构设计方式做，包括做事情的人都是传统的，然后在这之中把一部分分给rails，方向相反，oh, no, this is not the rails way! 估计楼主即使有了composite key解决方案，仍会遇到一些问题。good luck!希望楼主能够继续跟进，并且公布最新进展，这可是难得的一次项目实战。