Design Doc Review: Database Schema & Sample Frontend State

[RosemaryGonzaga]

Database Schema

• Contains correct datatypes
• Contains appropriate constraints/details
  • primary key
  • not null
  • unique
  • indexed
  • foreign key
• Contains bullet points after the table that state which foreign keys will reference to which table, or references to the associations which will be made
  • foreign key and table name are lowercased, snake_cased and back_ticked
• Correctly formatted
  • schema is written in a table format
  • the table's name are lowercased, snake_cased and back_ticked
  • the table header column names are bolded
  • columns names are lowercased and snaked_cased and back_ticked

Comments

• Address the missing bullet points above
• watchlist should be watchlists (tables should be pluralized)
• Column names should be snake_cased. Just a few examples: "stockname", "shares quantity" and "transaction cost" are not snake-cased but should be.
• Add timestamps to all tables (two separate columns: created_at and updated_at ... writign t.timestamps as the column name does not count)
• users:
  • Change username column to email. Users sign up with an email, NOT a password...
  • Add a column to store the current balance or "buying power" for each user.
• stocks:
  • Remove price column. You don't need to store this info because you'll fetch from a stock API (IEX).
• transactions:
  • Rename transaction cost column because this implies the cost of the total transaction. What you should record instead is the price of each share at time of the transaction. Something like share_price or price_per_share would be more accurate and descriptive. This should also have a null: false constraint
• Consider replacing stock_id with ticker_symbol for any table that has a foreign key referencing a stock. (This applies to the watchlists and transactions tables). Each ticker_symbol is also unique. Additionally, you will be searching by ticker symbol on the frontend, so this will make it easier to fetch the associated watchlist items and transactions from the database.

---

Sample State

• State shape is flat!
• State's keys are camelCased
• All keys within the values in the state are accessible in the schema
• Correctly formatted
  • Sample state is rendered with triple backticks, and the language ```javascript...```). This will display the state as a code block instead of a giant line of text
  • Top level slices
    • entities
    • session
    • errors (here or in ui)
    • ui (if needed)
  • Should NOT have nested slices, aka comments inside of posts
    • Some info from other tables is ok, for instance:
      • the author username and imageurl for a post. basically any info that the user can't change
      • like count and a boolean on whether the user likes the post instead of a likes slice

Comments

• After addressing my feedback on your schema, apply any changes made there to your sample state. If you add or remove tables or columns, or if you change any names, do so here in the sample state as well. For example, remove the price key from the stocks slice of state. (That's just one example)
• All the keys in your frontend state should be named in camelCase, following JavaScript naming conventions. Example: ticker_symbol should be tickerSymbol
• transactions slice of state:
  • Note that the only transactions stored in the frontend Redux state should be the ones associated with the currently logged in user. (You can't see the transactions that a different user made.) So the sample state shouldn't store transactions with different userIds. In the examples you gave, the userId should be 1 for both transactions, or 2 for both.
• watchlists slice of state:
  • Same note as above for transactions. You can't see another user's watchlist, so all watchlists stored in the frontend state should have the same userId.