Database Write Back
Pyramid is often asked when they will add a "write back" option to the tools. Often such functionality is centered around capturing end-user data input or budgeting and planning applications. In other scenarios, it's merely a technique for users to view data in a database with an option to correct/edit data elements directly from the same tool used to view them.
Today, we have the ability to build entire databases, tables and even columns into a database via the data modeling tools. But the type of "write back" we are referring to here is literally more like a row-by-row data capture and manipulation tool set.
In formulating the scope of such capabilities, we are trying to determine what are the critical functions that users are after.
In this article, we would be happy to hear about your use cases, your interest in such a feature and some very specific guidance on the functionality you would like to see.
You can also just vote for the feature here.
Our needs focus mostly for SQL-database actions.
- possibility to delete, insert and modify data
- possibility to set rules for when and for which cells editing is allowed
- |column 1||column 2||column 3||column 4| --> only column 4 can be edited, but only if columns 1-3 fulfill certain conditions (col1='a', col2 > i, col3 in (listed values found from another database))
- possibility to write metadata for each edit (why)
- possibility to force the user to write metadata (otherwise the edit will fail)
- automatic metadata for each edit (what, who, when)
- possibility to write metadata into a different database than where the edit is done
- possibility to set a key that follows the metadata from the edited database (for example value in col1 is copied as id)
- possibility for an automatic conditional editing (if... then...)
- possibility to write ML outputs into a specific database
- possibility for actions in storyboards (if button is pressed in Pyramid, then cell value in certain database changes (for example +1) --> this would trigger other actions later)
- possibility for dynamic pass-through queries (if a button is pressed in Pyramid, it would run a stored procedure with parameters from that storyboard page)
Relational Writeback is the one thing, the ability to writeback data directly into an OLAP-Cube (for planning purposes or analysis of different scenarios (what-if)), is also highly appreciated.
Basically that would just mean to send an UPDATE CUBE Statement to the Analysis Services, but as always the devil is in the details. Be aware of
- splashing algorithm(s)
- special splashing functions
- granularity attribute
- multiple hierarchies
Good luck! ;-)
thanks for giving us the chance to participate in this process.
We support the ideas from Eerikki and Markus and would like to add the main requirements from our perspective:
1 „Workflow Support“
- possibility to store data about from whom / when / which data was edited
- data entry disable rules (e.g. when own results are submitted / next phase is initiated or planning is globally finished)
2 Flexibility with data
- possibility to store not only numeric values, but also text and dates...
- possibility for users to insert new elements (e.g. new product, employee, investments...)
- possibility to even change hierarchy relationships (e.g. let users change category of products, assign client to another sales person...)
- Possibility to set validation rules (Value must be positive, above a certain value...)
- Possibility to activate splashing
- complex data calculations after data entry or after pressing button (e.g. calculation of depreciation)
Thank you, best regards