Database grooming (pre-migrations checklist)

[kluvin]

• drink er veldig spesifikt

• vi kan sikkert med fordel finner et mer beskrivende navn i konteksten det er brukt. tror vi har brukt menu_item mye internt

  • forslag: rename til menu_item, eller bare item

• Tabellnavn er blanding mellom flertall og entall.

  • tabellnavnet representerer en type entity
  • forslag: entall

• activeMessage og displayMessage er camelCase

  • normen før disse var snake_case. snake_case er mest vanlig i sqlite økosystemet
  • forslag: snake_case

[IldenH]

Jeg foretrekker at vi gjør alt til camelCase da koden er camelCase. Jeg vil også rename følgende:

• drinks -> item
• orderDrink -> orderItem

Vi har også endel fields som ikke brukes som:

• users.purchased_cup (jeg tenker det bør være på ett individuelt order nivå)
• dinks.kind (category er bedre og brukes faktisk)

I fields er det også varierende mellom camelCase og snake_case.

Jeg er enig i å rename alt til entall.

[LilleAila]

Vi har også endel fields som ikke brukes som:

• users.purchased_cup (jeg tenker det bør være på ett individuelt order nivå)
• dinks.kind (category er bedre og brukes faktisk)

Ja, disse to og alle vi ikke bruker synes jeg og bør fjernes. purchased_cup bør fjernes helt. Egen kopp bør heller vært en "extra" for hver orderItem

[kluvin]

Tusen takk for gode innspill, eg tenkte litt mer:

• Vi kan fjerne purchased_cup og finne ut av hva en "egen kopp" egentlig er underveis
• Jeg vil bevare drink.kind fordi kaffe-diem bruker drink.kind i menyen sin i dag. Dette fordi databasen prøver å representere en verden, og den bør få plass til det, selv om ikke en av klientene bruker denne funksjonaliteten. Det er umiddelbart relevant for analyse eller hvis sesongens spesial endres.
• Når det gjelder casing: databasen bør ikke bry seg om hva konvensjon klientene dens bruker, JS bruker camelCase av historiske grunnlag. Hvis vi skal la folk laste ned databasen, vil folk gjerne bruke Python, og da er det snake_case som gjelder--men det har ikke noe å si. Slik jeg ser det så er det enten snake_case for portabilitet med PostgreSQL eller PascalCase for kompatibilitet med slik hvert eneste språk definerer typer og entities. Jeg er et proponent av snake_case fordi veldig mange SQL dialekter er case-insensitive.
• Jeg vil gjerne endre displayMessage til message slik det er brukt som FK i activeMessage.
• activeMessage vil jeg gjerne endre til status eller noe i den duren på et-ord.
• isVisible basert på kriterie over er nå kalt online
• orderItem vil jeg kanskje kalle line_item for å tyde at det ikke har noe med order eller item, jeg tror valget mitt om å konjugere tabellene var dårlig i ettertid
• kanskje kopp (stor, liten, egen) er en del av line_item?

[LilleAila]

• Jeg vil bevare drink.kind fordi kaffe-diem bruker drink.kind i menyen sin i dag. Dette fordi databasen prøver å representere en verden, og den bør få plass til det, selv om ikke en av klientene bruker denne funksjonaliteten. Det er umiddelbart relevant for analyse eller hvis sesongens spesial endres.

drink.kind brukes ikke i menyen. Det brukes relations til categories (som i praksis er samme tingen), mens kind er ubrukt i koden. Jeg synes det bør fjernes med mindre vi finner en god grunn til at dette skal brukes i tillegg til categories

• orderItem vil jeg kanskje kalle line_item for å tyde at det ikke har noe med order eller item, jeg tror valget mitt om å konjugere tabellene var dårlig i ettertid

Etter å ha brukt det synes jeg orderItem (eller order_item) gir mye mer mening, siden det er en item i en order?

• Vi kan fjerne purchased_cup og finne ut av hva en "egen kopp" egentlig er underveis
• kanskje kopp (stor, liten, egen) er en del av line_item?

Se #76 . Type kopp og slikt bør være definert der, ikke hard-codet som en kolonne i databasen.

[kluvin]

Jeg rotet litt, du har helt rett med punkt 1 og 2 @LilleAila; ser på nummer 3 i morgen (men det ser bra ut på første øyekast).