Hello guys,
I am building an application where my users are employees of marketing agencies that are creating SEO reports for their customers.
I am having slight problems with deeply understanding the best practices of bubble database design. I have read and many times consulted Petter Amlies Book about performance but still this is not an easy task and I would like to be sure and not realize 6 months in that I made a huge and dumb mistake.
Please tell me what you think about the following database structure:
My questions are:
- Is the reference from
Agency DT: listOfReports
toReport DT
and the reference back fromReport DT: belongsToAgency
toAgency DT
a problem?
→ (the reason I am asking is because if a page is of typeReport DT
then this page has potentially a loop: Report DT → belongsToAgency → Agency DT → listOfReports → has all Report DTs inside which again each of them have a belongsToAgency → Agency DT → listOfReports and so on … Or is this not true? - Should I think about joinTables such as:
AgencyReportJoinTable DT
which has two fields:Agency: Agency DT
andReport: Report DT
or maybe satellite DTs? - If I use satellite DTs would’n that mean that I need way more
Do a search for
-operations leading to potentially an extremely high and unwanted WU usage? - What type should a page have other than Report DT if the page is all about the information gathered in Report DT (which is probably always the case)?
The reason I chose to go the route displayed in the image above is that I get each bit of information very easy from every point of the application. From Report DT
I can access every bit of information (like: display all keywords for one report: Current pages Report DTs keywords
, or show all agency reports: Current Users Agency DTs ListOfReports
.
My instinct says there is something not okay. (I have tried this structure in a project and on one page I have a table element displaying all keywords. Sometimes the page does not load at all or loads very slowly. I have not clue if this is related to the structure or the table element being in beta.)
What else I am thinking about:
Maybe move the Keyword DT to a MongoDB instance. This datatype can easily grow big (each report can have something around 300-1000 keywords), each agency creates many reports a month and we should have many agencies that again have many employees. So my solution should be ready to scale.
I would be really happy to start a discussion and maybe have a sparing partner/feedback on my thoughts.
Thanks!