我有表Year

A = ...........
B = ..........

 A字段表示国历生日
B字段表示农历生日

我有表people:

name =.........
year = models.ForeignKey(Year)
group = .........

在程序中  他选择输入国历生日或者农历生日
  程序自动计算相对应的日期

我在显示时需要这样显示:

1999年生:
      张某某    李某   赵某
2000年生:
       钱某某   朱某某  甄某

麻烦的是  页面是以group来分别显示各组的人员的
我现在使用的是:
year_list = Year.objects.all()

也就是说  大体会出现这样的情况
组A:

1999年生:

2000年生:

2001年生:
     刘某某   代某某

2002年生:
      郑某  夏某

组B:

1999年生:
      张某某    李某   赵某
2000年生:
       钱某某   朱某某  甄某

2001年生:

2002年生:

这样的情况
我只想让该组出现该组存在人员已有的年份
但对结果集优化又会出现年份重复  不像现在这样分明
还有些办法也太笨了点  效率低(例如循环分类)

大牛有没有稍微好点的办法?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20060708/9e841c55/attachment.html

为什么需要单独的year表？除了年份还有什么信息？
一般来说，year直接作为people表的字段，然后查找people表时对这个字段做group操作就好了。
需要所有年份的时候也只要distinct一下就可以了。

On 7/8/06, 风向标 <vaneoooo at gmail.com> wrote:
>
>
> 我有表Year
>
> A = ...........
> B = ..........
>
>  A字段表示国历生日
> B字段表示农历生日
>
> 我有表people:
>
> name =.........
> year = models.ForeignKey(Year)
> group = .........
>
> 在程序中  他选择输入国历生日或者农历生日
>   程序自动计算相对应的日期
>
> 我在显示时需要这样显示:
>
> 1999年生:
>       张某某    李某   赵某
> 2000年生:
>        钱某某   朱某某  甄某
>
> 麻烦的是  页面是以group来分别显示各组的人员的
> 我现在使用的是:
> year_list = Year.objects.all()
>
> 也就是说  大体会出现这样的情况
> 组A:
>
> 1999年生:
>
> 2000年生:
>
> 2001年生:
>      刘某某   代某某
>
> 2002年生:
>       郑某  夏某
>
> 组B:
>
> 1999年生:
>       张某某    李某   赵某
> 2000年生:
>        钱某某   朱某某  甄某
>
> 2001年生:
>
> 2002年生:
>
> 这样的情况
> 我只想让该组出现该组存在人员已有的年份
> 但对结果集优化又会出现年份重复  不像现在这样分明
> 还有些办法也太笨了点  效率低(例如循环分类)
>
> 大牛有没有稍微好点的办法?
>
> _______________________________________________
> python-chinese
> Post: send python-chinese at lists.python.cn
> Subscribe: send subscribe to python-chinese-request at lists.python.cn
> Unsubscribe: send unsubscribe to  python-chinese-request at lists.python.cn
> Detail Info: http://python.cn/mailman/listinfo/python-chinese
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20060708/aaf0bbd5/attachment.html

单独的对于以"年"为枝杆的显示方式更清晰一点

还有不重复的话 这样来的更明确
呵呵 或许是思维方式的原因


在06-7-8，swordsp <sparas2006 at gmail.com> 写道：
>
> 为什么需要单独的year表？除了年份还有什么信息？
> 一般来说，year直接作为people表的字段，然后查找people表时对这个字段做group操作就好了。
> 需要所有年份的时候也只要distinct一下就可以了。
>
>  On 7/8/06, 风向标 < vaneoooo at gmail.com> wrote:
>
> >
> > 我有表Year
> >
> > A = ...........
> > B = ..........
> >
> >  A字段表示国历生日
> > B字段表示农历生日
> >
> > 我有表people:
> >
> > name =.........
> > year = models.ForeignKey(Year)
> > group = .........
> >
> > 在程序中  他选择输入国历生日或者农历生日
> >   程序自动计算相对应的日期
> >
> > 我在显示时需要这样显示:
> >
> > 1999年生:
> >       张某某    李某   赵某
> > 2000年生:
> >        钱某某   朱某某  甄某
> >
> > 麻烦的是  页面是以group来分别显示各组的人员的
> > 我现在使用的是:
> > year_list = Year.objects.all()
> >
> > 也就是说  大体会出现这样的情况
> > 组A:
> >
> > 1999年生:
> >
> > 2000年生:
> >
> > 2001年生:
> >      刘某某   代某某
> >
> > 2002年生:
> >       郑某  夏某
> >
> > 组B:
> >
> > 1999年生:
> >       张某某    李某   赵某
> > 2000年生:
> >        钱某某   朱某某  甄某
> >
> > 2001年生:
> >
> > 2002年生:
> >
> > 这样的情况
> > 我只想让该组出现该组存在人员已有的年份
> > 但对结果集优化又会出现年份重复  不像现在这样分明
> > 还有些办法也太笨了点  效率低(例如循环分类)
> >
> > 大牛有没有稍微好点的办法?
> >
> > _______________________________________________
> > python-chinese
> > Post: send python-chinese at lists.python.cn
> > Subscribe: send subscribe to python-chinese-request at lists.python.cn
> > Unsubscribe: send unsubscribe to
> > python-chinese-request at lists.python.cn
> > Detail Info: http://python.cn/mailman/listinfo/python-chinese
> >
> >
>
>
> _______________________________________________
> python-chinese
> Post: send python-chinese at lists.python.cn
> Subscribe: send subscribe to python-chinese-request at lists.python.cn
> Unsubscribe: send unsubscribe to  python-chinese-request at lists.python.cn
> Detail Info: http://python.cn/mailman/listinfo/python-chinese
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20060708/f9f8f583/attachment.html

不是说显示方式的问题，显示的形式和数据的存储结构是两回事。
我的意思是，数据库中不需要用两张表来表达一张表就能表达的内容，这样会带来效率上的损失和维护上的代价。很多时候为了逻辑上的清晰和可扩充性可能需要这样做，但在这个例子中似乎没有带来任何的便利。

还有，不管是一张表还是两张表，你的需求都是一个group操作就能完成的。

On 7/8/06, 风向标 <vaneoooo at gmail.com> wrote:
>
>
> 单独的对于以"年"为枝杆的显示方式更清晰一点
>
> 还有不重复的话 这样来的更明确
> 呵呵 或许是思维方式的原因
>
>
> 在06-7-8，swordsp <sparas2006 at gmail.com> 写道：
>
> > 为什么需要单独的year表？除了年份还有什么信息？
> > 一般来说，year直接作为people表的字段，然后查找people表时对这个字段做group操作就好了。
> > 需要所有年份的时候也只要distinct一下就可以了。
> >
> >  On 7/8/06, 风向标 < vaneoooo at gmail.com > wrote:
> >
> > >
> > > 我有表Year
> > >
> > > A = ...........
> > > B = ..........
> > >
> > >  A字段表示国历生日
> > > B字段表示农历生日
> > >
> > > 我有表people:
> > >
> > > name =.........
> > > year = models.ForeignKey(Year)
> > > group = .........
> > >
> > > 在程序中  他选择输入国历生日或者农历生日
> > >   程序自动计算相对应的日期
> > >
> > > 我在显示时需要这样显示:
> > >
> > > 1999年生:
> > >       张某某    李某   赵某
> > > 2000年生:
> > >        钱某某   朱某某  甄某
> > >
> > > 麻烦的是  页面是以group来分别显示各组的人员的
> > > 我现在使用的是:
> > > year_list = Year.objects.all()
> > >
> > > 也就是说  大体会出现这样的情况
> > > 组A:
> > >
> > > 1999年生:
> > >
> > > 2000年生:
> > >
> > > 2001年生:
> > >      刘某某   代某某
> > >
> > > 2002年生:
> > >       郑某  夏某
> > >
> > > 组B:
> > >
> > > 1999年生:
> > >       张某某    李某   赵某
> > > 2000年生:
> > >        钱某某   朱某某  甄某
> > >
> > > 2001年生:
> > >
> > > 2002年生:
> > >
> > > 这样的情况
> > > 我只想让该组出现该组存在人员已有的年份
> > > 但对结果集优化又会出现年份重复  不像现在这样分明
> > > 还有些办法也太笨了点  效率低(例如循环分类)
> > >
> > > 大牛有没有稍微好点的办法?
> > >
> > > _______________________________________________
> > > python-chinese
> > > Post: send python-chinese at lists.python.cn
> > > Subscribe: send subscribe to python-chinese-request at lists.python.cn
> > > Unsubscribe: send unsubscribe to
> > > python-chinese-request at lists.python.cn
> > > Detail Info: http://python.cn/mailman/listinfo/python-chinese
> > >
> > >
> >
> >
> > _______________________________________________
> > python-chinese
> > Post: send python-chinese at lists.python.cn
> > Subscribe: send subscribe to python-chinese-request at lists.python.cn
> > Unsubscribe: send unsubscribe to  python-chinese-request at lists.python.cn
> > Detail Info: http://python.cn/mailman/listinfo/python-chinese
> >
> >
>
> _______________________________________________
> python-chinese
> Post: send python-chinese at lists.python.cn
> Subscribe: send subscribe to python-chinese-request at lists.python.cn
> Unsubscribe: send unsubscribe to  python-chinese-request at lists.python.cn
> Detail Info: http://python.cn/mailman/listinfo/python-chinese
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20060708/02bed15b/attachment.htm

