I don’t feel that one option is going to be the best option for every situation. The one you choose will depend on your use case, and what you want to get out of the system once it’s built.
For my core contact base, I have two tables. I want to not only track people separately from companies, but also see who I know at various companies, so I link people to the places they work. This allows me to look at a record on the [Companies]
table and see at a glance who works there. On the people table, I’m also tracking a lot of personal information like birthday, anniversary, relationship, etc. I wouldn’t want those fields on a table where I’m tracking companies. In the end, there are numerous reasons I want to keep them separate.
In my business base, though, where I’m tracking work for clients, it’s set up with a single table. In that situation, the single-table setup works fine because I’m not tracking nearly as much individual info, so I can merge it all into one table.
Thanks to the new sync features added this morning, though, I’m beginning to redesign both tables so that I can sync from my core contacts base. However, I’ll still have separate tables for companies and people in my core base, and a single table in my business base, which will sync from the core [Companies]
table.
While there is a “best” choice for some things, base design should be driven by your needs and project requirements. I don’t feel that there’s a clear “best” option when comparing single-table vs two-table options for a CRM, at least in terms of which option will always be the best. In other words, the question shouldn’t be, “Which choice is the best?” Instead, I feel that it should be, “Which choice is the best for my current needs?” As your needs change, you may find the answer changing, and that’s okay.