| Application | ||
| Config | ||
| static | ||
| Web | ||
| .envrc | ||
| .ghci | ||
| .gitattributes | ||
| .gitignore | ||
| .stylish-haskell.yaml | ||
| App.cabal | ||
| compareware-erd.plantuml | ||
| compareware-erd.png | ||
| default.nix | ||
| flake.lock | ||
| flake.nix | ||
| hie.yaml | ||
| Main.hs | ||
| Makefile | ||
| README.md | ||
| Setup.hs | ||
CompareWare
This application is still a prototype, with only a landing page publicly available thus far.
Use-Cases
- Authorised users can create
Items: Working, no authorisations Itemscan haveTags: Implemented
To Implement
- Authenticated
Userscan writeReviewsreferencing one or moreItemsandTagthem (for example with a URL linking to a more in-depth review) Userscan trust (the reviews of) other users, creating a web of trust
Database Design
Tags are Key-Value like in OpenStreetMap 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.
For a fully normalized and implementable view, every many-to-many relationship needs another table which will be visible in a diagram generated from the schema.
Developer Setup
direnv allow
devenv up
Open up http://localhost:8000 and you can create, edit and delete items with key-value tags.