感谢swordsp兄指教
确实是为了以后的可扩充性  更重要的是现在还有其他功能需要依靠年份
独立表单更能高效些
否则会造成大量重复

limodou兄
遇到点问题
我在交互式中测试  采用这样的方式能够正常判断出来:

for y in year_obj:
    y.people_set.filter(id=1).count()

但是问题在模板中进行这样的处理又另有问题
好象类似 filter()这样的形式不能出现在 {% if  .......%} 这样的判断中
我的id传递又存在了问题  ...在models写个函数吧  又有传递id的问题
我想过写单独的过滤器来写
但是过滤器只容纳一个参数   也就是我的y传送进去以后  作为ID的参数就没办法进去了

有点头疼.........


在06-7-8，swordsp <sparas2006 at gmail.com> 写道：
>
> 不是说显示方式的问题，显示的形式和数据的存储结构是两回事。
>
> 我的意思是，数据库中不需要用两张表来表达一张表就能表达的内容，这样会带来效率上的损失和维护上的代价。很多时候为了逻辑上的清晰和可扩充性可能需要这样做，但在这个例子中似乎没有带来任何的便利。
>
> 还有，不管是一张表还是两张表，你的需求都是一个group操作就能完成的。
>
>
> On 7/8/06, 风向标 <vaneoooo at gmail.com> wrote:
> >
> >
> > 单独的对于以"年"为枝杆的显示方式更清晰一点
> >
> > 还有不重复的话 这样来的更明确
> > 呵呵 或许是思维方式的原因
> >
> >
> > 在06-7-8，swordsp <sparas2006 at gmail.com> 写道：
> >
> > > 为什么需要单独的year表？除了年份还有什么信息？
> > > 一般来说，year直接作为people表的字段，然后查找people表时对这个字段做group操作就好了。
> > > 需要所有年份的时候也只要distinct一下就可以了。
> > >
> > >  On 7/8/06, 风向标 < vaneoooo at gmail.com > wrote:
> > >
> > > >
> > > > 我有表Year
> > > >
> > > > A = ...........
> > > > B = ..........
> > > >
> > > >  A字段表示国历生日
> > > > B字段表示农历生日
> > > >
> > > > 我有表people:
> > > >
> > > > name =.........
> > > > year = models.ForeignKey(Year)
> > > > group = .........
> > > >
> > > > 在程序中  他选择输入国历生日或者农历生日
> > > >   程序自动计算相对应的日期
> > > >
> > > > 我在显示时需要这样显示:
> > > >
> > > > 1999年生:
> > > >       张某某    李某   赵某
> > > > 2000年生:
> > > >        钱某某   朱某某  甄某
> > > >
> > > > 麻烦的是  页面是以group来分别显示各组的人员的
> > > > 我现在使用的是:
> > > > year_list = Year.objects.all()
> > > >
> > > > 也就是说  大体会出现这样的情况
> > > > 组A:
> > > >
> > > > 1999年生:
> > > >
> > > > 2000年生:
> > > >
> > > > 2001年生:
> > > >      刘某某   代某某
> > > >
> > > > 2002年生:
> > > >       郑某  夏某
> > > >
> > > > 组B:
> > > >
> > > > 1999年生:
> > > >       张某某    李某   赵某
> > > > 2000年生:
> > > >        钱某某   朱某某  甄某
> > > >
> > > > 2001年生:
> > > >
> > > > 2002年生:
> > > >
> > > > 这样的情况
> > > > 我只想让该组出现该组存在人员已有的年份
> > > > 但对结果集优化又会出现年份重复  不像现在这样分明
> > > > 还有些办法也太笨了点  效率低(例如循环分类)
> > > >
> > > > 大牛有没有稍微好点的办法?
> > > >
> > > > _______________________________________________
> > > > python-chinese
> > > > Post: send python-chinese at lists.python.cn
> > > > Subscribe: send subscribe to python-chinese-request at lists.python.cn
> > > > Unsubscribe: send unsubscribe to
> > > > python-chinese-request at lists.python.cn
> > > > Detail Info: http://python.cn/mailman/listinfo/python-chinese
> > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > python-chinese
> > > Post: send python-chinese at lists.python.cn
> > > Subscribe: send subscribe to python-chinese-request at lists.python.cn
> > > Unsubscribe: send unsubscribe to
> > > python-chinese-request at lists.python.cn
> > > Detail Info: http://python.cn/mailman/listinfo/python-chinese
> > >
> > >
> >
> >
> > _______________________________________________
> > python-chinese
> > Post: send python-chinese at lists.python.cn
> > Subscribe: send subscribe to python-chinese-request at lists.python.cn
> > Unsubscribe: send unsubscribe to
> > python-chinese-request at lists.python.cn
> > Detail Info: http://python.cn/mailman/listinfo/python-chinese
> >
> >
>
> _______________________________________________
> python-chinese
> Post: send python-chinese at lists.python.cn
> Subscribe: send subscribe to python-chinese-request at lists.python.cn
> Unsubscribe: send unsubscribe to  python-chinese-request at lists.python.cn
> Detail Info: http://python.cn/mailman/listinfo/python-chinese
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20060709/379fa7c3/attachment.htm

其实也不需要单独用一个year的字段，就用通常的DateTime就好了。
一般来说，关系数据库的实现都有提供DateFormat这样的函数，这样就可以从一个DateTime字段中过滤出日期时间的每一个段了。接下来，把过滤出来的东西作一个as别名，然后就可以对其进行group或者having的操作，前面再用distinct和count就可以求出来数据了。
总的来说，很多复杂的操作都可以通过一条sql语句来实现的。现阶段的mysql对于子查询支持的还不太好，换作是SQL
Server或者oracle，一个复杂的报表数据再加上同时的数据更新都可以通过一条语句来实现的。

在 06-7-8，swordsp<sparas2006 at gmail.com> 写道：
> 不是说显示方式的问题，显示的形式和数据的存储结构是两回事。
> 我的意思是，数据库中不需要用两张表来表达一张表就能表达的内容，这样会带来效率上的损失和维护上的代价。很多时候为了逻辑上的清晰和可扩充性可能需要这样做，但在这个例子中似乎没有带来任何的便利。
>
> 还有，不管是一张表还是两张表，你的需求都是一个group操作就能完成的。
>
>
> On 7/8/06, 风向标 <vaneoooo at gmail.com> wrote:
> >
> >
> >
> > 单独的对于以"年"为枝杆的显示方式更清晰一点
> >
> > 还有不重复的话 这样来的更明确
> > 呵呵 或许是思维方式的原因
> >
> >
> > 在06-7-8，swordsp <sparas2006 at gmail.com> 写道：
> >
> > >
> > > 为什么需要单独的year表？除了年份还有什么信息？
> > > 一般来说，year直接作为people表的字段，然后查找people表时对这个字段做group操作就好了。
> > > 需要所有年份的时候也只要distinct一下就可以了。
> > >
> > >
> > >
> > > On 7/8/06, 风向标 < vaneoooo at gmail.com > wrote:
> > >
> > > >
> > > >
> > > >
> > > >
> > > > 我有表Year
> > > >
> > > > A = ...........
> > > > B = ..........
> > > >
> > > >
> > > > A字段表示国历生日
> > > > B字段表示农历生日
> > > >
> > > > 我有表people:
> > > >
> > > > name =.........
> > > > year = models.ForeignKey(Year)
> > > > group = .........
> > > >
> > > > 在程序中  他选择输入国历生日或者农历生日
> > > >   程序自动计算相对应的日期
> > > >
> > > > 我在显示时需要这样显示:
> > > >
> > > > 1999年生:
> > > >       张某某    李某   赵某
> > > > 2000年生:
> > > >        钱某某   朱某某  甄某
> > > >
> > > > 麻烦的是  页面是以group来分别显示各组的人员的
> > > > 我现在使用的是:
> > > > year_list = Year.objects.all()
> > > >
> > > > 也就是说  大体会出现这样的情况
> > > > 组A:
> > > >
> > > > 1999年生:
> > > >
> > > > 2000年生:
> > > >
> > > > 2001年生:
> > > >      刘某某   代某某
> > > >
> > > > 2002年生:
> > > >       郑某  夏某
> > > >
> > > > 组B:
> > > >
> > > >
> > > > 1999年生:
> > > >       张某某    李某   赵某
> > > > 2000年生:
> > > >        钱某某   朱某某  甄某
> > > >
> > > > 2001年生:
> > > >
> > > > 2002年生:
> > > >
> > > > 这样的情况
> > > > 我只想让该组出现该组存在人员已有的年份
> > > > 但对结果集优化又会出现年份重复  不像现在这样分明
> > > > 还有些办法也太笨了点  效率低(例如循环分类)
> > > >
> > > > 大牛有没有稍微好点的办法?
> > > >
> > > > _______________________________________________
> > > > python-chinese
> > > > Post: send python-chinese at lists.python.cn
> > > > Subscribe: send subscribe to
> python-chinese-request at lists.python.cn
> > > > Unsubscribe: send unsubscribe to
> python-chinese-request at lists.python.cn
> > > > Detail Info:
> http://python.cn/mailman/listinfo/python-chinese
> > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > python-chinese
> > > Post: send python-chinese at lists.python.cn
> > > Subscribe: send subscribe to
> python-chinese-request at lists.python.cn
> > > Unsubscribe: send unsubscribe to
> python-chinese-request at lists.python.cn
> > > Detail Info:
> http://python.cn/mailman/listinfo/python-chinese
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > python-chinese
> > Post: send python-chinese at lists.python.cn
> > Subscribe: send subscribe to
> python-chinese-request at lists.python.cn
> > Unsubscribe: send unsubscribe to
> python-chinese-request at lists.python.cn
> > Detail Info:
> http://python.cn/mailman/listinfo/python-chinese
> >
> >
>
>
> _______________________________________________
> python-chinese
> Post: send python-chinese at lists.python.cn
> Subscribe: send subscribe to
> python-chinese-request at lists.python.cn
> Unsubscribe: send unsubscribe to
> python-chinese-request at lists.python.cn
> Detail Info:
> http://python.cn/mailman/listinfo/python-chinese
>
>

