| 326 | | 1. !get_user_daily_calories (Function) |
| 327 | | |
| 328 | | * This function calculates a user's total caloric intake for a specific date by joining logged food portions with their respective nutritional content. It handles edge cases by converting empty log results into a baseline value of zero using COALESCE. Its main purpose is to serve as a reusable calculator for the application's dashboard. It isolates the mathematical conversion formula ($(\text{Calories} \times \text{Quantity}) / 100$) entirely within the database layer. |
| | 326 | 1. get_user_daily_calories (Function) |
| | 327 | |
| | 328 | * This function calculates a user's total caloric intake for a specific date by joining logged food portions with their respective nutritional content. It handles edge cases by converting empty log results into a baseline value of zero using COALESCE. Its main purpose is to serve as a reusable calculator for the application's dashboard. It isolates the mathematical conversion formula (Calories * Quantity) / 100) entirely within the database layer. |
| | 329 | |
| | 330 | 2. log_food_entry (Procedure) |
| | 331 | |
| | 332 | * This procedure manages the creation of a new meal record by validating user inputs against business rules before inserting data into the logs. It explicitly blocks invalid meal types, zero or negative quantities, and non-existent user or food identifiers. Used as a safe write-API for application data entry. It protects database integrity by throwing explicit procedural exceptions to reject malformed requests before they hit storage. |
| | 333 | |
| | 334 | 3. !trg_update_food_calories (Trigger & Function) |
| | 335 | |
| | 336 | * This trigger intercepts inserts or updates on the food nutrient mapping table and automatically extracts energy data. If the nutrient matches the specific !kilocalorie identifier, it modifies the main food item's summary column. Used to enforce automated data !denormalization. It ensures that the frequently read calories_per_100g summary column on the main table remains perfectly synchronized with raw, deeply nested nutrient records without manual !backend updates. |
