BUILDING A BASE

# BUILDING A BASE *"...We can see why adding structure to data can help us answer questions, and why we might choose a database instead of just a spreadsheet"* - [Understanding databases: Benefits of structured data](https://www.linkedin.com/learning/programming-foundations-databases-2/understanding-databases-benefits-of-structured-data?u=2194065) * there's some limitation to a spreadsheet, or if something else is desired * what information do we want to attach/incorporate with our existing structures? that is what we should put in airtable! * everything that can go into airtable *should* (even if that's not all of the text a fellow has written, but at least link to the google drive doc that has all of the text that a fellow has written). spreadsheet is flat vs. database is multidimensional. so many ways to expand and link while in a database ### [RELATIONAL DATABASES](https://www.linkedin.com/learning/programming-foundations-databases-2/relational-databases-2?resume=false&u=2194065) * Tables as entities * Rows as instances * Columns/Fields as information about each instance (each will have a defined type) ### [KEYS AND UNIQUE VALUES](https://www.linkedin.com/learning/programming-foundations-databases-2/keys-and-unique-values-2?resume=false&u=2194065) The part about unique values in tables is interesting, because in our airtable bases, we tend to use formulas nade of concatentating other attributes in two or more columns. QUESTION: do we think of the key as that first field? or as the Airtable Record ID? * there is a unique airable key that is often hidden. when do we want to hide it or have it shown? * do we always need a formula as a fake record ID? when are times we want this, and when do we not need this? note: in automations, you only see the primary field without needing a lookup ### [MODELING AND PLANNING A DATABASE](https://www.linkedin.com/learning/programming-foundations-databases-2/modeling-and-planning-a-database?resume=false&u=2194065) This feels like a good step for us to think about performing for Bok (coming up with a list of all the entities at Bok we want to track, the properties of these entities we might care about, and then some relationships between these entities). Capitalization conventions = Capitalize table names, upper-CamelCase (PascalCase) field names. Avoid using spaces in field names. ### NAMING TABLES Simple notes: tables should be labeled with the plural of the object they track. ### COLUMNS AND DATA TYPES Fields should be labeled with the singular of the object they track. Airtable offers us different options than the ones he lists, but it's still good to check these out. Q: is it true that the only difference between long and short text fields on airtable is in the view? or are they really stored differently? (like `VARCHAR(50)` or `TINYTEXT` vs `LONGTEXT`?) ### NUMBERS AND OTHER TYPES note: in AT, the date is a date object rather than a string, meaning that you can manipulate the way you view it down the line ### PRIMARY AND FOREIGN KEYS In Airtable, the primary key is the recordID, but this is hidden from you by default. Would we ever want to make this visible in a convenience column by default in every Main Base we create?