Is it worth it in the database to separate finished products from components, or to combine them into one essence "subject"? Simplified, both options are as follows:

Option one, components, products, semi-finished products are in the general table "Items". The type determines whether the object is composite (assembled at the enterprise) or atomic (component, etc.). The only noticeable disadvantage is that the speed of processing requests will drop as the spreads out of the table, but at the same time, the Occam's razor in action does not breed. Option 1 Option two, the goods collected at the enterprise are in a separate table. Option 2

  • Usually do not break components and products for individual tables. There is one general nomenclature of items (goods / products, as you conveniently call them). Some items can be components or raw materials for others. - Sergey
  • @Sergey The problem is that what can be assembled from components can also be a semi-finished product, and in the second case, the question arises, in which table to take it? And how to establish a link between semi-finished and finished products? In the case of a single table, this is all easily solved, although I understand that this is a slightly cumbersome option. - aryndin
  • But what's the difference between a product, a mop, a product or a product? All this is primarily inventory in the accounting, manufacturing, warehouse. Think for yourself how much in which case you should consider when any inventory of the movement of goods and materials is needed, where all types of mops should be collected. - Sergey
  • @Sergey I just thought you were recommending my second option. That is, the first option, when everything in the same table is the table “type of product”, is quite a right to life for itself? It will just be a lot of records, someone will be interested in the list of components, someone a list of ready-to-sell products, all this will increase the speed of processing the request. - aryndin

0