帮助处理表关系
我需要一些帮助来设计一个酒吧用于饮料的数据库。我的应用程序以两种方式处理饮料订单：客户可以订购饮料并立即付款，或者他们可以启动一个选项卡。到目前为止，这是我的餐桌关系：
Table Order: Table Tabs:
------------ ------------
[PK] OrderId - 1 [PK] TabId
ItemName / TabName
QtyOrdered / Total
TabId *- PaymentType
Archive
它的设置是 1 个选项卡上可以有很多饮料。这对于选项卡来说非常有用，但客户可以选择不设置选项卡。我的问题是，我如何修改这两个表来支持这一点？或者我必须创建一个新表？
提前致谢。
I need a little help designing a database that a bar would use for drinks. My app handles drink orders in 2 ways: A customer can order drinks and pay right away, or they can start a tab. This is my table relationship so far:
Table Order: Table Tabs:
------------ ------------
[PK] OrderId - 1 [PK] TabId
ItemName / TabName
QtyOrdered / Total
TabId *- PaymentType
Archive
Its setup so 1 tab can have many drinks on it. Thats great for tabs, but customers can choose not to setup a tab. My question is, how can i modify these two tables to support that? Or do I have to create a new table?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您的“项目”是订单行项目。
该订单上有三个（编辑：项目，但两个）行项目。要将它们识别为同一订单的一部分[如果您需要这样做]，您将需要两个表：
并且
如果您不需要将饮料识别为属于同一订单，则可以放弃两表结构，但是每个订单只能喝一种饮料。
延长价格是多少 * 订购时饮料的价格。您将此值存储在订单表中，以便您可以更改 DRINKS 表中饮料的价格，而不会影响所欠的标签金额（如果标签生命周期长于一天 - 即客户可以运行每月或每季度标签） 。
HowMany 可以默认为 1。饮料行项目所欠的金额为（扩展价格 - 所应用的付款金额）。 PaymentAmountApplied 默认为 0（即默认运行选项卡）。
如果您不需要跟踪所订购的饮料种类（即，您不介意使用数据库来发现，出于某种原因，周二晚上您售出的杜松子酒和滋补品比吉尼斯啤酒多得多）：
您的酒保只需输入系统外部计算的订单总金额，而不参考数据库中的饮料表——也许酒保会看墙上的黑板。
Your "item" is the order line-item.
There are three (EDIT: items, but two) line-items on that order. To identify them as part of the same order [if you should need to do so], you would need two tables:
and
If you do not need to identify the drinks as belonging to the same order, you could abandon the two-table structure, but then you could have only one kind of drink per order.
Extended price is howmany * the drink's price at time of the order. You store this value in your order table so you can change the price of the drink in the DRINKS table without affecting the tab amount owed (in case the tab lifetime is longer than a day -- i.e. customers can run a monthly or quarterly tab).
HowMany can default to 1. The amount owed on a drink line-item is (extendedprice - paymentamountapplied). PaymentAmountApplied defaults to 0 (i.e. default is to run a tab).
If you do not need to track the kind of drink being ordered (i.e. you don't care to use your database to discover that on Tuesday nights you sell a lot more gins-and-tonic than Guinesses, for some reason):
Your barkeep would simply enter the total amount of the order, calculated outside your system, without reference to a DRINKS table in the database -- maybe the barkeep would look at a chalkboard on the wall.
您需要一个 CUSTOMERS 表、一个 DRINKS 表、一个 ORDERSHEADER 表、一个 ORDERDETAIL 表（选项卡上的每种饮料都是一个行项目）。您可以/应该有一个单独的付款表。您可以将付款分配给 ORDERDETAIL（您的选项卡）的行项目。 “选项卡”是订单上未应用付款的所有行项目的集合。
You need a CUSTOMERS table, a DRINKS table, an ORDERSHEADER table, an ORDERDETAIL table (each drink on the tab is a line-item). You could/should have a separate PAYMENTS table. And you would allocate payments to the line-items of the ORDERDETAIL (your tab). The "tab" is the set of all line-items on the order(s) that have no payment applied to them.