On 7/9/06, 马踏飞燕 <honeyday.mj at gmail.com> wrote:
>
> 其实也不需要单独用一个year的字段，就用通常的DateTime就好了。
>
> 一般来说，关系数据库的实现都有提供DateFormat这样的函数，这样就可以从一个DateTime字段中过滤出日期时间的每一个段了。接下来，把过滤出来的东西作一个as别名，然后就可以对其进行group或者having的操作，前面再用distinct和count就可以求出来数据了。


功能上当然没有问题，但性能上有差距，特别是对索引的处理。

总的来说，很多复杂的操作都可以通过一条sql语句来实现的。现阶段的mysql对于子查询支持的还不太好，换作是SQL
> Server或者oracle，一个复杂的报表数据再加上同时的数据更新都可以通过一条语句来实现的。


许多操作写成一条sql是很爽快，但效率未见得最优，也要谨慎一些的好。
最要命的是，sql的执行时间不确定因素太大了，远不如程序能够精确的分析和预测。
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20060709/5dc6e890/attachment.htm

ºÇºÇ£¬ÕâÇ£³¶µ½Ò»¸öºÜÀϵÄÕùÂÛÁË£¬¾ÍÊÇÒµÎñÂß¼­ÊÇÍêÈ«·ÅÔÚSQLÖУ¬»¹ÊÇÍêÈ«·ÅÔÚ³Ì
ÐòÖУ¬»¹ÊǸ÷Ò»²¿·Ö
ò¯³ÏµÄJ2EEÅÉÈÏΪҵÎñÂß¼­Ó¦¸ÃÍêÈ«¸úÊý¾Ý¿â´æ´¢ÍÑÀ룬EJB¿ÉÒÔÖ±½Ó±íʾһ¸öÊý¾Ý¶Ô
Ïó£¬Í¬Ê±Session BeanºÍXMLµÄ²éѯÓïÑÔ¿ÉÒÔ¶ÔÕâ¸öEJB½øÐи÷ÖÖÂß¼­²Ù×÷£¬ÔÚÕâÖÖÌå
ÖÆÖУ¬¡°Êý¾Ý¿â¡±Ö»²»¹ýÊÇÕâ¸öEJBÔÚÓ²ÅÌÉϵÄÎïÀí¿½±´¶øÒÑ
¶øÊý¾Ý¿âÖ§³ÖÕßÕâÔòÈÏΪ°ÑËùÓеÄÂß¼­¾¡¿ÉÄÜÓô洢¹ý³ÌÀ´Íê³É£¬ÕâÑùЧÂÊ×î¸ß¡£×î
µäÐ͵ľÍÊÇInformixµÄ4GLÓïÑÔ¡£ÀíÂÛÉÏÒ»¸öÓÃ4GLʵÏÖµÄÂß¼­¹ý³ÌÒª±ÈJ2EEģʽ¿ìÁ½
¸öÊýÁ¿¼¶£¨Ò²¾ÍÊÇÊýÊ®±¶£©
²»¹ýÓÉÓÚÈÕÇ°µçÄÔCPUºÍÄÚ´æÊý¶È¼«´óµÄÌáÉý£¬Æ¿¾±ÒѾ­²»ÔÚÂß¼­ÔËËã¶øÔÚÓ²Å̵Ĵ洢
Ëٶȣ¬ËùÒÔÁ½ÕßÐÔÄܲî±ð²»ÊǺÜÃ÷ÏÔ

¸öÈ˹۵㣬Èç¹ûÄãµÄÓ¦Ó÷dz£¹Ì¶¨£¬Ã»ÓÐÈκÎÀ©Õ¹ºÍƽ̨ÒÆÖ²µÄ´òË㣬²¢ÇÒʹÓÃÖîÈç
Oracle,SybaseºÍInformixÖ®ÀàµÄ¸ßÐÔÄÜÊý¾Ý¿â£¬ÄÇô¿ÉÒÔ½«ÒµÎñÂß¼­½»ÓÉÊý¾Ý¿âʵÏÖ
·´Ö®£¬¾¡Á¿ÓɳÌÐòʵÏÖÒµÎñÂß¼­
»¹ÓÐÒ»µã¾ÍÊÇ£¬Ä¿Ç°¼¸ºõËùÓеÄSQL¶¼ÊÇÃæÏò¹ý³Ì±à³ÌµÄ£¬Õâ¾ÍÒª¿´±à³ÌÈËÔ±µÄϲºÃ
ÁË£¬Èç¹ûÄ㲻ϲ»¶ÕâÖÖ·ç¸ñ£¬ÄÇ»¹ÊÇÓø߼¶OOÓïÑÔÈ¥°É£¨4GL±¾À´ÓкܺõÄOO·¢Õ¹Ç°
;£¬¿Éϧ¡­¡­£©
ÁíÍâMySQLÕâÖÖÍæ¾ß¼¶±ðµÄ¶«Î÷£¬ÊÇÎÞÁ¦³ÐÔØÉÌÒµÒµÎñÂß¼­µÄ

Best Regards,

Zachary Wu (Îâ°~ÀÚ)
Software Engineer, Enterprise Content Management FVT, IBM China Software
Development Lab
Tel: +86 10 82782244-3235. Fax: 82782244-2886 Tie Line: 915-2244-3235
Internet: xiaoleiw at cn.ibm.com
Notes ID: Xiao Lei Wu/China/Contr/IBM at IBMCN
Address: 8/F, Block A, Power Creative Building, No.1, East Road, Shang Di,
Beijing 100085, P.R. China

python-chinese-bounces at lists.python.cn дÓÚ 2006-07-09 23:51:41:

> On 7/9/06, Âí̤·ÉÑà <honeyday.mj at gmail.com> wrote:
> ÆäʵҲ²»ÐèÒªµ¥¶ÀÓÃÒ»¸öyearµÄ×ֶΣ¬¾ÍÓÃͨ³£µÄDateTime¾ÍºÃÁË¡£
> Ò»°ãÀ´Ëµ£¬¹ØϵÊý¾Ý¿âµÄʵÏÖ¶¼ÓÐÌṩDateFormatÕâÑùµÄº¯Êý£¬ÕâÑù¾Í¿ÉÒÔ´Ó
> Ò»¸öDateTime×Ö¶ÎÖйýÂ˳öÈÕÆÚʱ¼äµÄÿһ¸ö¶ÎÁË¡£½ÓÏÂÀ´£¬°Ñ¹ýÂ˳öÀ´µÄ¶«
> Î÷×÷Ò»¸öas±ðÃû£¬È»ºó¾Í¿ÉÒÔ¶ÔÆä½øÐÐgroup»òÕßhavingµÄ²Ù×÷£¬Ç°ÃæÔÙÓÃ
> distinctºÍcount¾Í¿ÉÒÔÇó³öÀ´Êý¾ÝÁË¡£
>
> ¹¦ÄÜÉϵ±È»Ã»ÓÐÎÊÌ⣬µ«ÐÔÄÜÉÏÓвî¾à£¬ÌرðÊǶÔË÷ÒýµÄ´¦Àí¡£
>
> ×ܵÄÀ´Ëµ£¬ºÜ¶à¸´ÔӵIJÙ×÷¶¼¿ÉÒÔͨ¹ýÒ»ÌõsqlÓï¾äÀ´ÊµÏֵġ£Ïֽ׶εÄ
> mysql¶ÔÓÚ×Ó²éѯ֧³ÖµÄ»¹²»Ì«ºÃ£¬»»×÷ÊÇSQL
> Server»òÕßoracle£¬Ò»¸ö¸´Ôӵı¨±íÊý¾ÝÔÙ¼ÓÉÏͬʱµÄÊý¾Ý¸üж¼¿ÉÒÔͨ¹ýÒ»
> ÌõÓï¾äÀ´ÊµÏֵġ£
>
> Ðí¶à²Ù×÷д³ÉÒ»ÌõsqlÊǺÜˬ¿ì£¬µ«Ð§ÂÊδ¼ûµÃ×îÓÅ£¬Ò²Òª½÷É÷һЩµÄºÃ¡£
> ×îÒªÃüµÄÊÇ£¬sqlµÄÖ´ÐÐʱ¼ä²»È·¶¨ÒòËØÌ«´óÁË£¬Ô¶²»Èç³ÌÐòÄܹ»¾«È·µÄ·ÖÎöºÍÔ¤
²â¡£
> _______________________________________________
> python-chinese
> Post: send python-chinese at lists.python.cn
> Subscribe: send subscribe to python-chinese-request at lists.python.cn
> Unsubscribe: send unsubscribe to  python-chinese-request at lists.python.cn
> Detail Info: http://python.cn/mailman/listinfo/python-chinese
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20060710/ceeec916/attachment.html

