What database structure to choose for a catalog with custom fields?

Question

PHP

I want to develop an online catalog of radio components so that you can keep records, search by parameters, group, and - most importantly, use a common inter-user database of components so as not to paint the characteristics of the K561LA7 every time, but they could be "pulled up" from those that were made other users. And if not, then offer your own description, eventually speeding up the filling of the database ...
I do it because all the programs available are rather stupid, ugly or simply require a lot of actions ...
But due to my little experience with databases, I can’t choose how to organize the base.
So far, I see this option
1. Table of characteristics
Fields: Element group, Element type, Element subtype, Characteristic, Characteristic type, symbol, options
For example, it will be filled like this:
- Transistors - Bipolar - Collector current - Number - Ic
- Transistors - Bipolar - Collector-emitter voltage, max - Number - Uce
- Transistors - Bipolar - Structure - List - Structure - "NPN, PNP"
2 Table of characteristics moderated
- Element name (PRIMARY), Element group, Element type, Element subtype, JSON-encoded string of characteristics
Filling example:
- KT3107A, Transistors, Bipolar, { "Ic": 4, "Uce": "50"}
3. User base
1. Name (PRIMARY), Storage location(s), Quantity(s)
Filling example
KT3107, "desk drawer", "10"
KT3102, "cell 33, cell 20","10.0"
Perhaps you need to do it differently - for each storage location - a new line?
As a result, when adding an element , the
user enters a name, if it was not found, then he
selects a group, type, subtype, a list of characteristics appears, fills them in, sends them for moderation.
While not moderated, this entry in the Features database is marked as "Checked" so that other users are warned..
Also, the characteristics should include the ability to attach graphic materials and documents, such as datasheets .. At the same time, one document may be suitable for a group of elements, this must also be somehow provided. For example, to offer to select already loaded documents for an element, focusing on the Group-type-subtype and the label that the document contains information applicable to many components..
How optimal is such a structure?
It is clear that there will still be a table of users and maybe some other service ones.
I will also be glad for any help in creating such a project ..

Answer 1

document-oriented databases to help you, you can also google on request noSQL, if you still want a relational database, then see the EAV approach to storing information,
and so try to implement it first without the ability to set new characteristics to users, is there a list of characteristics in the radio parts so huge and tends to infinity?

Answer 2

Well, from unstructured bases and EAV already @Playbot said, I can only say that you can use ready-made solutions. They are called CCK. These are kitten constructors. For example Cobalt for Joomla.
Why?
1. You will receive a CMS and can also put up a forum, gallery, .... and quickly expand your site without spending a lot of time.
2. You can customize everything yourself.
3. Save time on project launch.