我的 ER 模型需要帮助
我需要帮助为我的公司设计数据库模型。
基本上它是一家工业产品贸易公司。所以我们有销售、采购、库存、仓库、员工、应收账款、应付账款等作为主要功能。
我非常感谢有人帮助或指导如何去做。 我制作了下表：-
销售发票
invoice no(PK),
salesmanid,
customer code,
customer name,
voucher type,
invoice date,
invoice amount,
warehouse id
销售项目
invoice no,
itemcode,
sale qty,
sales price
库存项目
itemcode(PK),
item name,
qty in stock,
cost price
客户列表
customer code(PK),
customer name,
customer address,
salesman id
我需要帮助来定义正确的键并建议添加/删除列等。
I need help in designing a database model for my company.
basically it is a trading company into industrial products. so we have sales,purchases,inventory,warehouses,employees,receivables,payables, etc. as main functions.
I would greatly appreciate someone's help or guidance on how to go about it.
i have made the following tables:-
sales invoice
invoice no(PK),
salesmanid,
customer code,
customer name,
voucher type,
invoice date,
invoice amount,
warehouse id
sales items
invoice no,
itemcode,
sale qty,
sales price
inventory items
itemcode(PK),
item name,
qty in stock,
cost price
customer list
customer code(PK),
customer name,
customer address,
salesman id
i need help with defining proper keys and advise on adding/removing coloumns, etc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我最好的建议：如果您必须询问如何设计应收账款表，那么您可能不应该编写应收账款系统。我设计过拥有一千多个表的企业系统，我不愿意处理会计系统。对于大多数定制开发，您交付的系统在某种程度上定义了业务流程。你的方式可能与设计师设想的略有不同，但仍然更好。
对于会计软件，有一种方法可以完成。你最好的情况绝对是“我们没有搞砸”。
另一方面，库存通常足够特定于领域，因此需要自定义编码。那么：为什么要使用一个大的文本字段来输入地址？难道你不需要知道他们处于什么状态（也许不需要）？您是否按邮政编码分析货件？他们有您关心的电话号码吗？客户姓名通常分为名字和姓氏（至少）。
您可能需要推迟数据库设计，直到您确切（或大部分）知道要对数据做什么。模拟一些报告和虚假电子邮件活动。绘制一些界面屏幕草图。然后您可以回到数据库并更清楚地了解您的需求。预先创建一个过于通用的设计，然后必须不断修改它，这对你没有好处。在应用程序中可以更改的所有内容中，数据库可能是最困难的，因此我会首先尝试解决其他领域的问题。
My best advice: If you have to ask how to design a receivables table, you probably shouldn't be writing the receivables system. I've designed enterprise systems with over a thousand tables and I wouldn't willingly tackle an accounting system. With most custom development the system you deliver defines the business process to some degree. Your way can be slightly different than the designers envisioned and still be better.
With accounting software, there is One Way It Should Be Done. Your absolute best case is "we didn't screw it up".
Inventory, on the other hand, is usually domain-specific enough that it warrants custom coding. So: Why one big text field for address? Don't you need to know what state they're in (maybe not)? Do you analyze shipments by zip code? Do they have a phone number you care about? Customer name is often separated into first and last (at a minimum).
You might want to hold off on the database design until you know exactly (or mostly) what you're going to do with the data. Mock up a few reports, and a fake email cmpaign. Sketch out some interface screens. Then you can come back to the DB with a clearer idea of what you need. It does you no good to create an overly generic design upfront, and then have to keep modifying it. Of all the things you can change in your application, the DB is probably the toughest, so I'd try to work out the kinks in other areas first.
销售、采购、应收账款和应付账款（至少）是会计职能。如果有人提议设计我们自己的会计软件而不是购买它，我会解雇他们。或者至少用锋利的棍子戳他们的眼睛。
有时，有一些话要说，那就是重新发明轮子。但不是这个轮子。
Sales, purchases, receivables, and payables (at the very least) are accounting functions. If anybody proposed designing our own accounting software instead of buying it, I'd fire them. Or at least poke them in the eye with a sharp stick.
Sometimes, there's something to be said for reinventing the wheel. But not this wheel.