下单系统和多桌输入
我正在做这个项目，它基本上是使用 PHP/MySQL（codeigniter 框架）的 ERP 中的几个模块。
我不确定应该如何集成订单放置机制（和其他多表相关）功能。 例如。客户的订单由两个 MySQL 表（Order 和 Order-Detail）管理。 订单表存储一般订单信息，而订单详细信息存储订购的产品信息（数量等），因为一个订单可以订购多个产品。
所以，我的问题是：
这个东西基本上是如何实现的（背后的逻辑）？
它在行业术语中是如何称呼的（这样我就可以在 google 上搜索现成的 JavaScript/AJAX 或 PHP 库或片段）？
I am doing this project, which is basically few modules from an ERP using PHP/MySQL (codeigniter framework).
I'm not sure how should I integrate the Order Placing mechanism (and other multi table dependent) features.
Eg. Customer's Order is managed by two MySQL tables, (Order and Order-Detail).
Order tables stores general order information, while Order-Detail stores ordered product information (quantity etc.), since an order can have more than one product ordered.
So, my questions are:
How is this thing basically implemented (the logic behind it)?
How it is called in the industry jargon (so I can google for ready JavaScript/AJAX or PHP libraries or snipets)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这个术语是关系数据库。
您可以使用 mysql 本身使用“innoDB”驱动表来构建关系数据库。
其背后的逻辑如下（在您的情况下）
您有 3 个表：
- 用户（包含用户 ID、用户名、用户密码等）
- 已下订单（带有 orderid、userid、productid）
- 订单详细信息（包含订单 ID、产品 ID、订单日期、金额等）
- 产品（带有productid、productname、productweith等）
这里所有的'...id'名称都是主键
对于用户来说，主id是userid
对于已放置订单，主要 ID 是 orderid
但
有些表还有另一个“..id”，它是另一个表的主 ID。
就像 PlacedOrders 表中的 userid 是用户的主要 ID
这些 id 称为foreignID。
这些foreignID 相互链接。
其背后的逻辑是，对于放置订单表，您不必包含用户名或密码之类的内容。
当您拥有大量数据时，这可以防止冗余并可以提高数据库效率。
关于如何在网站中使用它的更多提示：
用户首先使用表 users 中的数据登录。
然后他转到产品页面并选择产品和他想要订购的数量。
现在下订单时，订单将在 orderdetails 内进行
所有变量（orderid、productid 和 userid）都将合并到 PlacedOrders 中，
现在对于用户来说这并不是一个改进。
但对你（或商店）来说就是这样。
通过这种方式，您可以使用 placeorders 表中的数据来查看谁订购了什么。通过
这种方式，您可以创建一个（搜索）页面，只需单击一下即可查看用户的数据、产品详细信息和订单详细信息。
现在，通过一些方便的脚本，您可以轻松地从产品、用户和订单中获取适当的数据，并将这些数据放在一页上，而无需将所有内容都放在一个大而混乱的数据库中
The term for this is relational databases
You can achieve building a relational database using either mysql itself using 'innoDB' driven tables.
The logic behind it is the following (in your case)
You have 3 tables:
- Users (with userid, username, userpassword, etc.)
- PlacedOrders (with orderid, userid, productid)
- OrdersDetails (with orderid, productid, orderdate, ammount, etc.)
- Products (with productid, productname, productweith, etc.)
Here all the '...id' names are primary keys
For users the primary id is userid
For placedorders the primary id is orderid
etc.
But some tables also have another '..id' that is the primary id from another table.
like userid in the table placedorders is the primary id from users
These id's are called foreignID's
These foreignID's are linked to eachother.
The logic behind it is that for the table placedorders you won't have to include the user name or password, stuff like that.
This prevents redundancy and can improve database efficiency when you have a lot of data.
Just one more hint about how this would be used in a website:
A user first logs in using data from the table users.
Then he goes to the product page and selects the product and the ammount he wants to order.
Now when placing the order an order will be made inside orderdetails
And a all the variables (orderid, productid and userid) will be combined in placedorders
Now for the user this isn't an improvement.
But for you (or the shop) it is.
This way to see who has ordered what using data from just the placedorders table
This way you can make a (search) page where you are just one click away from seeing the users' data, product detail and order detail.
Now with some handy scripting you can easily grab the appropriate data from the product, user and order and put these on one page while you don't have everything inside one big messy database