Can you recommend a book on database design?

Question

PHP

Hello,
I would like to expand my knowledge in the field of database design, I am interested in such questions as:
1) Choosing a DBMS, i.e. what to choose in what cases
2) The choice of subsystems of the subd
3) Illumination of the moments of the choice of indexes
4) There may be some design patterns

Answer 1

SQL database programming. Common mistakes and...
An excellent book that sheds light on design and common mistakes. (I mean patterns)

Answer 2

PostgreSQL book postgresql.leopard.in.ua

Answer 3

Introduction to database systems

Answer 4

Not really about design, but the book is very sensible
High performance Mysql 3rd edition

Answer 5

Now I will swear :)
1) The choice of a DBMS, ie. what to choose in which cases
Based on my experience (22 projects), I recommend this:
DBMS is just a tool
- If the organization has good specialists who can work effectively on MS SQL, they know all its capabilities and understand why it is so expensive - then MS SQL
- If there are good Oracle specialists in the organization - then it is better to install Oracle
- If very very secret data is processed - then something other than MS SQL is also better - for example, Oracle (since the operating system is different from Windows) - but in most companies the data is not are of interest to special services :)
2) The choice of subsystems of the subd
- It would be great to understand what the "Subsystem of the DBMS" is
3) Illumination of the moments of choosing indexes
- Everything depends on the queries that go to the database, as well as on the data. At the initial stage of indexing in MS SQL, the DBMS Engine Tuning Assistant is useful. Further, it is already necessary to proceed from the analysis of query plans (not necessarily all, but at least the longest ones). At the same time, it should be borne in mind that only indexes will be optimal on test data, and after a year of operation, the existing indexes may no longer be the best way to search through tables .... you need to administer the database ...
4) Maybe some design patterns
- In my company, they only do what they retrain the specialists who have come in who have their own patterns in their heads! Honestly - at the institute of such Herney, they don’t hammer students into the head that you are amazed (for example: some developers insert an identity field in each table - although it is not searched for, and a cluster index is hung on the same field - "Mudakskoe Russian Higher Education" (c))
- Paterny Good! Amazing! But there is no universal way!
It’s worth getting acquainted with them so as not to make mistakes - but even if you made such a mistake, then no one bothers to correct it later :) split the table into several or combine a couple of tables into one. The main thing is that applicators (client-side programmers) use the principles of OOP (so as not to alter the program code too much when changing the structure of the base)

Answer 6

Don't make life difficult for yourself. You have data. You know how you will handle them, how often to read, how often to update, by which fields to sort, how to group ... You know what data is a lot, what is not enough ... All that remains is to scatter across different tables and establish relationships .
From what is really worth worrying about: decide where to give in to the harmony of the data and choose duplication at the expense of performance. But it is better to understand this when you start to really load your creation and see that, for example, recursive questions are not so beautiful and for them it is worth introducing one more field. And which one - with the level of nesting or designation of the root of attachments - decide along the way.