Update Readme and Diagrams

This commit is contained in:
xeruf 2024-04-10 15:33:55 +02:00
parent 70e999f465
commit 3ae07c38f7
4 changed files with 30 additions and 78 deletions

View File

@ -5,13 +5,14 @@
- `Items` can have `Tags`: Implemented - `Items` can have `Tags`: Implemented
### To Implement ### 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) - 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 - `Users` can trust (the reviews of) other users,
creating a web of trust
## Database Design ## Database Design
`Tags` are Key-Value like in [OpenStreetMap](https://wiki.openstreetmap.org/wiki/Tags) or Wikidata, `Tags` are Key-Value like in [OpenStreetMap](https://wiki.openstreetmap.org/wiki/Tags) or Wikidata,
that is why they need own tables. that is why they need own tables.
Initially I planned having a shared `Tags` table for both `Reviews` and `Items`, 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, 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, so two separate tables would have needed to been set up to track the referenced object,
with a risk of anomalies: with a risk of anomalies:
@ -23,6 +24,13 @@ Considering the simplicity of a Tag,
creating two separate tables prevents those cases without overhead creating two separate tables prevents those cases without overhead
and normalizes the schema. and normalizes the schema.
![CompareWare Overview Entity Relationship Diagram](compareware-erd.png)
Of course, every many-to-many relationship needs another table
to be represented in a normalized well,
which the diagram of the actual structure used in the code illustrates:
TODO
## Developer Setup ## Developer Setup

View File

@ -8,15 +8,8 @@ left to right direction
entity User { entity User {
Id: Autoumber Id: Autoumber
-- --
Name (UNIQUE) Name: String
Pass Pass: String
}
entity Tag {
Id: Autoumber
--
Key: String
Value: String
} }
entity Item { entity Item {
@ -28,13 +21,26 @@ entity Review {
Id: Autoumber Id: Autoumber
-- --
(FK) AuthorId (FK) AuthorId
Text Text: String
} }
entity ItemTag {
Id: Autoumber
--
(INDEX) Key: String
Value: String
}
entity ReviewTag {
Id: Autoumber
--
(INDEX) Key: String
Value: String
}
User ||--o{ Review::AuthorId: Writes User ||--o{ Review::AuthorId: Writes
Item --o{ Tag Item ||--o{ ItemTag
Review --o{ Tag Review ||--o{ ReviewTag
Item }|--o{ Review Item }|--o{ Review
User }|--|{ User: Trusts User }|--|{ User: Trusts

BIN
compareware-erd.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 22 KiB

View File

@ -1,62 +0,0 @@
@startuml compareware-erd-nf
skinparam linetype ortho
hide circle
left to right direction
'!theme sandstone
!theme blueprint
entity User {
Id: Autoumber
--
Name
Pass
}
entity Tag {
Id: Autoumber
--
Key: String
Value: String
}
entity ItemTag {
(FK) ReviewId
(FK) TagId
--
}
entity Item {
WikidataId: String
--
}
entity Review {
Id: Autoumber
--
(FK) AuthorId
Text
}
entity ReviewTag {
(FK) ReviewId
(FK) TagId
--
}
entity ItemReview {
(FK) ItemId
(FK) ReviewId
--
}
User ||--o{ Review::AuthorId: Writes
Item ||--o{ ItemTag
Review ||--o{ ReviewTag
ItemTag::TagId ||--o| Tag::Id
ReviewTag::TagId ||--o| Tag::Id
Item::WikidataId ||--o{ ItemReview::ItemId
ItemReview::ReviewId }|--|| Review::Id
User }|--|{ User: Trusts
@enduml