Is it crazy to “break” the table like that?

Question

Database design

The script of the universal Catalog (of goods) is being written. (There are only three types of goods - "normal", "digital", "goods-services")
There is a table of objects/goods. The 1st part of the fields is purely "system", and does not change from site to site (eg published, alias, date_add, date_update, ...). The 2nd part of the fields can change from site to site (for example, "quantity", "shipped within", "width/height/length", "weight", "tax", "article", "file (attachments) ", ...) Eg. digital goods and goods-services will not have almost all of these fields.
It would be desirable to give the chance to the user to change to delete/add/change fields of the 2nd part.
Therefore, you can "break" the main table of goods into 2. 1st with "STATIC structure".
(In contrast to the tables - "Types of goods" there will not be a DISCHARGE of the table. That is, for example, 15% of processors, 22% of laptops, 17% of monitors are scattered over the tables. These types have "non-overlapping", individual attributes, which will be placed in separate tables. Why in the main table - there will be fewer empty fields. Here, the 2nd table is not some kind of SEPARATE type of product. On the contrary, it has a different meaning "GENERAL set of fields - for ONE specific site / store" )
Question 1. How crazy is it to break the main table like that?
Question 2. If you still break it, how critical will it be in terms of performance? If there are, say, 70-100 thousand goods?
Question 3. How bad is it, and what is fraught with - to allow the user to change the structure of the 1st table (which is, as it were, the "entry point")? (Just by marking somewhere which fields it does not have access to)

Answer 1

It is urgent to read about the normalization of tables and join :))) While some kind of porridge :)))
There should not be any rarefaction in the norm. Well you will not be able to provide integrity of the data, porridge will be. It should be several related tables. With the necessary restrictions to ensure data integrity.
Conceptually, you should have multiple "dimension" tables. For example, the type of product is in a separate table. Available goods with descriptions - in another. Naturally, if the table with descriptions will refer to the table of product types. Etc. And one fact table. It contains what, by whom, to whom, when it was dumped, for example, in the form of references to the corresponding tables.
And then collect, collect all joins.
In general, read, understand. With porridge in the head, only porridge can turn out. God forbid you to dump all the information in one heap.

Answer 2

Read about database normalization and questions will disappear by themselves