This really depends on amount of data.

If you have a lot of data, then you could create a separate database and fine-tune it.
But then you have to maintain two databases (EPi and custom one).

If you don't have a lot of data, you'll be fine with DDS.

And don't forget to build a custom caching layer on top of that :)

You can start with DDS and build a service layer (Façade) that will fetch the data from a data source (either EPi or your custom database), cache it and return it to the end user.

If you experience the performance issues, you can always change the data source, and make small changes in the service layer w/o touching the rest of the code.

We are doing pretty simular things in some applications and we always use a own database for those part out of scalability, performance and simplicity reasons.

We often use dapper as a microORM for the communication with the database since it is built for performance and easy to use.

Thanks Dejan and Henrik,

We will potentially have a lot of data, tens of thousands of users saving goodness knows how many links each. Based on what you've both said I think I might go down the custom database route with some caching over the top.

Thanks again,

Mark

If there are so many users I will absolutly go for that solution.

If you have the fortune to have the solution in Framework 4.5 you should look into using Entity Framework and it's async await methods to ensure that no user will have to wait for the other.
I have code to show on how to do it, but not today, say if you want to see, then I will add it on monday

Hi Henrik,

Thanks for that, yes we are using 4.5 and I thought I might use EF. I would be very interested to see that code, thanks,

Mark