# Ideal PostgreSQL DB Design Rules
New Schema/Business Logic/Metrics should follow the standards outlined below.
If possible - try to define logic in the order outlined below.
## 1. Views for all computed properties
A computed property being anything that can be computed from other fields, and is not a count/metric.
Having these views out of the way first will be very handy when working on metric logic, since most metric
logic will be based off of these properties.
### Example(s)
###### Events View
A View that handles all the computed properties for events.
- events_view (view)
- start_date
- end_date
- Upcoming (computed column)
- Past (computed column)
## 2. Stored Procedures for counts/metrics
Counts/metrics being any count that can be calculated off of a property or properties. Try and calculate
metrics off of existing business logic abstractions.
### Example(s)
###### Event Metrics
Function that returns all metrics related to groups.
Function args should be all the items we would want to filter by
- events_metrics (event_id, event_type, user_type) (stored procedure)
- total
- upcoming (where events_view.upcoming)
- past (where events_view.past)