是这样的：这a1~a50子段是平级字段，要是拆的话，可能拆成50个表才最合适，我本来是想把那个a1~a50做成一个字段，用blob (;相隔explode)，可是对于我后面的运算很不利，我想在数据库服务器就能返回查询的结果，尽量不在应用程序做.......我这么考虑您看对不对（我对数据库原理没怎么研究过）
select a1 from chengji where id='$myid'首先数据库先指向我所制定的表格的字段，然后分析条件，最后生成记录集，也就是说查询只是跟
记录数量的绝对数有关系呀（列数），字段的数量（行数）影响应该不是很大吧？建立一个表格的时候是不是应该选择功能比较单一，功能最简单为宜？比如
表1：学生name 字段：id name
表2：学生成绩 字段：id fenshu
表3: 学生排名 字段：id paiming肖地对数据库的设计很感兴趣，希望高手指点再谢
select a1 from chengji where id='$myid'首先数据库先指向我所制定的表格的字段，然后分析条件，最后生成记录集，也就是说查询只是跟
记录数量的绝对数有关系呀（列数），字段的数量（行数）影响应该不是很大吧？建立一个表格的时候是不是应该选择功能比较单一，功能最简单为宜？比如
表1：学生name 字段：id name
表2：学生成绩 字段：id fenshu
表3: 学生排名 字段：id paiming肖地对数据库的设计很感兴趣，希望高手指点再谢
解决方案 »
- PHP中出现无法加载mysql(外链，英语)扩展,请检查您的 PHP 配置是什么错误？
- 想要用php链接sqlite保存网页信息
- 如何实现同一台mysql服务器中不同数据库之间的数据同步？
- 这个js调用方法怎么看啊?看糊涂了
- 請問要如何得知是某IP來源是spider進行訪問呢?
- 500 Internal Server Error
- MYSQL的一个简单问题
- PHP初学者，在线求高手解决，20分相送！！！
- 为什么我插入或更新完数据都要刷新一次才能看到新数据呢
- php 模糊查询2个表的数据 sql语句怎么写
- ASP.NET推出了，到底是ASP有前途还是PHP有前途？为什么现在公司都要PHP设计员，不要ASP设计员？
- 请帮我看看这个小算法，急呀
呵呵 多悲哀，教教小弟吧
然后每个人拿到自己的模块，比如说我拿到一论坛形式的内部交流，我就开始想，一BBS，他有主题文章，有回复文章，是不是应该分开保存，还是在同一个表中用一个字段来区分……文章，它有唯一标志，恩，一个字段，ID int(11) PRIMARY KEY；它有标题，恩，又一个字段，Title varchar(64)；还有作者、正文、发表时间、人气值……等等，这样把库结构就定下来了。然后我就动手开始写代码。一BBS，一进来应该看到一个主题列表，于是乎我就开始mysql_connect()、$sql="...."、mysql_qurey($sql)、for ($i=0;$i<mysql_num_rows($res);$i++)……好了，index.php就出来了，然后点每个标题，一click.php页面，然后我又mysql_connect()、$sql="...."、……这样周而复始，一内部交流就算出来了。对吧~~~现在很多人的开发过程与此大致相仿~~~但是这种方法合理吗？这样的代码健壮吗？答案是否定的。要先说的是，现在已经面向对象的时代了，为什么还要做这样的开发呢？有没有想过，实际上很多代码都是可以重用的，这就是一个可重用性的问题。为什么不写一个数据库接口类呢？每个需要操作数据库的页面，只需要将这个类的inc文件require进来，再构造一个实例，直接使用它提供的方法就行了。用过Delphi或者VB的人一定很清楚这样的过程，往窗体上拖一个组件，（相当于php中的构造出一个实例）然后再使用这个组件（实例）提供的属性和方法。如果哪一天客户的要求变了，我不这样操作数据库，我要那样操作数据库，这个说法也许不好理解，这样说吧，如果哪天客户的MySQL终于在重压之下崩掉了，他们的DBA建议将数据库换成MSSQL或者Oracle，你想想你写的这个内部交流要做多少改动才能恢复使用？是不是要将每个页面翻出来，一旦发现有什么mysql_query之类的mysql函数，统统改掉，再找……麻烦吗？要是最早就是一接口类，要改库吗？改你的吧，我就把接口类的文件翻出来，把里面的方法逐一改掉，其它的页面再多再少，动也不用动它们，整个系统就又复活了~~:)当然，以上提到的数据库类只是一个控制类，只有抽象上的意义，因为你说不出来它的实例在现实中到底是个什么东西。但是，在现实中可以说明是什么的呢？比如上例中提到的文章，为什么不同样把它封装成一个描述类呢，它有自己的成员属性：标题、作者……有自己的成员方法：GetTitle()、SetTitle()……GetArticleInfoByID()、GetArticleByUserID()等等，跟以上说的一样，客户要改就改他的，我只需要更改我的Article类，就可以了，页面上基本都不用管。这样的描述类分析好了，再由类属性，来定库表结构，再具体实现类的操作。好了，也就是说，一个项目拿下来，先做类分析（当然是需求已定的情况下），再做库表设计，再局部实现类操作，再做系统装配……后面就是页面装配啊，组合测试啊之类之类的了~~:)这样做，也许看上去很麻烦，或者说一时半会接受不了。但是从系统的可变性、可扩展性和可重用性（OOP的三大原则）来考虑，还是推荐大家都慢慢接受这样的方式，或者说尝试一下，自己切身感受一下~~相信会很有感触哦~~:)
:)