作为学习一些数据库设计技巧的练习，我正在为虚构的小型电脑商店设计一个数据库。这个想法是，商店从多个供应商处获得一些组件，将它们组装到计算机系统中并将它们出售给客户。小型电脑商店的数据库设计，寻求建议
这里的模型，我拿出这么远的图像： Image
几点说明：
这种模式的核心实体是项目。它代表了该店所拥有或销售的单个项目，例如一个精确的i7 920处理器。此商品属于属于类别（“处理器”）的产品（本例中为“Intel i7 920”）。
这些商品通过订单进入商店。当从供应商订购组件时，会创建订单表中的新条目。对于每个订购的商品，都会创建Items表中的新条目，并在OrderItem中创建相应条目（我无法为此表提供更好的名称......）。
OrderItem条目基本上包含商店在供应商发票上收到的内容：商品成本的价格，相同的描述等。如果必须显示或打印订单，订单字段确定商品出现的顺序。
另一方面，当客户购买东西时，创建了发票。他们购买的每件商品都会创建一个InvoiceItem。它基本上和OrderItem一样。价格区域是客户将支付的价格（让我们假设价格不是每个产品的价格，而是针对每个发票定制的，我无法找到具有每种产品价格并能够跟踪价格变化的优雅方式） 。如果说明为空，则相应产品的说明显示在发票上，否则，可以输入该发票的自定义说明。
现在棘手的部分是组件表。如果商店销售称为“PC 1”的PC系统，则产品中将存在“PC 1”条目，例如属于“PC”类别。每次组装“PC 1”系统时，都会创建一个新项目（productID为“PC 1”），并且对于该系统的每个组件，会向组件添加条目：assemblyID将是新项目的itemID ，componentID是组件的itemID。
我只是想到了没有Assemblies表的另一种管理方式：商店可以向0虚构的客户“卖”零部件（实际上0 CHF），并从虚构的供应商那里“购买”组装好的计算机（再次，免费）。这似乎更容易做到，因为组件会从库存中消失，但是否有一种将“已售出”组件与“已购买”计算机关联的简单方法？
现在，我对我从中学到的东西很满意。但肯定有一些错误或一些更好的方式来表达我无法想到的事情。我很高兴收到任何建议和批评。提前致谢！
PS：对不起，如果文本有点长...还有，对于一些糟糕的英语情况感到抱歉（这不是我的主要语言（这也可以解释一些选择不好的字段/表名称（为此我会更多比较乐意获得建议）））