On 7/10/06, Xiao Lei Wu <xiaoleiw at cn.ibm.com> wrote:
>
>
>
> 呵呵，这牵扯到一个很老的争论了，就是业务逻辑是完全放在SQL中，还是完全放在程序中，还是各一部分
>  虔诚的J2EE派认为业务逻辑应该完全跟数据库存储脱离，EJB可以直接表示一个数据对象，同时Session
> Bean和XML的查询语言可以对这个EJB进行各种逻辑操作，在这种体制中，"数据库"只不过是这个EJB在硬盘上的物理拷贝而已
> 而数据库支持者这则认为把所有的逻辑尽可能用存储过程来完成，这样效率最高。最典型的就是Informix的4GL语言。理论上一个用4GL实现的逻辑过程要比J2EE模式快两个数量级（也就是数十倍）
>  不过由于日前电脑CPU和内存数度极大的提升，瓶颈已经不在逻辑运算而在硬盘的存储速度，所以两者性能差别不是很明显
>
> 个人观点，如果你的应用非常固定，没有任何扩展和平台移植的打算，并且使用诸如Oracle,Sybase和Informix之类的高性能数据库，那么可以将业务逻辑交由数据库实现
>  反之，尽量由程序实现业务逻辑
> 还有一点就是，目前几乎所有的SQL都是面向过程编程的，这就要看编程人员的喜好了，如果你不喜欢这种风格，那还是用高级OO语言去吧（4GL本来有很好的OO发展前途，可惜……）
>  另外MySQL这种玩具级别的东西，是无力承载商业业务逻辑的
>
MySQL与商业业务没有必然的联系吧。商业就一定意味着高性能，高可用性吗？商业的本质就是赚钱，有些很烂的项目是彻底的商业东西。

好坏与否有一系列的评判的标准和方法，还要看不同的环境，不是容易做出的。如果脱离具体的环境，只说某个软件或产品并不恰当。

-- 
I like python!
My Blog: http://www.donews.net/limodou
My Django Site: http://www.djangocn.org
NewEdit Maillist: http://groups.google.com/group/NewEdit

个人认为还是不要把逻辑放到数据库存储中，这样维护困难。

在06-7-10，limodou <limodou at gmail.com> 写道：
>
> On 7/10/06, Xiao Lei Wu <xiaoleiw at cn.ibm.com> wrote:
> >
> >
> >
> > 呵呵，这牵扯到一个很老的争论了，就是业务逻辑是完全放在SQL中，还是完全放在程序中，还是各一部分
> >  虔诚的J2EE派认为业务逻辑应该完全跟数据库存储脱离，EJB可以直接表示一个数据对象，同时Session
> > Bean和XML的查询语言可以对这个EJB进行各种逻辑操作，在这种体制中，"数据库"只不过是这个EJB在硬盘上的物理拷贝而已
> >
> 而数据库支持者这则认为把所有的逻辑尽可能用存储过程来完成，这样效率最高。最典型的就是Informix的4GL语言。理论上一个用4GL实现的逻辑过程要比J2EE模式快两个数量级（也就是数十倍）
> >  不过由于日前电脑CPU和内存数度极大的提升，瓶颈已经不在逻辑运算而在硬盘的存储速度，所以两者性能差别不是很明显
> >
> >
> 个人观点，如果你的应用非常固定，没有任何扩展和平台移植的打算，并且使用诸如Oracle,Sybase和Informix之类的高性能数据库，那么可以将业务逻辑交由数据库实现
> >  反之，尽量由程序实现业务逻辑
> >
> 还有一点就是，目前几乎所有的SQL都是面向过程编程的，这就要看编程人员的喜好了，如果你不喜欢这种风格，那还是用高级OO语言去吧（4GL本来有很好的OO发展前途，可惜……）
> >  另外MySQL这种玩具级别的东西，是无力承载商业业务逻辑的
> >
> MySQL与商业业务没有必然的联系吧。商业就一定意味着高性能，高可用性吗？商业的本质就是赚钱，有些很烂的项目是彻底的商业东西。
>
> 好坏与否有一系列的评判的标准和方法，还要看不同的环境，不是容易做出的。如果脱离具体的环境，只说某个软件或产品并不恰当。
>
> --
> I like python!
> My Blog: http://www.donews.net/limodou
> My Django Site: http://www.djangocn.org
> NewEdit Maillist: http://groups.google.com/group/NewEdit
>
> _______________________________________________
> python-chinese
> Post: send python-chinese at lists.python.cn
> Subscribe: send subscribe to python-chinese-request at lists.python.cn
> Unsubscribe: send unsubscribe to  python-chinese-request at lists.python.cn
> Detail Info: http://python.cn/mailman/listinfo/python-chinese
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20060710/cb8d0c2c/attachment.htm

On 7/10/06, Xiao Lei Wu <xiaoleiw at cn.ibm.com> wrote:
>
> 呵呵，这牵扯到一个很老的争论了，就是业务逻辑是完全放在SQL中，还是完全放在程序中，还是各一部分
> 虔诚的J2EE派认为业务逻辑应该完全跟数据库存储脱离，EJB可以直接表示一个数据对象，同时Session
> Bean和XML的查询语言可以对这个EJB进行各种逻辑操作，在这种体制中，"数据库"只不过是这个EJB在硬盘上的物理拷贝而已
>
> 而数据库支持者这则认为把所有的逻辑尽可能用存储过程来完成，这样效率最高。最典型的就是Informix的4GL语言。理论上一个用4GL实现的逻辑过程要比J2EE模式快两个数量级（也就是数十倍）
> 不过由于日前电脑CPU和内存数度极大的提升，瓶颈已经不在逻辑运算而在硬盘的存储速度，所以两者性能差别不是很明显
>
>
> 个人观点，如果你的应用非常固定，没有任何扩展和平台移植的打算，并且使用诸如Oracle,Sybase和Informix之类的高性能数据库，那么可以将业务逻辑交由数据库实现
> 反之，尽量由程序实现业务逻辑
>
> 还有一点就是，目前几乎所有的SQL都是面向过程编程的，这就要看编程人员的喜好了，如果你不喜欢这种风格，那还是用高级OO语言去吧（4GL本来有很好的OO发展前途，可惜……）
>
这是一个一般性的设计考量，使用任何语言编程都可以把逻辑从sql中剥离出来，而不仅仅是"J2EE派"。
事实上，除去少数原教旨主义者和基于某些完整框架的应用，现在在实践中大多是两者结合的。

有些人先从直观的sql语句和存储过程写起，等项目规模变大之后，再逐渐将底层的操作颗粒细化，逐渐将更高级别的抽象逻辑移到上层代码中，以提高代码的可维护性和可扩展性。
如果开发团队本身对sql很熟悉，或者是在遗留代码的基础上，或者项目本身逻辑很简单，那么多采取这种自底向上的方式。

也有些人则是先从对象建模开始，在项目初期最大限度使用ORM等技术隔离底层的sql操作，等完成项目原型之后再进行效率调优，必要的时候把关键代码用手写sql或者存储过程替代。（所以"快几十倍"的说法其实没有意义，因为如果真的是效率瓶颈，肯定会在优化的时候用存储过程重写的）
如果开发团队有很好的面向对象的概念，项目规模又比较大，那么多采取这种自顶向下的方式。
由于现在ORM技术发展越来越成熟，再加上快速开发框架的集成，即使是小型项目中运用这种方式进行快速开发的效率也不低于自底向上的方式了，所以现在采用的也越来越频繁。

另外MySQL这种玩具级别的东西，是无力承载商业业务逻辑的
>
商业应用 != 企业级应用
MySQL的确不是企业级的产品，但绝大多数一般商业应用还是足够应付了的。
许多复杂的操作其实只需要在数据库和代码的组织上稍下功夫都是可以避开或者绕过的。
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20060710/0c67d6f8/attachment.html

On 7/10/06, Xiao Lei Wu <xiaoleiw at cn.ibm.com> wrote:
>
> [snip]
> 另外MySQL这种玩具级别的东西，是无力承载商业业务逻辑的
>
> 嘿嘿，这是IBM的观点吧（不排除Oracle和Microsoft也非常支持)




-- 
simple is good
http://brucewang.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20060710/ab5bbaf4/attachment.htm

ÕùÂÛÀ´£¬ÕùÂÛÈ¥£®Õâ¸ö¶«¶«¶¼ÊÇÍâ¹úÈËÌá³öÀ´µÄ£®ÎÒÃÇÖ»ÊDZ»Ç£×űÇ×Ó×ߣ®

»¹ÓÐһЩÈË°ï×ÅÍâ¹úÈ˺°£®ÁíÓÐһЩÈ˳­×÷£®Ä¿µÄ¾ÍÊÇΪÁË׬£®Ò»¸ö¼òµ¥µÄguest bookÓÃj2ee ¼Ü¹¹ÖØдһÏ£®¾Í¿É¸ßм¼Êõ£®£®¿ÉÒÔÆ«¡ç¡ç¡çÁË£®£®

