Just some issues I’ve learned from working with huge amounts of data and users and trying to enable more ease of use when it comes to running queries.
These are just some things I think of to prevent being bitten:
Read only access, so users don’t Willy Nilly drop tables and delete/update data with a bad query
Some type of user control based on what they can see.
Leaning towards non locking queries and maybe even forcing it depending on situation to prevent table locks
Limits on amount of data to pull back. Millions of records in a slack chat lol.
Otherwise I love it and wish it was something I could use where I work l, but sadly it would open up a cluster of issues lol. We have very strict controls on database access and queries.
Hey Jordan! Wow, I love all of these points - I feel like we've definitely run into a lot of the same problems when it comes to SQL collaboration 😅
For read-only access, I definitely agree that it's important to monitor/grant to people who don't actually need to change the data (aka most people).
What's great about Beacon is we actually use the same database credentials that a user already has! So that means, if you have read-only access, then we'll grant you read-only access in the SQL app. Hopefully the folks who do have write access aren't being too Willy Nilly in their SQL querying 😉
User control on viewing outputs + preventing locking queries are both interesting points! We haven't dug too much into that yet, but will definitely consider it for potential features.
For limits on data pull back, Beacon only posts the top 10 results of your query. It took us one really long Slack post to realize that we definitely needed to add that feature in 😅
We have very strict controls on database access and queries.
This is really great information! Would it still be a problem given that Beacon actually uses someone's existing credentials for a database?
Ah that is good to hear, when I first looked at this I guess I assumed it was using a non-person ID for SQL access in the backend. So that is cool and solves the whole bad query issue if users have read only access, which I’d hope in real life every company sets their users up that way and does modifiable changes with a NPID and uses store procedures or prepared sql in an app, but that’s a pipe dream hahaha.
And sweet was wondering about how large results were handled. Lol
To answer your question at the end. If I didn’t deal with PHI that can’t be sent even though slack due to being off prem. Then yeah would probably be able to use it if everyone had read only access and queries were forced to be non locking.
Again, Great program!! If my job wasn’t so strict with data, this would save me a boat load of time as a developer when communicating with my internal customers. But to be honest I’m glad we do have the safeguards in place as I’ve noticed a lot of companies don’t and get burned because of it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Just some issues I’ve learned from working with huge amounts of data and users and trying to enable more ease of use when it comes to running queries.
These are just some things I think of to prevent being bitten:
Read only access, so users don’t Willy Nilly drop tables and delete/update data with a bad query
Some type of user control based on what they can see.
Leaning towards non locking queries and maybe even forcing it depending on situation to prevent table locks
Limits on amount of data to pull back. Millions of records in a slack chat lol.
Otherwise I love it and wish it was something I could use where I work l, but sadly it would open up a cluster of issues lol. We have very strict controls on database access and queries.
Hey Jordan! Wow, I love all of these points - I feel like we've definitely run into a lot of the same problems when it comes to SQL collaboration 😅
For read-only access, I definitely agree that it's important to monitor/grant to people who don't actually need to change the data (aka most people).
What's great about Beacon is we actually use the same database credentials that a user already has! So that means, if you have read-only access, then we'll grant you read-only access in the SQL app. Hopefully the folks who do have write access aren't being too Willy Nilly in their SQL querying 😉
User control on viewing outputs + preventing locking queries are both interesting points! We haven't dug too much into that yet, but will definitely consider it for potential features.
For limits on data pull back, Beacon only posts the top 10 results of your query. It took us one really long Slack post to realize that we definitely needed to add that feature in 😅
This is really great information! Would it still be a problem given that Beacon actually uses someone's existing credentials for a database?
Ah that is good to hear, when I first looked at this I guess I assumed it was using a non-person ID for SQL access in the backend. So that is cool and solves the whole bad query issue if users have read only access, which I’d hope in real life every company sets their users up that way and does modifiable changes with a NPID and uses store procedures or prepared sql in an app, but that’s a pipe dream hahaha.
And sweet was wondering about how large results were handled. Lol
To answer your question at the end. If I didn’t deal with PHI that can’t be sent even though slack due to being off prem. Then yeah would probably be able to use it if everyone had read only access and queries were forced to be non locking.
Again, Great program!! If my job wasn’t so strict with data, this would save me a boat load of time as a developer when communicating with my internal customers. But to be honest I’m glad we do have the safeguards in place as I’ve noticed a lot of companies don’t and get burned because of it.