Forum Discussion
- MCFNeilQrew CaptainIf you con architect the entire app in one, I'd go that route.
If you start to push the table count of 60, then I'd consider breaking them up.
It also depends on anticipated record counts because that affect app size. QB will charge you more if your apps are too big, so if we anticipate the app getting too big (10 Million records, 40+ tables, etc.) we will break it into multiple apps.
Also things to consider are cross functional roles or groups of roles within the company (i.e. Supply chain vs Manufacturing vs fulfillment, etc.) Do they need to be together, or do they just some information from other departments.
What is your business use case? Maybe that will help clarify the needs. - JonathanRobert1Qrew Memberit would be teams like, purchasing, manufacturing, design, equipment
shared info like purchased items, parts, vendors,
would be doing things like BOM management, purchase requests, inventory, project management, maintenance, etc. Mini ERP if you will.
More than 40 tables but those are detail tables with small number of fields - like size or orientation.
More apps doesn't really give less roles so i don't see a huge benefit on interface tuning...
I just want to fully understand the choices before building alot on a questionable foundation.
Thanks for your input! really helpful! - QuickBaseCoachDQrew CaptainI will chime in too. This feels like 1 app to me as the functions are all very interrelated.