£»£©
  ----- Original Message ----- 
  From: swordsp 
  To: python-chinese at lists.python.cn 
  Sent: Monday, July 10, 2006 12:24 PM
  Subject: Re: [python-chinese] [django] Ò»¸öÀÏÎÊÌâ ¹ØÓÚÊý¾Ý´¦Àí




  On 7/10/06, Xiao Lei Wu <xiaoleiw at cn.ibm.com> wrote:
    ºÇºÇ£¬ÕâÇ£³¶µ½Ò»¸öºÜÀϵÄÕùÂÛÁË£¬¾ÍÊÇÒµÎñÂß¼­ÊÇÍêÈ«·ÅÔÚSQLÖУ¬»¹ÊÇÍêÈ«·ÅÔÚ³ÌÐòÖУ¬»¹ÊǸ÷Ò»²¿·Ö
    ò¯³ÏµÄJ2EEÅÉÈÏΪҵÎñÂß¼­Ó¦¸ÃÍêÈ«¸úÊý¾Ý¿â´æ´¢ÍÑÀ룬EJB¿ÉÒÔÖ±½Ó±íʾһ¸öÊý¾Ý¶ÔÏó£¬Í¬Ê±Session BeanºÍXMLµÄ²éѯÓïÑÔ¿ÉÒÔ¶ÔÕâ¸öEJB½øÐи÷ÖÖÂß¼­²Ù×÷£¬ÔÚÕâÖÖÌåÖÆÖУ¬"Êý¾Ý¿â"Ö»²»¹ýÊÇÕâ¸öEJBÔÚÓ²ÅÌÉϵÄÎïÀí¿½±´¶øÒÑ
    ¶øÊý¾Ý¿âÖ§³ÖÕßÕâÔòÈÏΪ°ÑËùÓеÄÂß¼­¾¡¿ÉÄÜÓô洢¹ý³ÌÀ´Íê³É£¬ÕâÑùЧÂÊ×î¸ß¡£×îµäÐ͵ľÍÊÇInformixµÄ4GLÓïÑÔ¡£ÀíÂÛÉÏÒ»¸öÓÃ4GLʵÏÖµÄÂß¼­¹ý³ÌÒª±ÈJ2EEģʽ¿ìÁ½¸öÊýÁ¿¼¶£¨Ò²¾ÍÊÇÊýÊ®±¶£©
    ²»¹ýÓÉÓÚÈÕÇ°µçÄÔCPUºÍÄÚ´æÊý¶È¼«´óµÄÌáÉý£¬Æ¿¾±ÒѾ­²»ÔÚÂß¼­ÔËËã¶øÔÚÓ²Å̵Ĵ洢Ëٶȣ¬ËùÒÔÁ½ÕßÐÔÄܲî±ð²»ÊǺÜÃ÷ÏÔ

    ¸öÈ˹۵㣬Èç¹ûÄãµÄÓ¦Ó÷dz£¹Ì¶¨£¬Ã»ÓÐÈκÎÀ©Õ¹ºÍƽ̨ÒÆÖ²µÄ´òË㣬²¢ÇÒʹÓÃÖîÈçOracle,SybaseºÍInformixÖ®ÀàµÄ¸ßÐÔÄÜÊý¾Ý¿â£¬ÄÇô¿ÉÒÔ½«ÒµÎñÂß¼­½»ÓÉÊý¾Ý¿âʵÏÖ
    ·´Ö®£¬¾¡Á¿ÓɳÌÐòʵÏÖÒµÎñÂß¼­
    »¹ÓÐÒ»µã¾ÍÊÇ£¬Ä¿Ç°¼¸ºõËùÓеÄSQL¶¼ÊÇÃæÏò¹ý³Ì±à³ÌµÄ£¬Õâ¾ÍÒª¿´±à³ÌÈËÔ±µÄϲºÃÁË£¬Èç¹ûÄ㲻ϲ»¶ÕâÖÖ·ç¸ñ£¬ÄÇ»¹ÊÇÓø߼¶OOÓïÑÔÈ¥°É£¨4GL±¾À´ÓкܺõÄOO·¢Õ¹Ç°Í¾£¬¿Éϧ¡­¡­£©

  ÕâÊÇÒ»¸öÒ»°ãÐÔµÄÉè¼Æ¿¼Á¿£¬Ê¹ÓÃÈκÎÓïÑÔ±à³Ì¶¼¿ÉÒÔ°ÑÂß¼­´ÓsqlÖаþÀë³öÀ´£¬¶ø²»½ö½öÊÇ"J2EEÅÉ"¡£
  ÊÂʵÉÏ£¬³ýÈ¥ÉÙÊýÔ­½ÌÖ¼Ö÷ÒåÕߺͻùÓÚijЩÍêÕû¿ò¼ÜµÄÓ¦Óã¬ÏÖÔÚÔÚʵ¼ùÖдó¶àÊÇÁ½Õß½áºÏµÄ¡£

  ÓÐЩÈËÏÈ´ÓÖ±¹ÛµÄsqlÓï¾äºÍ´æ´¢¹ý³ÌдÆ𣬵ÈÏîÄ¿¹æÄ£±ä´óÖ®ºó£¬ÔÙÖð½¥½«µ×²ãµÄ²Ù×÷¿ÅÁ£Ï¸»¯£¬Öð½¥½«¸ü¸ß¼¶±ðµÄ³éÏóÂß¼­ÒƵ½Éϲã´úÂëÖУ¬ÒÔÌá¸ß´úÂëµÄ¿Éά»¤ÐԺͿÉÀ©Õ¹ÐÔ¡£
  Èç¹û¿ª·¢ÍŶӱ¾Éí¶ÔsqlºÜÊìϤ£¬»òÕßÊÇÔÚÒÅÁô´úÂëµÄ»ù´¡ÉÏ£¬»òÕßÏîÄ¿±¾ÉíÂß¼­ºÜ¼òµ¥£¬ÄÇô¶à²ÉÈ¡ÕâÖÖ×Ôµ×ÏòÉϵķ½Ê½¡£

  Ò²ÓÐЩÈËÔòÊÇÏÈ´Ó¶ÔÏó½¨Ä£¿ªÊ¼£¬ÔÚÏîÄ¿³õÆÚ×î´óÏÞ¶ÈʹÓÃORMµÈ¼¼Êõ¸ôÀëµ×²ãµÄsql²Ù×÷£¬µÈÍê³ÉÏîÄ¿Ô­ÐÍÖ®ºóÔÙ½øÐÐЧÂʵ÷ÓÅ£¬±ØÒªµÄʱºò°Ñ¹Ø¼ü´úÂëÓÃÊÖдsql»òÕß´æ´¢¹ý³ÌÌæ´ú¡££¨ËùÒÔ"¿ì¼¸Ê®±¶"µÄ˵·¨ÆäʵûÓÐÒâÒ壬ÒòΪÈç¹ûÕæµÄÊÇЧÂÊÆ¿¾±£¬¿Ï¶¨»áÔÚÓÅ»¯µÄʱºòÓô洢¹ý³ÌÖØдµÄ£©
  Èç¹û¿ª·¢ÍŶÓÓкܺõÄÃæÏò¶ÔÏóµÄ¸ÅÄÏîÄ¿¹æÄ£ÓֱȽϴó£¬ÄÇô¶à²ÉÈ¡ÕâÖÖ×Ô¶¥Ïòϵķ½Ê½¡£
  ÓÉÓÚÏÖÔÚORM¼¼Êõ·¢Õ¹Ô½À´Ô½³ÉÊ죬ÔÙ¼ÓÉÏ¿ìËÙ¿ª·¢¿ò¼ÜµÄ¼¯³É£¬¼´Ê¹ÊÇСÐÍÏîÄ¿ÖÐÔËÓÃÕâÖÖ·½Ê½½øÐп
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20060710/8da786bf/attachment.html

ºÇºÇ£¬¿´À´ÕâÀïµÄMySQLµÄÐÅͽºÜ¶à¡£
ºÜ¶àÈ˺ÜÉÙ»òÕß´Ó²»½Ó´¥¡°ÉÌÒµÂß¼­¡±£¬×¢ÒâÎÒÕâÀïËù˵µÄ¡°ÉÌÒµÂß¼­¡±Ö¸µÄÊÇ¡°Âß¼­¡±µÄ
ÀàÐÍ£¬¶ø²»ÊÇÓ¦ÓùæÄ££¬ËùÒÔ¸úʲô¡°ÆóÒµ¼¶¡±Õ´²»Éϱߡ£
ÎÒÃÇͨ³£ËùÃæ¶ÔµÄÉÌÒµÂß¼­£¬»ù±¾ÉÏÊDzÆÎñ¡¢½øÏú´æ¡¢ÎïÁϹÜÀí¡¢¿Í»§×ÊÔ´¹ÜÀí
µÈ£¬°üÀ¨OAÒ²¿ÉËãΪÉÌÒµÂß¼­£¬Ò²¾ÍÊÇÎÒÃÇͨ³£Ëù˵µÄ£¬ERP,SCM,CRMµÈÈí¼þ¡£
ÔÚ×îΪ¼ò½àÉÌÒµÂß¼­ÖУ¬Ò²ÐèÒª´óÁ¿µÄ×Ó²éѯ¡¢´¥·¢Æ÷¡¢ÁªºÏ²éѯ¡¢¿ä¿âÊÓ
ͼ¡¢Ëø¡¢¹æÔòµÈSQLÌØÐÔ£¬Õâµã´ó¼Ò¿ÉÒԲο¼¿ªÔ´µÄERPʵÏÖCompiere¡£
µ±È»ÀíÂÛÉϽ²£¬¿ÉÒÔÓñà³Ì´úÌæ×Ó²éѯ¡¢´¥·¢Æ÷µÈ¶«Î÷£¬µ«ÊÇÕâ¸öÄѶÈÊdz¬³öÒ»°ãµÄ
ÉÌÒµ±à³ÌµÄµÈ¼¶ÁË£¬ÒѾ­½Ó½ü¼«ÏÞ±à³ÌÁË¡£
ËùÒÔ˵£¬²»Ö§³Ö¸ß¼¶SQLÌØÐÔµÄMySQLÖ»²»¹ýÊǸöÍæ¾ß£¬ÎÞ·¨³ÐÔØÉÌÒµÂß¼­£¬Òò´ËÏò
CompiereÕâÑùµÄ¿ªÔ´Èí¼þÒ²²»Ñ¡ÔñMySQL£¨Êµ¼ÊÊÇû°ì·¨Ñ¡Ôñ£©¡£¶øCompiereËùʵÏÖµÄ
ÉÌÒµÂß¼­Ò²Ö»²»¹ýÊDZȽϼòµ¥µÄ£¬ÖÐСÆóÒµ¹æÄ£µÄ£¬ËûֻʵÏÖÁ˲»µ½SAP50%µÄÉÌÒµÂß
¼­¡£

