Go to file
xeruf be404dc8d0 Rename Tasks to Items and fix schema 2024-04-11 18:25:09 +02:00
Application Rename Tasks to Items and fix schema 2024-04-11 18:25:09 +02:00
Config Initial project setup 2023-04-16 12:31:32 +02:00
Web Rename Tasks to Items and fix schema 2024-04-11 18:25:09 +02:00
static Rename Tasks to Items and fix schema 2024-04-11 18:25:09 +02:00
.envrc Start upgrade to v1.1.0 2023-10-03 20:29:29 +03:00
.ghci Start upgrade to v1.1.0 2023-10-03 20:29:29 +03:00
.gitattributes Initial project setup 2023-04-16 12:31:32 +02:00
.gitignore Start upgrade to v1.1.0 2023-10-03 20:29:29 +03:00
.stylish-haskell.yaml Initial project setup 2023-04-16 12:31:32 +02:00
App.cabal Rename Tasks to Items and fix schema 2024-04-11 18:25:09 +02:00
Main.hs Initial project setup 2023-04-16 12:31:32 +02:00
Makefile Initial project setup 2023-04-16 12:31:32 +02:00
README.md Rename Tasks to Items and fix schema 2024-04-11 18:25:09 +02:00
Setup.hs Initial project setup 2023-04-16 12:31:32 +02:00
compareware-erd.plantuml Update Readme and Diagrams 2024-04-10 15:33:55 +02:00
compareware-erd.png Update Readme and Diagrams 2024-04-10 15:33:55 +02:00
default.nix Start upgrade to v1.1.0 2023-10-03 20:29:29 +03:00
flake.lock Commit flake.lock 2023-10-03 20:32:18 +03:00
flake.nix Rename Tasks to Items and fix schema 2024-04-11 18:25:09 +02:00
hie.yaml Initial project setup 2023-04-16 12:31:32 +02:00

README.md

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
  • Items can have Tags: Implemented

To Implement

  • Authenticated Users can write 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 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.

CompareWare Overview Entity Relationship Diagram

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.