Refer to Inventory Use Case for additional context.
The user has created a new table in Mathesar via file import. The table is used to organize their music album collection.
The user’s goal is to create a top-level releases table and break artists into another table.
- Create separate tables for related information
- Move data that will repeat often into a reference table
- Connect reference tables with foreign keys
Once the user has created their initial table, they need to add an additional one to include the data they want to link. The user can enter the data manually or they can create a new table by import, the difference is that this time they add it to an existing schema.
- ID field is visible
- If ID is detected during import the user can accept it
- Assumption is that ID = primary key
- Import from file can detect attributes and propose an append rather than replacing
- When creating a new table, do we show a sample field? Or no fields at all?
- Can an existing table be replaced by file import?
From a sidebar panel, the user can see a list of all tables inside a schema. To open a table, all they have to do is click on the corresponding item link. The table will open as a tab in the content area and be closed from the tab.
There are two alternatives to solve this step, and each has its pros and cons.
- Can open tables from different schemas
- Can access multiple schemas from sidebar
- Sidebar takes horizontal space
- Save up space by removing sidebar
- Can’t fit too many tables in the same view
- How does the user know changes have been saved?
- Interface needs to show auto-save status
- Consider activity log
- Can users undo changes?
- Can users undo table deletion?
- Yes. Users should be able to retrieve a table from an archive.
- Add views to sidebar
- User breaks column into a new table (look at dabble DB example)
- New view is created to show combined data, user redirected to that new table
- If user wants to add a computed field a view is added