In general by domain/research area. Projects come and go but domains stay. E.g., at first I started a single db with all I ever thought important for the company in there. That turned into a mess quickly but it did show where I wanted my dividing lines to be. Refactoring is part of engineering life so I split it all up into ‘products’ and ‘technology’ and later on split it up some more into technology papers/research and patents and the products db became products and competition. Each of these databases naturally formed differently but each time how to carve out the specific domains became clear when working with the data first.
Now my role is much more engineering and I have a database solely dedicated to electronic components (specifications, app notes, white papers, guides, some emails and snippets from forums). The grouping in the database is a taxonomy of electronic components, the tags are organized towards supplier names, technology used, type of info etc. So it is extremely easy to drill into say “ADCs” by “texas instruments”, “datasheet”.
I have another database on machine learning and AI, just a wide collection of papers. With the grouping taxonomy (somewhat) setup along the ML technologies. Another database that indexes the source code of an embedded operating system I am using - allows me to find just about anything much more quickly than with native IDE. I have a patent database with a) ongoing matters and b) existing patents. Patents grouping taxonomy by technology, tags are setup by patent author/company and priority date. Using the auto classify feature from DT I can quickly file new found patents. Additionally, this works so well that if engineers approach me with a patent idea, I ask them to write up a good half page (preferably whole page) and use the classify function to see in which category it falls and what the existing/relevant art is it potentially competes with or builds on.
It is perhaps easy to theorize and over think the ideal DB structure too much. I’d say just start with a rough idea and dont be affraid (too lazy) to redo it once you start to see what works/doesn’t work.