Èç¹ûÏëÓÿªÔ´Èí¼þ×öÉÌÒµÊý¾Ý¿âµÄ»°£¬ÍƼöPostgreSQL£¬ËûÖ§³Ö¼¸ºõËùÓеĸ߶ËSQLÌØ
ÐÔ£¬²¢ÇÒÔںܶàÖØÒªÁìÓò£¨±ÈÈçÅ©ÐУ©Óгɹ¦Ó¦Óá£

ÁíÍ⣬4GLÊǸöÌØÊâµÄ¶«Î÷£¬²»ÒªÓô«Í³µÄSQL˼άÀ´Àí½âËû£¬ÓÐÐËȤµÄÈË¿ÉÒÔÈ¥¿´Ò»
ЩÏà¹Ø×ÊÁÏ¡£Ôø¾­ÎÒµÄÒ»¸öÉϺ£ÅóÓѾÍÊÇ4GL³ÌÐòÔ±£¬ËûÃÇÒ»¼ÒºÜ´óµĄ̈ÍåÆóÒµËùÓÐÉÌ
ÒµÂß¼­¶¼ÊÇ4GL±àдµÄ£¬Ö»²»¹ýÊÇÓÃC++×öÁËÒ»¸öͼÐÎÇ°¶Ë¡£4GL±àдµÄÓ¦ÓñÈÖ±½ÓÓÃ
C++µ÷InformixµÄODBCµÄÈ·¿ì2¸öÊýÁ¿¼¶

Best Regards,

Zachary Wu (Îâ°~ÀÚ)
Software Engineer, Enterprise Content Management FVT, IBM China Software
Development Lab
Tel: +86 10 82782244-3235. Fax: 82782244-2886 Tie Line: 915-2244-3235
Internet: xiaoleiw at cn.ibm.com
Notes ID: Xiao Lei Wu/China/Contr/IBM at IBMCN
Address: 8/F, Block A, Power Creative Building, No.1, East Road, Shang Di,
Beijing 100085, P.R. China

python-chinese-bounces at lists.python.cn дÓÚ 2006-07-10 13:32:25:

>

> On 7/10/06, Xiao Lei Wu <xiaoleiw at cn.ibm.com> wrote:
> [snip]
> ÁíÍâMySQLÕâÖÖÍæ¾ß¼¶±ðµÄ¶«Î÷£¬ÊÇÎÞÁ¦³ÐÔØÉÌÒµÒµÎñÂß¼­µÄ

> ºÙºÙ£¬ÕâÊÇIBMµÄ¹Ûµã°É£¨²»ÅųýOracleºÍMicrosoftÒ²·Ç³£Ö§³Ö)
>
>
>
>
> --
> simple is good
> http://brucewang.net _______________________________________________
> python-chinese
> Post: send python-chinese at lists.python.cn
> Subscribe: send subscribe to python-chinese-request at lists.python.cn
> Unsubscribe: send unsubscribe to  python-chinese-request at lists.python.cn
> Detail Info: http://python.cn/mailman/listinfo/python-chinese
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20060710/5e9af109/attachment.htm

On 7/10/06, netkiller <openunix at 163.com> wrote:
>
>  争论来，争论去．这个东东都是外国人提出来的．我们只是被牵着鼻子走．
>

这些都是基本的设计模式和编程方法（自顶向下和自底向上的设计，开发、维护、性能三者的平衡），和任何具体的技术产品没有关系，更扯不上什么"外国人"。IT领域的确是Buzzword满天飞的地方，但绝不是*这些*。

还有一些人帮着外国人喊．另有一些人抄作．目的就是为了赚．一个简单的guest book用j2ee 架构重写一下．就可高新技术．．可以偏＄＄＄了．．
>

技术的使用在于人， 用不正确的方法做事是人的责任。
客观的说，每一种流行的技术背后都有其独到之处，与此同时，任何一种技术都有其应用的范围。
只要能够理解技术背后的思想，就永远不会被技术牵着鼻子走。

；）
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20060710/024cd55e/attachment.html

ÎÒÍæPostgreSQLÓжÎʱ¼ä£¬ºÜÓиãÍ·µÄ£®£»£©ÎÒ¾Íϲ»¶ÄÜÓÃÊý¾Ý×öµÄ£®¾Í²»ÓóÌÐòÀ´Ð´£®
Êý¾ÝºÃά»¤£¬Î¬»¤³ÌÐò»¹µÃ¶Á´úÂ룬·ÖÎöÈ˼Ò˼άÂß¼­£®Ò»¶Ñ°üº¬Îļþ£¬Ò»¶Ñ±äÁ¿£¬ÓÐһЩÊÇÈ«¾ÖµÄ¸ü¿ÉÅ£®Èç¹ûÄã×ö¶þ´Î¿ª·¢£¬ÓöÉÏÕâÑùµÄ³ÌÐò£¬ÄãÃü¿à£®


ÕâÊÇÎÒ¶ÔPostgreSQLµÄÒ»µãС¹©Ï×
http://netkiller.hikz.com/article/postgres/

  ----- Original Message ----- 
  From: Xiao Lei Wu 
  To: python-chinese at lists.python.cn 
  Sent: Monday, July 10, 2006 1:55 PM
  Subject: Re: [python-chinese] [django] Ò»¸öÀÏÎÊÌâ ¹ØÓÚÊý¾Ý´¦Àí


  ºÇºÇ£¬¿´À´ÕâÀïµÄMySQLµÄÐÅͽºÜ¶à¡£
  ºÜ¶àÈ˺ÜÉÙ»òÕß´Ó²»½Ó´¥¡°ÉÌÒµÂß¼­¡±£¬×¢ÒâÎÒÕâÀïËù˵µÄ¡°ÉÌÒµÂß¼­¡±Ö¸µÄÊÇ¡°Âß¼­¡±µÄÀàÐÍ£¬¶ø²»ÊÇÓ¦ÓùæÄ££¬ËùÒÔ¸úʲô¡°ÆóÒµ¼¶¡±Õ´²»Éϱߡ£
  ÎÒÃÇͨ³£ËùÃæ¶ÔµÄÉÌÒµÂß¼­£¬»ù±¾ÉÏÊDzÆÎñ¡¢½øÏú´æ¡¢ÎïÁϹÜÀí¡¢¿Í»§×ÊÔ´¹ÜÀíµÈ£¬°üÀ¨OAÒ²¿ÉËãΪÉÌÒµÂß¼­£¬Ò²¾ÍÊÇÎÒÃÇͨ³£Ëù˵µÄ£¬ERP,SCM,CRMµÈÈí¼þ¡£
  ÔÚ×îΪ¼ò½àÉÌÒµÂß¼­ÖУ¬Ò²ÐèÒª´óÁ¿µÄ×Ó²éѯ¡¢´¥·¢Æ÷¡¢ÁªºÏ²éѯ¡¢¿ä¿âÊÓͼ¡¢Ëø¡¢¹æÔòµÈSQLÌØÐÔ£¬Õâµã´ó¼Ò¿ÉÒԲο¼¿ªÔ´µÄERPʵÏÖCompiere¡£
  µ±È»ÀíÂÛÉϽ²£¬¿ÉÒÔÓñà³Ì´úÌæ×Ó²éѯ¡¢´¥·¢Æ÷µÈ¶«Î÷£¬µ«ÊÇÕâ¸öÄѶÈÊdz¬³öÒ»°ãµÄÉÌÒµ±à³ÌµÄµÈ¼¶ÁË£¬ÒѾ­½Ó½ü¼«ÏÞ±à³ÌÁË¡£
  ËùÒÔ˵£¬²»Ö§³Ö¸ß¼¶SQLÌØÐÔµÄMySQLÖ»²»¹ýÊǸöÍæ¾ß£¬ÎÞ·¨³ÐÔØÉÌÒµÂß¼­£¬Òò´ËÏòCompiereÕâÑùµÄ¿ªÔ´Èí¼þÒ²²»Ñ¡ÔñMySQL£¨Êµ¼ÊÊÇû°ì·¨Ñ¡Ôñ£©¡£¶øCompiereËùʵÏÖµÄÉÌÒµÂß¼­Ò²Ö»²»¹ýÊDZȽϼòµ¥µÄ£¬ÖÐСÆóÒµ¹æÄ£µÄ£¬ËûֻʵÏÖÁ˲»µ½SAP50%µÄÉÌÒµÂß¼­¡£

  Èç¹ûÏëÓÿªÔ´Èí¼þ×öÉÌÒµÊý¾Ý¿âµÄ»°£¬ÍƼöPostgreSQL£¬ËûÖ§³Ö¼¸ºõËùÓеĸ߶ËSQLÌØÐÔ£¬²¢ÇÒÔںܶàÖØÒªÁìÓò£¨±ÈÈçÅ©ÐУ©Óгɹ¦Ó¦Óá£

  ÁíÍ⣬4GLÊǸöÌØÊâµÄ¶«Î÷£¬²»ÒªÓô«Í³µÄSQL˼άÀ´Àí½âËû£¬ÓÐÐËȤµÄÈË¿ÉÒÔÈ¥¿´Ò»Ð©Ïà¹Ø×ÊÁÏ¡£Ôø¾­ÎÒµÄÒ»¸öÉϺ£ÅóÓѾÍÊÇ4GL³ÌÐòÔ±£¬ËûÃÇÒ»¼ÒºÜ´óµĄ̈ÍåÆóÒµËùÓÐÉÌÒµÂß¼­¶¼ÊÇ4GL±àдµÄ£¬Ö»²»¹ýÊÇÓÃC++×öÁËÒ»¸öͼÐÎÇ°¶Ë¡£4GL±àдµÄÓ¦ÓñÈÖ±½ÓÓÃC++µ÷InformixµÄODBCµÄÈ·¿ì2¸öÊýÁ¿¼¶

  Best Regards,

  Zachary Wu (Îâ°~ÀÚ)
  Software Engineer, Enterprise Content Management FVT, IBM China Software Development Lab
  Tel: +86 10 82782244-3235. Fax: 82782244-2886 Tie Line: 915-2244-3235
  Internet: xiaoleiw at cn.ibm.com 
  Notes ID: Xiao Lei Wu/China/Contr/IBM at IBMCN
  Address: 8/F, Block A, Power Creative Building, No.1, East Road, Shang Di, Beijing 100085, P.R. China

  python-chinese-bounces at lists.python.cn дÓÚ 2006-07-10 13:32:25:

  > 

  > On 7/10/06, Xiao Lei Wu <xiaoleiw at cn.ibm.com> wrote:
  > [snip]
  > ÁíÍâMySQLÕâÖÖÍæ¾ß¼¶±ðµÄ¶«Î÷£¬ÊÇÎÞÁ¦³ÐÔØÉÌÒµÒµÎñÂß¼­µÄ

  > ºÙºÙ£¬ÕâÊÇIBMµÄ¹Ûµã°É£¨²»ÅųýOracleºÍMicrosoftÒ²·Ç³£Ö§³Ö)
  > 
  > 
  > 
  > 
  > -- 
  > simple is good
  > http://brucewang.net _______________________________________________
  > python-chinese
  > Post: send python-chinese at lists.python.cn
  > Subscribe: send subscribe to python-chinese-request at lists.python.cn
  > Unsubscribe: send unsubscribe to  python-chinese-request at lists.python.cn
  > Detail Info: http://python.cn/mailman/listinfo/python-chinese



