3 Enhanced formatting for better readability and included pertinent tag to provide a bit more visibility.
| link

Store Definition of approach to store temporarily unknown data

2 Enhanced formatting for better readability and included pertinent tag to provide a bit more visibility.
source | link

What structure would be more reasonable to store temporarily unknown data, that is data that? Initially we don'tdo not know yetsome aspects of the data we are working with, but such aspects will soon be filled in at some point. The problem is the following: i

Problem description

I am developing a database for product refurbishmentproduct refurbishment, in the database wewhich I have to store data such as customercustomer, modelmodel, serial numberserial number, etc. (Thisthis part is working OKwell so far).

TheSaid database has to handle shipmentshipment of productsproducts (incomingincoming - outgoingoutgoing), for outgoing there. There is also no problem for the outgoing part because we already have the data, the problem we are facing is with incomingthe incoming aspect, since some customerscustomers send productsproducts as a bulkbulk or lotlot, and we only receive a summarysummary of the shipmentshipment (model & quantityi.e., model and quantity), other customers customers do send the complete information of the products.

Alternatives I have considered

So far i, I have a SHIPMENTShipment table, and a Linkinglinking table that stores the relationrelationship between productsProducts and shipmentsShipments, the options that iI have come up with are the following.

Option A

Insert products in the PRODUCT table with null fields (Except model & customer) and relate them to a shipment, later when we receive the products we fill in those reserved spaces.

This option will allow the products to be treated as the rest and will add minimal changes to the system

Option B

Have a separate table that stores the products summary to be received, then when the shipment is received they are properly stored in the products table.:

This option will add more tables and complexity, but i will not have to deal with null data

  • Option A. Insert products in the Product table with NULL marks (except Model & Customer) and relate them to a Shipment; later, when we receive the products we fill in the columns that were marked as NULL. This option will allow the products to be treated as the rest and will add minimal changes to the system.

  • Option B. Have a separate table that stores the ProductSummaries to be received, and then when the shipment is received they are properly stored in the Product table. This option will add more tables and complexity, but I will not have to deal with NULLable columns.

Question

Questions

What approach will be more suitable?, is there any other design that i can implement or follow?

  • Which of my two described approaches will be more suitable?

  • Is there any other design or structure that I can implement or follow?

What structure would be more reasonable to store unknown data, that is data that we don't know yet but will soon be filled in. The problem is the following: i am developing a database for product refurbishment, in the database we store data such as customer, model, serial number, etc. (This part is working OK so far).

The database has to handle shipment of products (incoming - outgoing), for outgoing there is also no problem because we already have the data, the problem is with incoming, some customers send products as a bulk or lot, and we only receive a summary of the shipment (model & quantity), other customers do send the complete information of the products.

So far i have a SHIPMENT table, and a Linking table that stores the relation between products and shipments, the options that i have come up with are the following.

Option A

Insert products in the PRODUCT table with null fields (Except model & customer) and relate them to a shipment, later when we receive the products we fill in those reserved spaces.

This option will allow the products to be treated as the rest and will add minimal changes to the system

Option B

Have a separate table that stores the products summary to be received, then when the shipment is received they are properly stored in the products table.

This option will add more tables and complexity, but i will not have to deal with null data

Question

What approach will be more suitable?, is there any other design that i can implement or follow?

What structure would be more reasonable to store temporarily unknown data? Initially we do not know some aspects of the data we are working with, but such aspects will be filled in at some point.

Problem description

I am developing a database for product refurbishment, in which I have to store data such as customer, model, serial number, etc. (this part is working well so far).

Said database has to handle shipment of products (incoming - outgoing). There is no problem for the outgoing part because we already have the data, the problem we are facing is with the incoming aspect, since some customers send products as a bulk or lot, and we only receive a summary of the shipment (i.e., model and quantity), other customers do send the complete information of the products.

Alternatives I have considered

So far, I have a Shipment table, and a linking table that stores the relationship between Products and Shipments, the options that I have come up with are the following:

  • Option A. Insert products in the Product table with NULL marks (except Model & Customer) and relate them to a Shipment; later, when we receive the products we fill in the columns that were marked as NULL. This option will allow the products to be treated as the rest and will add minimal changes to the system.

  • Option B. Have a separate table that stores the ProductSummaries to be received, and then when the shipment is received they are properly stored in the Product table. This option will add more tables and complexity, but I will not have to deal with NULLable columns.

Questions

  • Which of my two described approaches will be more suitable?

  • Is there any other design or structure that I can implement or follow?

1
source | link

Store unknown data

What structure would be more reasonable to store unknown data, that is data that we don't know yet but will soon be filled in. The problem is the following: i am developing a database for product refurbishment, in the database we store data such as customer, model, serial number, etc. (This part is working OK so far).

The database has to handle shipment of products (incoming - outgoing), for outgoing there is also no problem because we already have the data, the problem is with incoming, some customers send products as a bulk or lot, and we only receive a summary of the shipment (model & quantity), other customers do send the complete information of the products.

So far i have a SHIPMENT table, and a Linking table that stores the relation between products and shipments, the options that i have come up with are the following.

Option A

Insert products in the PRODUCT table with null fields (Except model & customer) and relate them to a shipment, later when we receive the products we fill in those reserved spaces.

This option will allow the products to be treated as the rest and will add minimal changes to the system

Option B

Have a separate table that stores the products summary to be received, then when the shipment is received they are properly stored in the products table.

This option will add more tables and complexity, but i will not have to deal with null data

Question

What approach will be more suitable?, is there any other design that i can implement or follow?