Implementing a basic business application using Sharepoint 2013

Question

I'm currently working a project where I'd like to create a small application to compute spare parts criticality (for the maintenance department). Something based on Excel files already exist but isn't fully automated nor multi-users. I thought I could rely on Sharepoint lists and workflows to build something better. However, after reading quite a few tutorials / msdn docs, I still struggle to get things done.

In my application, there are basically 4 entities: Sines, Machines, Functions, Parts. Sites contains machines and machines have functions (one to many relationship). Functions require parts to work (many to many relationship): Site(0,N)---(1,1)Machine(1,N)---(1,1)Function(1,N)---(1,N)Parts

In order to store information about these entities, I thought about creating 5 lists: one for each entity, and a part - function association list.

Each entity has its own criticality. Machines, sites and functions criticality can be computed based on their own properties. This can be done easily using a sharepoint calculated field. However, parts criticality depends directly on the criticality of the most critical function it belongs to and on the criticality of the machine that has this function: Machines criticality + function criticality => part criticality. This is where things get difficult for me: I cannot find an easy way to do that. If I was using an SQL db, I could more easily get the function and machines criticality (with joins), but can I do that within a workflow using CAML ? Also, items' criticality should be computed again each time a user update / add information.

Is it a good idea to use Sharepoint for this kind of application ? If so, can you help me with this ?

Thanks a lot, Sébastien.

Answer 1

I realise this thread is a bit dated at this point, but I figured I'd give it a shot in case anyone else was interested.

I come from an ASP.Net background; whenever I'm faced with developing a business application I'm constantly asking myself the question of whether I should set it up with Sharepoint or just go with a regular web app. Most of the time, I do decide to go with Sharepoint because there are a lot of great features it supports OOTB, such as versioning and workflows.

One thing that I find a bit frustrating is the way it treats relationships. 1-N is okay with multi-value lookups up to a certain point, but I'm not terribly happy with the way it violates first normal form. That's something to think about, especially if your data model is complex and you're using calculated values.

The nice thing about Sharepoint 2013, though, is that it's much more jQuery friendly. Datasheet view (now known as Quick Edit) is no longer an ActiveX component and so you should in principle be able to enrich your users' experience by splicing in your own javascript / jQuery functionality. I would highly recommend that you take a look at Marc Anderson's excellent SPServices library for inspiration as well as the Bootstrap for Sharepoint project. These should help get you where you need to go!