------------------------------------------------------------------------------


  _______________________________________________
  python-chinese
  Post: send python-chinese at lists.python.cn
  Subscribe: send subscribe to python-chinese-request at lists.python.cn
  Unsubscribe: send unsubscribe to  python-chinese-request at lists.python.cn
  Detail Info: http://python.cn/mailman/listinfo/python-chinese
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20060710/b9c0cd37/attachment.htm

国内的软件业就如目前国内医疗广告, 内容基本都是:
我们采用美国激光XXX仪器,德国超声波XXX技术,由X国专家为您XXXX... 
回头再看看国内医疗事故.
  ----- Original Message ----- 
  From: swordsp 
  To: python-chinese at lists.python.cn 
  Sent: Monday, July 10, 2006 2:07 PM
  Subject: Re: [python-chinese] [django] 一个老问题 关于数据处理




  On 7/10/06, netkiller <openunix at 163.com> wrote:
    争论来，争论去．这个东东都是外国人提出来的．我们只是被牵着鼻子走．

  这些都是基本的设计模式和编程方法（自顶向下和自底向上的设计，开发、维护、性能三者的平衡），和任何具体的技术产品没有关系，更扯不上什么"外国人"。IT领域的确是Buzzword满天飞的地方，但绝不是*这些*。



    还有一些人帮着外国人喊．另有一些人抄作．目的就是为了赚．一个简单的guest book用j2ee 架构重写一下．就可高新技术．．可以偏＄＄＄了．．

  技术的使用在于人， 用不正确的方法做事是人的责任。
  客观的说，每一种流行的技术背后都有其独到之处，与此同时，任何一种技术都有其应用的范围。
  只要能够理解技术背后的思想，就永远不会被技术牵着鼻子走。



    ；）




------------------------------------------------------------------------------


  _______________________________________________
  python-chinese
  Post: send python-chinese at lists.python.cn
  Subscribe: send subscribe to python-chinese-request at lists.python.cn
  Unsubscribe: send unsubscribe to  python-chinese-request at lists.python.cn
  Detail Info: http://python.cn/mailman/listinfo/python-chinese
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20060710/23cd6534/attachment.html

On 7/10/06, Xiao Lei Wu <xiaoleiw at cn.ibm.com> wrote:
>
>
>
> 呵呵，看来这里的MySQL的信徒很多。

我不是信徒。

> 很多人很少或者从不接触"商业逻辑"，注意我这里所说的"商业逻辑"指的是"逻辑"的类型，而不是应用规模，所以跟什么"企业级"沾不上边。

如你所说，大部分都接触不到的话，说明你所说的东西只是某一领域的东西，因此并不适合各种场合。而这里并未讨论特殊领域的东西，只是一般的通用设计原理而已。有些偷换概念之嫌。

> 我们通常所面对的商业逻辑，基本上是财务、进销存、物料管理、客户资源管理等，包括OA也可算为商业逻辑，也就是我们通常所说的，ERP,SCM,CRM等软件。
> 在最为简洁商业逻辑中，也需要大量的子查询、触发器、联合查询、夸库视图、锁、规则等SQL特性，这点大家可以参考开源的ERP实现Compiere。

我很奇怪，如果你所说最为简洁的商业逻辑，为什么需要所谓的触发器，联合查询，跨库视图。其它的我认可，但这些有些概念过大了吧。我看最简单的也许可以认为就是进，销，存软件吧。好象foxpro这类的就足以完成，需要很复杂的东西嘛？

> 当然理论上讲，可以用编程代替子查询、触发器等东西，但是这个难度是超出一般的商业编程的等级了，已经接近极限编程了。

子查询我认为并不困难，触发器至少在我的编程生涯中，我目前还没有用过，不知道在什么场合用得上。并不是所有数据库的特性都要用上才叫编程，才叫设计吧。简单能实现为什么不这样做呢？这与极限编程有什么关系，你是想说编程太复杂嘛。那可以不用啊。

> 所以说，不支持高级SQL特性的MySQL只不过是个玩具，无法承载商业逻辑，因此向Compiere这样的开源软件也不选择MySQL（实际是没办法选择）。而Compiere所实现的商业逻辑也只不过是比较简单的，中小企业规模的，他只实现了不到SAP50%的商业逻辑。

如你所说的商业逻辑并没有规定简单的东西就实现不了呀，你的结论似乎是这样推导的：

mysql不支持高级sql特性
商业逻辑没有高级sql特性就无法实现
所以mysql无法承载商业逻辑

商业逻辑与高级sql特性根本没有直接的联系。IBM的大机根本不用关系数据库，它做的商业系统是不是根本不具备商业逻辑呢？

>
> 如果想用开源软件做商业数据库的话，推荐PostgreSQL，他支持几乎所有的高端SQL特性，并且在很多重要领域（比如农行）有成功应用。

前面是商业逻辑，现在是商业数据库。请问商业逻辑与商业数据库是一个概念吗？
>
> 另外，4GL是个特殊的东西，不要用传统的SQL思维来理解他，有兴趣的人可以去看一些相关资料。曾经我的一个上海朋友就是4GL程序员，他们一家很大的台湾企业所有商业逻辑都是4GL编写的，只不过是用C++做了一个图形前端。4GL编写的应用比直接用C++调Informix的ODBC的确快2个数量级
>
兄弟的概念罗列太多，能不能围绕主题，说得简单清楚些。

-- 
I like python!
My Blog: http://www.donews.net/limodou
My Django Site: http://www.djangocn.org
NewEdit Maillist: http://groups.google.com/group/NewEdit

这些是"business people"们要关心的事情，与开发者又有什么关系呢？
让上帝的归上帝，凯撒的归凯撒，做技术的自己有清醒的认识就可以了。

On 7/10/06, netkiller <openunix at 163.com> wrote:
>
>  国内的软件业就如目前国内医疗广告, 内容基本都是:
> 我们采用美国激光XXX仪器,德国超声波XXX技术,由X国专家为您XXXX...
> 回头再看看国内医疗事故.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20060710/fb2dcee9/attachment.htm

On 7/10/06, netkiller <openunix at 163.com> wrote:
>
> 国内的软件业就如目前国内医疗广告, 内容基本都是:
> 我们采用美国激光XXX仪器,德国超声波XXX技术,由X国专家为您XXXX...
> 回头再看看国内医疗事故.
>

