最近在帮学校做一个问卷调查系统，目前存储问卷以及问卷结果是这样的：
每新增一份问卷，数据库增加两个表，其中一个表用来存放这份问卷的信息，另一个表用来存放问卷结果信息
之前没怎么接触过数据库，在做这个系统之前查了一些关于数据库的资料，看到有人说
表的数量多不会影响查询速度，反而可能会因为你的数据存储结构更加有条理了而是查询更高效
在这个系统运行了一段时间之后，我感觉上面这种说法好像不太靠谱，现在正在准备重新设计数据库的结构。在此之前我想问一下各位熟悉数据库的前辈：数据库表的数量像我刚刚描述的那样动态增加会有什么弊端？数据库的结构设计一般遵循什么样的规则？
20140530 17:10 新增
感谢各位的回答，大家的回答算是解答了我的疑惑，另外我想说明一下，我这个问题主要不是问我这个数据库该怎么设计，而是侧重于数据表太多会有什么样的结果。
再次感谢各位的回答啦 :P
得看你具体采用的引擎。
mysql innodb的话，如果不做额外设置，表是在一个空间里面的，不存在文件系统的限制。但innodb会将表和分区信息记录在内存，且不主动释放，如果表太多有可能耗尽内存（估计得有几百万张表了）。
其他引擎，如果是表独立建文件存放的话，那就受操作系统文件限制了
一份问卷数据库便生成2个表设计似乎有问题，除非是非常特殊的需求，正常的问卷调查数据库一般是这样设计的：
1、user(用户表)
id,uesrname,password,email
2、questionnaire(问卷表，用来记录问卷属性，例如标题、介绍、开始和截至日期等)
id,title,intro,type,start_date,end_date,create_date,update_date
3、question(问卷下设的问题表)
id,questionnaire_id(所属问卷),type(类型，比如是单选还是复选，还是其他输入等)
4、option(选项表，用来保存每个问题的可选项)
id,question_id(所属问题),label(标签),value(值)
5、vote(投票结果，用来保存每个用户选择的结果)
id,question_id(对于的问题),user_id,option_id(用户最终选择的选项)
最终是5～6个表之间。
别超过几百个表从性能上来说问题不大——个人浅见，无依据。
但是，如果你的每个表都只有几行数据，或者数据量不会增加的话，这种设计是对数据库表的误用，可以参考下面的方式优化：
- 建立问卷表和和结果表，这样总共就只有 2 个表了。
- 用 json/xml 或其他类似格式存储问卷和结果，因为不同问卷之间结构大多不同，用不到数据库表的查询特性
参考：
- 一个数据库中20万个表时mysql表现会怎么样？
- MySQL 中一个库中表数量是否有限制？表太多是否影响数据的性能？比如要把一张表拆成 1024 张，对于每个表的性能的影响是什么？这些影响需要考虑哪些因素？
网上还有很多讨论，可以自己去看。
总体来说，表太多了，一是文件系统效率会降低，二是维护难度增加。
建议你根据实际需求情况，如果一天最多一个调查，那么无论哪种方案都是能够承受的。
针对楼主这种业务场景，为什么不把问卷做成文件，在库表中去记录文件文件信息岂不是更方便？
我不是很清楚，为什么你要把每个问卷都拆成两个表，我想可能是你没有理解表和行的概念。一份数据，注意是一份，放在数据库中也不过就是一行，比较复杂的数据结构，放在数据库中，也无非就是多个关联表中的多行而已，完全没有必要为一份数据新建一个表。而且，数据库表多少本身影响不大，主要是在程序中操作的时候，比较麻烦，可以说，本来应该在表中用语句查询的问卷，你放到了程序中用代码查询，完全没有利用查询语句。
我们之前做了一个设计，是把用户数据按id取模，拆分到100个表中，后期处理的时候实在是非常麻烦。后来才明白，其实几十万几百万条数据，根本用不到拆那么多的表，一般的中小型系统都达不到mysql的瓶颈，很多时候是想太多了
表基本上遵循我们常说的几个范式，但是不能一味的去遵循这个东西，因为从实际的实际来说，这些范式有时候反而会成为累赘！但是，也不是说不遵循，就是说我们在满足自己需求和保证系统性能的情况下，尽量去满足范式，毕竟前任总结的东西存在这么久，有其可取之处！
其次，数据库的表并非越多越好，在某种层面上说，表多确实反映了你数据库分的够细致，但是从你查询的层面上来说，你在查询的时候相应也就慢了，而且可能由于你的疏忽，产生很多的脏数据，但是如果为了保证数据的完整性，关联好像是好的选择，但是可以明确说，表的关联很影响数据库的性能，所以根据自己的要求，选取适合的才是最好的！……拙见勿喷！