2024-04-10 12:20:54 +00:00
|
|
|
# [CompareWare](https://compareware.org)
|
2023-10-03 17:29:29 +00:00
|
|
|
|
2024-04-10 12:20:54 +00:00
|
|
|
## Use-Cases
|
|
|
|
- Authorised users can create `Items`: Working, no authorisations
|
|
|
|
- `Items` can have `Tags`: Implemented
|
2023-10-03 17:29:29 +00:00
|
|
|
|
2024-04-10 12:20:54 +00:00
|
|
|
### To Implement
|
|
|
|
- Authenticated `Users` can create `Reviews` referencing one or more `Items` and `Tag` them (for example with a URL linking to a more in-depth review)
|
|
|
|
- `Users` can trust (the reviews of) other users, creating a web of trust
|
|
|
|
|
|
|
|
## Database Design
|
|
|
|
`Tags` are Key-Value like in [OpenStreetMap](https://wiki.openstreetmap.org/wiki/Tags) or Wikidata,
|
|
|
|
that is why they need own tables.
|
|
|
|
Initially I planned having a shared `Tags` table for both `Reviews` and `Items`,
|
|
|
|
but that would have been impractical because a Tag either belongs to a Review or an Item,
|
|
|
|
so two separate tables would have needed to been set up to track the referenced object,
|
|
|
|
with a risk of anomalies:
|
|
|
|
Technically there then could be no mapping in either table for a Tag, or two,
|
|
|
|
both of which are semantically incorrect -
|
|
|
|
because a Tag without reference is useless
|
|
|
|
and editing the Tag value for an `Item` should not affect a `Review` and vice versa.
|
|
|
|
Considering the simplicity of a Tag,
|
|
|
|
creating two separate tables prevents those cases without overhead
|
|
|
|
and normalizes the schema.
|
|
|
|
|
|
|
|
|
|
|
|
## Developer Setup
|
2023-10-03 17:29:29 +00:00
|
|
|
|
|
|
|
```bash
|
|
|
|
direnv allow
|
|
|
|
devenv up
|
2024-04-10 12:20:54 +00:00
|
|
|
```
|