What is the best way to organize the architecture of an online library?

Question

MySQL

Good day, the following question arose.
What is the best way to organize the architecture of an online library if the following functionality is meant:
- Adding a book (file) by a user
- Adding a book from the global library to your library
Global Library = a list of all books existing on the platform, comments to them and all information
How best to implement this with database point of view?

Answer 1

The question is very general, please specify the scope of the project, because The bloat of the architecture depends directly on the number of chips and the expected load, on the list of use cases in the first place. I have developed a number of large book projects, the architecture as a whole is somewhere like this
1) core, stores basic entities (books, authors, collections, categories, series, editions, etc.) and their relationships. Provides services such as GetBookById, GetListByCategory, GetListByAuthor, GetListByCollection... if the project is large and distributed to the core, there are several "decorators" - they select and serialize the received data into the required representation (JSON/XML to provide API, objects of varying degrees of detail for internal use)
Spinning as a rule on standard bases, tk. the set of kernel features is quite primitive and the access patterns are simple. Well, who is coding on what much. Each entity has a table, links are usually nm, so immediately start a single XtoY registry (well, or for each pair your own if you want).
2) the indexer takes data from the kernel and generates metadata based on it (graphs, full-text indexes, prediction indexes, stoplists, etc.). Searching through these metadata is much more efficient than sampling their base on complex queries. The indexer also allows you to perform a quick full-text search on data descriptions and even the insides of books and make selections like "give me books in German published between 1920 and 1940 on historical topics by authors whose name begins with A and who have a rating of at least 4 and cost no more 20 bucks, only those who have the word love in the description and either hate or death in the title.
here, as a rule, special demons like sphinx / lucene are used
3) The faceted search engine itself can get away from indexers and from the metadata obtained in the previous module get useful functions such as "what books are similar to this one", "what authors are the most popular in the section", apply filters to entity listings, etc.
4) Front-end - actually site display logic, the code consists mostly of requests to the core and facet and a template engine that wraps their response into a beautiful layout
5) CDN - storage and delivery system for static files. Book covers, samples, books themselves, etc. Image resizing, cache management, download protection, etc. etc. On a highly loaded project, there can be quite a lot of logic here. On a small site, it’s rather stupid to put files in a folder))))
6) Editorial system - books are goods with a huge amount of important metadata that are critical for the user (if the books are scientific), sometimes you need a serious system for collecting and modifying this metadata
In general, you can talk for a long time, if you decide to get serious - write. Sharing experiences and insights