还是多谈些开源软件吧。商业软件，特别是外包项目以挣钱为目的，就没必要再提了。但我感觉差距大的原因还是技术创新和技术积累上太欠缺了。别人是一个项目做几年，而我们是一年做几个项目，能做到积累的太少了。开源软件多少好些。

-- 
I like python!
My Blog: http://www.donews.net/limodou
My Django Site: http://www.djangocn.org
NewEdit Maillist: http://groups.google.com/group/NewEdit

ºÜ²»ÐÒÎÒ¾ÍÔø¾­Óöµ½¹ýÕâÑùµÄ¶þ´Î¿ª·¢¡­¡­
ÄǸöFramework±»ÎÒÃǾ­Àí³ÆΪ¡°Rubbish Oen¡±£¨ËüÔ­Ãû½Ð¡°Resource One¡±£©

Best Regards,

Zachary Wu (Îâ°~ÀÚ)
Software Engineer, Enterprise Content Management FVT, IBM China Software
Development Lab
Tel: +86 10 82782244-3235. Fax: 82782244-2886 Tie Line: 915-2244-3235
Internet: xiaoleiw at cn.ibm.com
Notes ID: Xiao Lei Wu/China/Contr/IBM at IBMCN
Address: 8/F, Block A, Power Creative Building, No.1, East Road, Shang Di,
Beijing 100085, P.R. China

python-chinese-bounces at lists.python.cn дÓÚ 2006-07-10 14:08:04:

> ÎÒÍæPostgreSQLÓжÎʱ¼ä£¬ºÜÓиãÍ·µÄ£®£»£©ÎÒ¾Íϲ»¶ÄÜÓÃÊý¾Ý×öµÄ£®¾Í²»ÓóÌÐò
À´Ð´£®
> Êý¾ÝºÃά»¤£¬Î¬»¤³ÌÐò»¹µÃ¶Á´úÂ룬·ÖÎöÈ˼Ò˼άÂß¼­£®Ò»¶Ñ°üº¬Îļþ£¬Ò»¶Ñ
> ±äÁ¿£¬ÓÐһЩÊÇÈ«¾ÖµÄ¸ü¿ÉÅ£®Èç¹ûÄã×ö¶þ´Î¿ª·¢£¬ÓöÉÏÕâÑùµÄ³ÌÐò£¬ÄãÃü¿à£®
>
>
> ÕâÊÇÎÒ¶ÔPostgreSQLµÄÒ»µãС¹©Ï×
> http://netkiller.hikz.com/article/postgres/
>
> ----- Original Message -----
> From: Xiao Lei Wu
> To: python-chinese at lists.python.cn
> Sent: Monday, July 10, 2006 1:55 PM
> Subject: Re: [python-chinese] [django] Ò»¸öÀÏÎÊÌâ ¹ØÓÚÊý¾Ý´¦Àí
>
> ºÇºÇ£¬¿´À´ÕâÀïµÄMySQLµÄÐÅͽºÜ¶à¡£
> ºÜ¶àÈ˺ÜÉÙ»òÕß´Ó²»½Ó´¥¡°ÉÌÒµÂß¼­¡±£¬×¢ÒâÎÒÕâÀïËù˵µÄ¡°ÉÌÒµÂß¼­¡±Ö¸µÄÊÇ¡°Âß
> ¼­¡±µÄÀàÐÍ£¬¶ø²»ÊÇÓ¦ÓùæÄ££¬ËùÒÔ¸úʲô¡°ÆóÒµ¼¶¡±Õ´²»Éϱߡ£
> ÎÒÃÇͨ³£ËùÃæ¶ÔµÄÉÌÒµÂß¼­£¬»ù±¾ÉÏÊDzÆÎñ¡¢½øÏú´æ¡¢ÎïÁϹÜÀí¡¢¿Í»§×ÊÔ´¹Ü
> ÀíµÈ£¬°üÀ¨OAÒ²¿ÉËãΪÉÌÒµÂß¼­£¬Ò²¾ÍÊÇÎÒÃÇͨ³£Ëù˵µÄ£¬ERP,SCM,CRMµÈÈí¼þ¡£
> ÔÚ×îΪ¼ò½àÉÌÒµÂß¼­ÖУ¬Ò²ÐèÒª´óÁ¿µÄ×Ó²éѯ¡¢´¥·¢Æ÷¡¢ÁªºÏ²éѯ¡¢¿ä¿âÊÓ
> ͼ¡¢Ëø¡¢¹æÔòµÈSQLÌØÐÔ£¬Õâµã´ó¼Ò¿ÉÒԲο¼¿ªÔ´µÄERPʵÏÖCompiere¡£
> µ±È»ÀíÂÛÉϽ²£¬¿ÉÒÔÓñà³Ì´úÌæ×Ó²éѯ¡¢´¥·¢Æ÷µÈ¶«Î÷£¬µ«ÊÇÕâ¸öÄѶÈÊdz¬³ö
> Ò»°ãµÄÉÌÒµ±à³ÌµÄµÈ¼¶ÁË£¬ÒѾ­½Ó½ü¼«ÏÞ±à³ÌÁË¡£
> ËùÒÔ˵£¬²»Ö§³Ö¸ß¼¶SQLÌØÐÔµÄMySQLÖ»²»¹ýÊǸöÍæ¾ß£¬ÎÞ·¨³ÐÔØÉÌÒµÂß¼­£¬Òò
> ´ËÏòCompiereÕâÑùµÄ¿ªÔ´Èí¼þÒ²²»Ñ¡ÔñMySQL£¨Êµ¼ÊÊÇû°ì·¨Ñ¡Ôñ£©¡£¶ø
> CompiereËùʵÏÖµÄÉÌÒµÂß¼­Ò²Ö»²»¹ýÊDZȽϼòµ¥µÄ£¬ÖÐСÆóÒµ¹æÄ£µÄ£¬Ëûֻʵ
> ÏÖÁ˲»µ½SAP50%µÄÉÌÒµÂß¼­¡£
>
> Èç¹ûÏëÓÿªÔ´Èí¼þ×öÉÌÒµÊý¾Ý¿âµÄ»°£¬ÍƼöPostgreSQL£¬ËûÖ§³Ö¼¸ºõËùÓеĸß
> ¶ËSQLÌØÐÔ£¬²¢ÇÒÔںܶàÖØÒªÁìÓò£¨±ÈÈçÅ©ÐУ©Óгɹ¦Ó¦Óá£
>
> ÁíÍ⣬4GLÊǸöÌØÊâµÄ¶«Î÷£¬²»ÒªÓô«Í³µÄSQL˼άÀ´Àí½âËû£¬ÓÐÐËȤµÄÈË¿ÉÒÔ
> È¥¿´Ò»Ð©Ïà¹Ø×ÊÁÏ¡£Ôø¾­ÎÒµÄÒ»¸öÉϺ£ÅóÓѾÍÊÇ4GL³ÌÐòÔ±£¬ËûÃÇÒ»¼ÒºÜ´óµÄ
> ̨ÍåÆóÒµËùÓÐÉÌÒµÂß¼­¶¼ÊÇ4GL±àдµÄ£¬Ö»²»¹ýÊÇÓÃC++×öÁËÒ»¸öͼÐÎÇ°¶Ë¡£
> 4GL±àдµÄÓ¦ÓñÈÖ±½ÓÓÃC++µ÷InformixµÄODBCµÄÈ·¿ì2¸öÊýÁ¿¼¶
>
> Best Regards,
>
> Zachary Wu (Îâ°~ÀÚ)
> Software Engineer, Enterprise Content Management FVT, IBM China
> Software Development Lab
> Tel: +86 10 82782244-3235. Fax: 82782244-2886 Tie Line: 915-2244-3235
> Internet: xiaoleiw at cn.ibm.com
> Notes ID: Xiao Lei Wu/China/Contr/IBM at IBMCN
> Address: 8/F, Block A, Power Creative Building, No.1, East Road,
> Shang Di, Beijing 100085, P.R. China
>
> python-chinese-bounces at lists.python.cn дÓÚ 2006-07-10 13:32:25:
>
> >
>
> > On 7/10/06, Xiao Lei Wu <xiaoleiw at cn.ibm.com> wrote:
> > [snip]
> > ÁíÍâMySQLÕâÖÖÍæ¾ß¼¶±ðµÄ¶«Î÷£¬ÊÇÎÞÁ¦³ÐÔØÉÌÒµÒµÎñÂß¼­µÄ
>
> > ºÙºÙ£¬ÕâÊÇIBMµÄ¹Ûµã°É£¨²»ÅųýOracleºÍMicrosoftÒ²·Ç³£Ö§³Ö)
> >
> >
> >
> >
> > --
> > simple is good
> > http://brucewang.net _______________________________________________
> > python-chinese
> > Post: send python-chinese at lists.python.cn
> > Subscribe: send subscribe to python-chinese-request at lists.python.cn
> > Unsubscribe: send unsubscribe to
python-chinese-request at lists.python.cn
> > Detail Info: http://python.cn/mailman/listinfo/python-chinese
>
> _______________________________________________
> pyt_______________________________________________
> python-chinese
> Post: send python-chinese at lists.python.cn
> Subscribe: send subscribe to python-chinese-request at lists.python.cn
> Unsubscribe: send unsubscribe to  python-chinese-request at lists.python.cn
> Detail Info: http://python.cn/mailman/listinfo/python-chinese
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20060710/5f240e00/attachment.html