Duwamish7的郁闷

看了半天，在它的Sql Server 中只找到了用户表和存储过程，它居然没有用到视图和关系，呵呵，诡异，微软也这样玩数据库么？
　　Customers表可谓是简单了，只用了Name，Email，Password三个字段，还有一个字段PKID是标识列，递增种子为1。
     Customers与Orders表中的关系是PKId和CustomerID，而Address表也是从夹在Customers与Order表间的，它们之间的关系也是用的CustomerID作一个外键进行过渡。
　类似的情况还有很多，但..........
     数据库中不是没定义关系吗？这些关系从哪儿来的哟？

    在存储过程中，定义的过程中居然是GetBooksByTitle，GetBooksBySubject，GetCustomerById之类的，有必要吗？
    越看越觉复杂，这样做，如果以后要迁移数据库，岂不很麻烦？

     说说自己的感觉，不知道这个东东是Microsoft中的哪个家伙完成的，有一种猜测：可能是微软逼得太急了，要这个家伙赶紧写出一个可以体现.net框架的示例代码，结果这位老牛人，不知怎么想的，跑去借鉴了一下J2EE平台上的系统架构，然后也不管写得复不复杂，就往外丢了..........
    业务实体层把每一个业务都敲了一遍了，这到没什么大不了，可问题是，全部是调用的数据的库存储过程，也太颠覆了吧？
　更牛的是建立对应数据库中表的N多个类，天呐，要是我有20张表，几百个业务怎么办，学您的风格，光是一行一行地搞，不知要搞到哪辈子去哦。
　　微软的vs.net中的DataSet数据集对应的构架文件xlst，在这个示例中居然不用，微软呐，微软，你要我们怎么学习你的技术呐？

　　我觉得要是在实际中，充分利用一下Vs.net中的数据适配器来建立数据集文件，应该要简单得多了。在Duwamish中，数据集都是无构架模式的，不知道这样做究竟有何好处？
　　在C/S模式下，如此作法，可以分散系统初始化的时间，减小用户的等待，而在B/S模式下，如此作法，只能是让用户每一次调用时，不断地再次动态构造数据集，这样岂不更浪费时间？
　　除非，在代码中，生成的数据集，能够一次性固定下来，但估计不可能，白痴都知道dll是在内存中执行的。
　　难以理解，而且也没找到相关的说法，晕

       再胡乱猜测一点：Duwamish本就是一个C/S的高手被强迫用B/S来写代码的话，好像一切都明白了，呵。
　　大家不用丢鸡蛋，只是研究了半天，越研究越胡涂，我发表一点微不足道的看法而已。