- enterprises will inevitably have more data being collected and maintained than their IT departments can keep up with, so business users resort to using spreadsheets or proprietary/incompatible tools.
- hard to share or integrate this data with other systems
- eventually the IT departments have to come in and build on top of or fix these tools (crazy formatting, having to reverse engineer the export)
- there isn't really a great alternative
- access: desktop software, outdated, not multi-user.
- airtable: prioprietary, saas-only and could disappear/pivot.
- salesforce: expensive, proprietary, easy to cross the line where it's very difficult to port (e.g. workflows, notifications).
- empower the business users of an enterprise with the ability to manage basic data in a way their IT departments support
- should the use case outgrow our product, the IT department should be able to take the data with them to a new product, without having to export/clean-up/reverse engineer
- be as vanilla database as possible, using database features instead of custom things. application should be a light layer on top of the database.
- e.g. ideally wouldn't even need tables for the application. just the data.
- "should work with an existing db" is a good litmus test of this (necessary to "install"?)
- work with the databases enterprise IT support/like
- this means oracle and mssql :( in addition to pg
- should work with an existing db (?)
- should allow DB to be edited outside the application
- what's the best way to store dataface-specific metadata for each column (e.g. the "display field" of a foreign/linked row, column order, formatting options)? Column comments, metadata table? (if the latter, how do we keep it in sync?)
- how do we handle change notifications if DB is edited outside the application?
- could do DB triggers, but that involves an "install"
- could only promise change notifications if done by application
- should email notifications, workflows, etc. be on the roadmap, or keep it strictly data editing?
- is it reasonable to support row-level security?
- maybe look at cross-db feature comparison
- how should auth work?
- database users, like postgrest/postgraphql?
- ldap/AD/oauth?
- auth0?
- how should sharing work? (leveraging schemas and vanilla sharing?)
- spreadsheet-like editing or one-record-at-a-time (djangoadmin style)?
- if the latter, we'd have to design the form
- store as table comment? or inside col comments
- if the latter, we'd have to design the form
- how do we track changes?