Learning note / Reflections on my studies
Database Systems
Database study helps me see an application through its information: what needs to be stored, how records relate, and which rules should remain true even when the interface changes.
Starting with the relationships
Before thinking about a query, I want to understand the entities and how they connect. A relationship that is unclear in the model tends to stay unclear in the application.
Keys and constraints are useful because they turn some of those expectations into rules the database can enforce.
What a query is really asking
SQL becomes easier to reason about when I describe the result first: which records count, how they should be grouped, and what one row in the output represents. Joins and aggregates then serve that question.
I pay particular attention to duplicate rows and missing values. A query can run successfully and still answer the wrong question.
Why it matters beyond the classroom
This connects directly to my PostgreSQL work on the clinic dashboard. Summaries only make sense when the underlying relationships and the meaning of a record are understood. A polished chart cannot fix a poorly defined query.
What I take forward
- Model the relationships before the screens.
- Define what one output row means.
- Treat data integrity as part of the application.