Support `groupBy()` for relations
## Problem In order to do any type of work on a Star Schema where you select the Fact Table and join in all of the Dimensions, you will always be grouping by related columns... almost never anything in your Fact table. So for reporting / BI, this is a big deal. We need Group By Relation support. ## Suggested solution I am expecting something like the following: ```js const groupUsers = await prisma.sales.groupBy({ by: { time: { year: true // or { ordinal: 1 } } }, _sum: { dollarsSold: true, }, }) ``` Please note the ordinal notation brought up here: See: https://github.com/prisma/prisma/issues/8743 ## Alternatives **Edit** - Currently Prisma uses a string array in the *by* clause. You could keep that same format, just have it delimited. Example: ```js by: ['time/year'], _sum: { dollarsSold: true } ``` This keeps more in line with what Prisma is already doing, it creates a less cluttered look, and frankly, if I am going from OData where the values are already in a delimited form, like that what is in the example, it fits perfectly without having to parse it all up and then create an object structure out of it. This also removes the order ambiguity as mentioned above. ## Additional context Grouped aggregation is key to BI Reporting, especially when using Data Marts with a Star Schema pattern. You are always filtering and grouping off of related tables, "Dimensions".
Posted by brandonmpetty on Aug 14, 2021, 2:37 AM
Tags
Related issues
- The only thing keeping me on VSCode these days is the remote SSH development.
- Something similar was done in a sheep model: "A bioactive supramolecular and covalent polymer scaffold for cartilage repair in a sheep m...
- Proposal for OpenHarmony Adaptation of [ ThreadPool ]
- Proposal for a pipe-like operator to chain constructor/method invocations without nesting
- Implement support for Node Stashing
- RSC and CDN interaction makes next.js inefficient for highload projects
Raise real-world problems, find people facing the same issue, and discuss solutions.3,000 issues0 comments
support (E-commerce)
The only thing keeping me on VSCode these days is the remote SSH development.
Something similar was done in a sheep model: "A bioactive supramolecular and covalent polymer scaffold for cartilage repair in a sheep m...
Proposal for OpenHarmony Adaptation of [ ThreadPool ]
Proposal for a pipe-like operator to chain constructor/method invocations without nesting
Implement support for Node Stashing
RSC and CDN interaction makes next.js inefficient for highload projects
Extract Action Notifier framework for push notifications
Improve support for monorepo by supporting git options such as depth, and sparse checkout
Support `groupBy()` for relations
## Problem In order to do any type of work on a Star Schema where you select the Fact Table and join in all of the Dimensions, you will always be grouping by related columns... almost never anything in your Fact table. So for reporting / BI, this is a big deal. We need Group By Relation support. ## Suggested solution I am expecting something like the following: ```js const groupUsers = await prisma.sales.groupBy({ by: { time: { year: true // or { ordinal: 1 } } }, _sum: { dollarsSold: true, }, }) ``` Please note the ordinal notation brought up here: See: https://github.com/prisma/prisma/issues/8743 ## Alternatives **Edit** - Currently Prisma uses a string array in the *by* clause. You could keep that same format, just have it delimited. Example: ```js by: ['time/year'], _sum: { dollarsSold: true } ``` This keeps more in line with what Prisma is already doing, it creates a less cluttered look, and frankly, if I am going from OData where the values are already in a delimited form, like that what is in the example, it fits perfectly without having to parse it all up and then create an object structure out of it. This also removes the order ambiguity as mentioned above. ## Additional context Grouped aggregation is key to BI Reporting, especially when using Data Marts with a Star Schema pattern. You are always filtering and grouping off of related tables, "Dimensions".
Comments (0)
No comments yet. Start the discussion.