Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GUN to Relational Database for Reporting features #32

Open
merarischroeder opened this issue Mar 27, 2019 · 1 comment
Open

GUN to Relational Database for Reporting features #32

merarischroeder opened this issue Mar 27, 2019 · 1 comment

Comments

@merarischroeder
Copy link

merarischroeder commented Mar 27, 2019

Feature request.

There are no major reporting engines that support GUN (nor most NoSQL DB systems). My solution for this kind of issue is to:

  1. Architect the NoSQL database, treating each collection like a table, with only a single tier deep of records; AND
  2. Have a general software system that subscribes to each collection, and inserts/updates records in a relational database.

I'm sure many coders can repeat [2], and do it in all kinds of mind-bending ways. But ideally, each NoSQL vendor does this kind of thing once and well. I'm sure there are unique features with each NoSQL database system to ensure the integrity and timeliness of relational reporting data.

(Also, there's a chance to use a streaming SQL language so that special reporting results tables can be built live, and aggregate results can be maintained for ready near-instant access.)

This might be a key feature that's missing to enable widespread adoption. With an adaptor to a relational database, most reporting engines will be able to READ from such relational databases for business reporting needs { Dashboards, Emailed PDF reports, adhoc reporting, etc }

It would be best if a "GUN-PostgreSQL" (for example) adaptor project could be managed alongside the core GUN project(s).

Benefits:

  • Backups - there are standard mature practices and tools for backups
  • Technology-redundancy - Gun-db is solid, but not near as mature and trusted yet as postgresql. Being able to have data in postgresql as well means more peace of mind.
  • Leverage postegresql - only implement features in gun-db that you can't workaround with postgresql. That means you can focus on the biggest benefits of gun-db first.
  • SQL - one of the leveraged benefits - SQL query directly off postgresql, don't try to parse SQL with gun
  • GraphQL - another leveraged benefit. With Postgraphile you can turn postgreql into a graphql server leveraging views, and the security model.
  • Reporting tools - unlock tools like powerbi

(If you think of any more benefits please comment, and I'll add them to the OP list here)

Thanks.

@amark
Copy link
Contributor

amark commented Mar 27, 2019

Thanks!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants