Currently making some final adjustments to my database and wanted to post here to get everyone’s thoughts on how I can structure this for scale/performance.
Business: PR software
Action:
Through our platform, user creates a pitch to send to journalists
Our platform, provides the user a curated list of journalists to select from Note: These journalists are onboarded to our platform
User (eg. buyer) selects a # of journalists (eg. seller) For example: Let’s say user selects 500 journalists to pitch
User clicks the Send button
User’s pitch is sent to journalists
Journalist logs in through their portal and reviews pitch
My question is…what database structure would work best?
A. User’s pitch gets sent to journalists one by one, creating 500 records.
or
B. User’s Pitch has a list of 500 journalists
I’m preparing to have over 1000+ journalists onboard by Spring 2023.
Interested to hearing everyone’s thoughts for the best method to scaling my app and performance
More specifically: You put a Target List on the Pitch. The type of Target List is potentially a list of Users (who are journalists which might be its own type).
Of course each target will be sent the Pitch (but that’s operational, you’ll do that via your bulk email vendor of choice).
NOW, depending upon what level of detail you’re providing to your PR Practitioner customers, the Target List might be a very different datatype.
Consider:
Does your email service provide hooks such that you can know if a Journalist opened your email/email delivered/email bounced?
Will you also provide a way for the PR Practitioner to record whether a given Target responded?
Etc etc.
IF SO, then the objects that are part of the Target List are more advanced. You might call those things Target Status objects and they would have all if the fields required to support whatever tracking/reporting your service might deliver.
(Fun fact: I am not just an internet troll, Bubble user, and Bubble plugin builder, but I ran corp comms for enterprises large and small, public and private, for a couple of decades. If I were building such an app, I would def call my PR practitioner role “Flack” and my Journalist role “Hack”. Don’t miss that opportunity here.)
@keith laughing: Will definitely keep the names in mind for the PR role and Journalist role. Good to hear we’re in somewhat similar fields, I ran a creative music agency for 12 years, PR and marketing was one of main services
Based on your response, a Target List (list of journalists) connected to the pitch might be the way to go but here’s something worth noting.
The platform I’m building here is a bit unique. I was using Postmark to send pitches initially (ran an API workflow on a list to send out to journalists individually), but now we’re creating a platform for journalists to onboard, a hub to receive pitches inside our platform — in short, I’m creating an inbox with Bubble for music journalists … and then the goal here is to tackle the fashion and art industry.
This way I can track everything: play counts, view counts, open and click rates, responses, likes, ratings, etc.
At the moment, I have it setup as:
Data Type: Pitch
From: User
To: List of Sellers (Journalists)
Submission: Submission (Pitch)
Play Count Total: number
View Count total: number
Activity Feed: Activity Feed
I just want to make sure the app is setup for scale and performance.
Interesting! I’ll give this some more thought. The thing with Bubble and datatype structure really just comes down to what sort of searches do you need to be super-performant (or easily constructed via the expression builder).
My gut tells me to combine the pitch recipient on an object with other metrics rather than having it just as a list of Hacks. (That is it’s an Object with a Hack on it and other metrics related to open rate, etc.)
Unclear to me if the play/count/feed should be on their own object. At any rate it’s nice that Bubble makes it easy to mess around with/change that as needed.
@keith Thanks! Searching for pitches to present and deliver to the journalist’s inbox is really important (obviously). This was actually my main concern in regards to performance… what would be faster, searching for a pitch with a list of 500+ … or searching 500+ pitch records (1 journalist for each Pitch).
Data Source would look like this for a list
For the journalist inbox.
Data Source: Search for Pitch
Constraints:
To: Search for Seller / Created by: Seller (Current User): first item
Sort by: Create Date / Descending “Yes”
Looking forward to hearing your thoughts. With your background, I’m sure you understand how this model could be better structured. I’m near the finish line — probably have 3-4 more weeks.
@keith Figured the best route here and just thought I should share.
A list of journalists wouldn’t be the best route as I would need to connect the metrics for each of their actions (as you mentioned before). Also, creating a repeating group for a list of pitches that each have a list of journalists connected to it could really impact performance in the long run.
A record for each pitch sent to each journalist is the best route to take here. The right searches and constraints should help pull the right data when needed.
Thanks for the brainstorming session here, it was much needed.
Yeah, @saviorabrams, a lot of times (all the time, perhaps?) the best Bubble database structure is dictated by what is best/easiest/fastest to retrieve with a vanilla Bubble Search query and there’s no sense in fighting it! Good luck with your app, which sounds pretty cool!
