不多说,上代码
<asp:ObjectDataSource ID="ObjectDataSource1" runat="server" 
                        SelectMethod="GetAllType" TypeName="BLL.MuTypeManage"></asp:ObjectDataSource>
                    <asp:Repeater ID="Repeater1" DataSourceID="ObjectDataSource1" runat="server">
                        <ItemTemplate>
                            <asp:CheckBox ID="CheckBox1" Text='<%#Eval("Name") %>' runat="server" />
                        </ItemTemplate>
                    </asp:Repeater>问题如下:
1.在添加商品的时候,让这个商品有多种套餐,每种套餐的价格不同,数据库是用了一个关系表连接套餐类型表和商品表,关系表里有字段price,请问这样搞数据库对吗?如果不对,有什么更好的解决方法?
2.如果按照以上数据库设计,在添加button的click事件里,怎么判断选择了哪些套餐,从而获得实例插入数据库

解决方案 »

  1.   

    “不多说,上代码”这种在博客园经常看到的语句,我其实访问博客园时大多数时候都感到反感。真正的设计师,会把80%以上的篇幅用来描述自己的设计思路,而不是用贴一堆代码或者屏幕拷贝来赚取版面。回到你的问题。“数据库是用了一个关系表连接套餐类型表和商品表,关系表里有字段price”这种话,实在是太含糊了。
      

  2.   


    这是数据库关系,因为一个MuProduct要有多个类型,类型的价格也不一样,所以这样设计对不对?
    然后页面中的是用repeater列出这些类型的,因为是要选这个产品有哪些套餐,就用了checkbox,怎么在后台获取都选择了哪些,然后得到类型的实例?
      

  3.   

    假设我们抛开你的设计(假设认为你的设计毫无用处),重新描述一下,可能是这样的:  套餐: {
              品名: "梅菜扣肉套餐",
              价格: 13.5,
              商品明细:
                  [
                       {品名:"米饭", 数量:1, 单位:"小碗"},
                       {品名:"扣肉", 数量:4, 单位:"小片"},
                       {品名:"鸡蛋汤", 数量:1, 单位:"小碗"}
                 ]
            }或者如果你用比较散乱的关系数据库,那么就是有一个“套餐”表,一个“套餐商品明细”表,并且套餐商品明细中的品名关联到具体的商品。对于软件设计师,他应该学会使用UML图来画出这种关系。至于说“对不对”,我对这种问题不置可否。这个世界上没有永远对、而不会被重构的设计,但是一切都要尊重市场需求而不是瞎折腾。只要是在最近3~4个月内足够用,就是对的。如果明明承认3个月内不找事,结果不到3个月就要求你修改需求了,那么责任不在你而在于老板的朝令夕改,他自己会承担责任。因此你所谓的“这样的数据库设计对不对?”的问题,其实很容易判断的,只要你主动跟人沟通就好了。实践会告诉你“对还是错”的。
    至于第二个问题,那么销售明细可以分为三种,例如
        
       销售记录: {
              流水号:"丽丽201305X0011",
              桌号:"A12",
              时间:#2013/5/30 19:59#,
              金额: 412.5,
              付款明细:
                 [
                    {  方式:"现金", 金额:120 },
                    {  方式:"刷卡", 金额:300, 卡号:"652082374724384823482342", 发卡行:"农行", 银行扣手续费: 2.5}
                 ],
              消费明细:
                [
                    {  商品:"大龙虾": 数量: 2.1234, 单位:"kg", 金额: 699.5, 类型:"普通商品"},
                    {  商品:"梅菜扣肉套餐": 数量: 1, 单位:"份", 金额: 13.5, 类型:"套餐" },
                    {  商品:"年费客户优惠券", 数量:1, 单位:"张", 金额:-300, 类型:"礼券", 号码:"123", 有效期:2013/10/1},
                ],
              发票:{ 金额: 412.5, 发票号:"8238238232323", 单位:"xxxxx软件技术有限公司" }
              }在UML或者使用c#而写的代码的设计中,“消费明细”实际上可能只是一个abstract的类型,它具有三种扩展子类型,分别是“普通商品消费明细、套餐消费明细、礼券消费明细”。但是有些人只会写点关系数据库程序,不会NoSQL编程,或者不知道如何将编程中的“继承、子类”与关系数据库表对应起来,那么遇到你这种问题可能就产生比较诡异的设计了。使用关系数据库来表示对象的继承,确实是没有什么标准的形式。这里,你可以在“消费明细”关系数据库表中定义字段“销售流水号,明细行号,商品,金额,类型”这5个字段,然后在“礼券商品消费明细”关系数据库表中定义字段“销售流水号,明细行号,号码,有效期”等礼券商品消费明细中特别要扩展记录的、进行礼券管理关注字段。其它的消费明细,如果需要扩展也可以定义,例如可以定义“普通商品消费明细”表具有字段“销售流水号、明细行号、进货来源、出库分量(经过加工肯定有损失)”等,对于“套餐商品消费明细”表则扩展的字段可能有“销售流水号,销售明细行号,加工工序编号,加工时间,销售时间”等等进行套餐管理关注的信息。这里强调的是,要懂也,不要用程序员的脑袋去做随便想象人家的业务需求,也不要以为用户能直截了当地告诉你多少业务知识,需要你自己去用智慧去深入到业务实践中去发现业务领域的设计知识。
      

  4.   

    首先我的感谢lz的问题,让我们看到sp1234大大精彩的回复剩下的话我就不说,再说就有狗尾的嫌疑了,lz好好领会,真能从sp1234大大这学上一点,保证你能往前跨一大步