The help desk software for IT. Free.
Track users' IT needs, easily, and with only the features you need.
I haven't built SharePoint sites and lists for a few years now. Before, I had been working with SharePoint for about 10 years. Now, I recently migrated my company to using Office 365, and as part of that, I want to build some useful tools with SharePoint.
My question surrounds a process I hope to reduce complexity within, and one of the smaller pieces is how we store some client data used for this process.
For each client [or project for each client], we may have multiple possible contacts, and of course each of those could have multiple contact phone numbers.
Rather than creating fields, something like:
Contact1 Contact1Phone1 Contact1Phone2 Contact2 Contact2Phone1 Contact2Phone2 and so onI'd rather setup something like with a standard database of one to many relationships to allow for multiple contacts per client, but if only one contact it only shows one contact and not a bunch of blank/empty fields.
So for that idea, is it possible to setup a few different lists that link together via lookups to get the job done? If I do so, will I introduce possible problems with maintaining or using the list?
Thanks for any guidance on the topic.
I would advise not to try this. You will probably waste time. See Myth2
//www.topsharepoint.com/sharepoint-mythbusters-top-5-misconceptions-of-the-platform
4 Replies
I would advise not to try this. You will probably waste time. See Myth2
//www.topsharepoint.com/sharepoint-mythbusters-top-5-misconceptions-of-the-platform
Thanks for the link.I do need to remember it won't be same as directly using database tables. Not always easy to brush the idea off.
I think I can still do somewhat of what I ultimately want to do, but I need to be very careful in the Lookups so I don't hit performance issues. I'll just need to bridge the planning gap between 2 different ways of thinking. I think I've an idea that should work. If not, I can always drop back to the straight flat one list [still better than current methods].
We would not be dealing with high transactional operations with this project, so hopefully we won't have to worry about issues there, especially if I can somewhat limit the lookups.
Spent so much time trying to get this to work, and then had someone recommend using a web part to make it workable, but I'm not sure that'll work everywhere. So I think I'll probably just go to the annoying long way of listing them so we can just get going:
Contact1 Contact1Phone1 Contact1Phone2 Contact2 Contact2Phone1 Contact2Phone2
At least the data is all there, and I can just customize some of the views to show or not show all the detail. That'll probably be the easiest I guess.
Yeah, I too have tried to fit the square peg into the round hole. You could probably pay a ton of money having someone code a web part, but would it be worth the money? Probably not.
This topic has been locked by an administrator and is no longer open for commenting.
To continue this discussion, please ask a new question.