The problem in creating table database information where the columns are defined separately and the rows are defined separately

Question

In my program, the table columns are received separately from the user and stored in a separate database table. Add Column Form

Also, the rows of the table are received individually and one by one from the user and stored in another database table. When I receive the table columns from the user, I want to show a list of table row items to the user (as a checkbox list) Add Row Form

and the user can select the related rows. This way every row that is related to the column will be marked in my final table. My problem is that I don't know how to store these two in two separate database tables but finally link them together. Table

I have done the save and reload in the second form but I don't know how to save the two back to the database in a way that I can retrieve them later

why i have to do this?

I want to record the important specifications of a product first. Then the important specifications of the product manufacturing process Then choose which of the process characteristics affects which of the product characteristics. Please note that these specifications are editable and may be added or removed later.

Answer 1

Your clarification gives me a glimpse of what you want to do, but only a glimpse.

Normally, when you set up tables, you create a data model after discussion with business users and other people.

A dynamic schema as you seem to have in mind certainly has to count as advanced.

It it is true that modelling in advance is not always possible, because new requirements appear all the time. This is particularly true for ISV that target multiple customers all with their own requirements.

A common approach is an EAV design (EAV = Entity-Attribute-Value). Such a table would have three columns: one for the product, one for the characteristic, and one for the value. This type of design is not without issues, and casual use of this design can lead to very complex queries with horrible performance.

Common attributes which are always used, and commonly used in major filters and joins, are best kept as dedicated columns. Minor attributes which are only there "for information only" can be shoved into an EAV design.

Bear in mind that I still have a poor understanding of your actual problem, so I may be off track.