Hi Guys,

I am just starting out on a new section for our business and was wondering what the best approach is for this:
Currently I am using the Projects table for the Sales and Marketing Department.
I already have 186 fields in this table and only learned recently that I should keep each table to around 50 fields for speed.

So, as I am due to start for another department with completely different requirements I am wondering how I am best utilizing the Project features, but not adding more fields?

I was thinking of duplicating the project table, basically creating a new project section for the different department, but I guess it will be tons of work to duplicate relationships, scripts and layouts too and get it all to work.

Other option was to create a separate table and "route" it through the Project table with the project ID and department. So that I can still use certain features and layouts, ie events based on Projects, contacts, etc.
but this means I still have the 186 fields from the current Project table, which would need to be loaded when routing through to the sub-table, at least I believe that is the case.

I probably have to add, that we don't use the invoice, purchase order and inventory features. The purchase order would be something that we could utilize in Property Management, which I am just starting on.

Any ideas/tips how to best go about this would be greatly appreciated.

Thanks
Regine

Hi Regine,

Great to hear that you're expanding your solution!

One thing to focus on might be to question whether some of the fields on your projects table should instead be in related tables. For example, if you're storing contact details or phase information directly in the project record, that data could possibly be better stored in related contact and phase tables.

This FileMaker forum post has some good suggestions on how to tackle this situation that might point you in the right direction: https://community.claris.com/en/s/quest ... s-too-many

If you did decide to go the way of duplicating the projects table into a separate table with different fields, yes, that does involve a bit of work. We do have instructions on adding new modules to Complete in the docs here: https://www.seedcode.com/pmwiki/index.p ... ingModules

If you'd like some in-depth help with this new section of your solution, we'd be happy to dive in as part of an implementation package. Packages can be used for consulting, coaching, or modifications like these and start at blocks of 5 hrs for $190/hr. When the time comes, you can use this link and with a day or two notice we can schedule our first screen-sharing session:

http://sites.fastspring.com/seedcode/pr ... onpackages

I hope that helps!

Sincerely,

KC

Hi KC,

I do believe I have not that many fields in the project table that could be in a related table.

What about this option:

Other option was to create a separate table and "route" it through the Project table with the project ID and department. So that I can still use certain features and layouts, ie events based on Projects, contacts, etc.
but this means I still have the 186 fields from the current Project table, which would need to be loaded when routing through to the sub-table, at least I believe that is the case.

Is this something that would work?

Thanking you in advance.

Kind regards

Regine

Hi Regine,

I'm not sure exactly what would be the plan there, but it sounds like you'd be setting up a related table to the Projects table for these other events. It would probably require additional calculated fields that could cause the performance to slow down even more than just adding additional fields directly to the Projects table, so it might not be the best option for this scenario.

If you'd like to dive in deeper to your solution's structure and discover the available options and their performance impacts, we'd be happy to do so as part of an implementation package.

Sincerely,

KC