Invoicing design-data table structure design of documents

Document data table Design

 

In table design, I tried two methods:
Use the same entity to represent the sales and purchase orders and other documents, and then identify them by the Document Type field. Because the document is designed to access and exit goods, the document type must have a status sign. The reason for doing so is:
1. In line with the OO design philosophy, the order is regarded as a class
2. Good code reusability and High Efficiency
3. It is conducive to business expansion. by inheriting the order class, you can add new businesses by adding interface methods.
In the implementation process, especially in the database design, this idea produces some small tables

 

Of course, you can also split a ticket, that is, consider each ticket as a separate entity. This has the following benefits:
1. For enterprises with large business volumes, splitting orders helps reduce the complexity of data query;
2. When implemented by programmers, the coding complexity is reduced and the code readability is also good;
3. The set of books is more flexible in business data backup and can be separately backed up for different businesses;
However, the design abstraction level is low, and the code reuse efficiency is not high.