You need as many as required to understand and communicate the system. For blogging software, I wouldn't think you need many. Model as much as you need to understand the system. Stop modelling when it stops adding you your understanding.
If you are new to UML you may want do a few diagrams in detail to increase your understanding of the diagrams. Once you understand a diagram type well enough you can do it in your mind, the need for actual diagrams becomes less.
If you date your diagram versions, it will help you judge whether they are likely to be current. Comparing the current design to older diagrams can be useful in determining which areas of the project varied significantly from the original design.
Unless you are using tools which generate the code from diagrams or embed the diagram specification in code the are likely to fall out of sync with the code. Detailed diagrams will tend to become significantly more incorrect over time. than overview diagram. Overview diagrams will also be require less maintenance to keep them current.
You may find it useful to generate diagrams that:
- Outline the actors and how they use the system.
- Outline the structure of packages within the system. Note which packages contain reusable components.
- Model the database structure.
- Sequence diagrams are useful to design standard components. If you have many similar components, model one and use it as a pattern for the others. Consider code reuse in cases like this.
Generate diagrams which are useful in planning the project. If a diagram is not necessary to understand and/or communicate something about the project, don't waste time on it. Feel free to use a non-UML diagram if it aids understanding. UML may not be the best way to model the database.