Hi I have these tables:
I want to build a dashboard with two views:
I’m launching this Dashboard view when a record is selected in a separate Deck view. Right now I’ve got the Dashboard “working” using a separate “filter” table that is updated with a PlaceID value when the record is selected in the Deck view. Unfortunately this arrangement (at least the way I’ve implemented it) is very slow. I click on the Deck view, the Filter Table eventually gets updated, and the Dashboard view eventually refreshes to show the appropriate data…
There’s gotta be a better or more optimal way to do this. Any suggestions? Thanks!
Something like this?
In general it could be achieved by interactive dashboards, if the two tables are referenced to each other.
Thanks @Suvrutt_Gurjar … I thought about that but don’t “referneced” tables have to point to a Primary Key in the ‘other’ table? I have this table structure:
TABLE: Activities FIELDS: ActivityID (PK) and PlaceID
TABLE: PlacePhotos FIELDS: PlacePhotoID (PK) and PlaceID
The “PlaceID” is the ‘join’ component but it’s not a PK in either table. Can I still do a reference in this scenario?
Thank you @Matt_Myers for the updates.
Is there a seperate table for Place ID?. How the app user ensures she/ he enters the same place ID as a join when they add records both in Activities and PlacePhotos tables?
Can there be many place IDs for a single activity? And in turn, can each Place ID have multiple PlacePhot IDs? How the three IDs are related?
@Suvrutt_Gurjar thanks for the continued engagement! regarding your questions:
YES - There is a Places table where the PK is Place ID
This app is much more of a “content consumption” app than a data maintenance app. All this data and the relationships will be maintained manually behind the scenes directly in the data source. The people that use the actual app are pretty much just consumers of the data.
No. Only ONE Place ID ever for any given Activity record.
YES - Any give Place ID can have ZERO, ONE, or MANY Place Photo ID’s associated with it.
The three tables would be related like this:
Maybe we need a new relationship type table called Activity Photos that ties the photos Directly to an Activity? I had to do that because it would be a little duplicative…
Your continued thoughts are appreciated!!
Thank you @Matt_Myers for all the details.
Please explore below
[Place ID].[Related PlacePhotos]
[ Place ID] is the FK in the Activities table of the Places table
A) Deck View of Activities table
B) Detail view of the Activities table that has the {Related Photos] column included.
With the above configuration, the dashboard will look like below
Hey Suvrutt, just wanted to say thank you for time you spent. The discussion and examples really sent me down a good path! – Matt
Thank you @Matt_Myers for the update. You are welcome.
User | Count |
---|---|
38 | |
35 | |
27 | |
23 | |
18 |