9

I have a server side developed in c# with entity framework as a provider for SQL server. My server is managing a many to many relation between students and classes.

  public class Student
  {

      public List<Course> Courses
      .
      .
  }

   public class Course
   {
         public List<Student> Students
        .
        .
   }

My client side is developed in angular js with Typscript. To be synchronized with the server, each change in server is pushed to the clients with push notifications (signalr).

For faster response time, my client keeps a sort of database in memory (since the amount of data is not that big, less than 500 records). I keep an array of students and for each one of them also keep array of courses:

     Students: { [studentId: number] : Courses } ={}

And in that object I keep track of all the students and their courses in the client side.

In my application I have the option to remove multiple courses from the entire system. However when doing such thing, when the action is successfully finished on server-side, the processing in the client side becomes heavy when there are many students. That is because I need to iterate through all the removed courses and for each one of them iterate through the entire students array to locate and remove those courses from the students array. (Or iterate the removed courses first and within iterate through the students) - both are heavy and take a while.

Is there a different better design for this? Should I approach this in a different way maybe?

Improve this question
5
  • @peter don't use in-built identifier as your class name Commented Sep 4, 2017 at 7:27
  • You should also include something about your client side model (for angular). Commented Sep 6, 2017 at 11:30
  • Can we see how you are doing the removing part? It shouldn't take long. Commented Sep 6, 2017 at 11:31
  • That is not how you should be solving a N:M relationship. You solve it by adding a association table that turns it into a number of 1:N relationships. When displaying it you will either display it from the Course or the Student side. The side you look at it from is the 1 side. If you want a chaching DB, look if your DBMS has a proper solution for that (like MySQL Express in process DB). Commented Sep 11, 2017 at 15:17
  • We need typescript code that finds and removes courses. It must be horribly inefficient. We need code to point out issue. Commented Sep 13, 2017 at 9:30

6 Answers 6

Reset to default
1
+50

There are a couple of things that come to mind:

  1. Check if you really need the "client side database". Is your backend that slow? Isn't it a premature optimation? I think the complexity of your client program will drop drastically if you remove this part... Just fetch the latest data directly from the server when you need it.

  2. Reload the whole "client database" if big changes happen.

  3. Optimize your "client database". Removing a few hundred items shouldn't take too long... Are you using angular.forEach? It could slow you down significantly. Do you have a few hundred students, but only a few deleted courses? Iterate over the students and only then (inside the iteration) iterate over the deleted courses. Pseudo code:

    for (student in students) {
    for (deletedCourse in deletedCourses) {
         student.removeCourse(deletedCourse);
    }
}

    And not like this:

    for (deletedCourse in deletedCourses) {
    for (student in students) {
         student.removeCourse(deletedCourse);
    }
}

    This way, you would iterate much more and waste time. But it's hard to know without your source code.

In general, you should profile your code and pin down the performance problems. Log to the console how long you needed for different approaches and choose accordingly.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

I came to a realization this was indeed a premature optimization. Respond time in the view is annoying though.. I'll probably just have to implement a paging strategy or something similar in the future
0

Rebuild the array of Students using the updated data in the database after the course is deleted.

Improve this answer

Comments

0

Try storing just the courseIDs inside the student object. That way the performance of the removal part might be manageable.
Have the courses in a separate object and use the map function to get the courses for the student.

Also as the comments suggested, your code for course removal might play a role. So if you can edit your question, it would be helpful.

Improve this answer

Comments

0

Of course there is a better design than just looping through the arrays :)

Essentialy, you need to filter your client side array - i.e. the in-memory database - to exclude (drop) the courses, deleted by the server.

So let's say that the server did its job and deleted some courses, thus sent the deletedOnServer array through SignalR. Then you can call a client side function - e.g. PurgeCourses - and clean your in-memory database. Here is a possible implementation, using native JavaScript's Array.prototype.filter():

// Assuming you client side courses are stored here
var clientSideCoursesArray = [];

function PurgeCourses(deletedOnServer) {
    // To get an array of deleted courses ids:
    var deletedCoursesIds = $.map(deletedOnServer, function (x) { return x.id; });

    clientSideCoursesArray = clientSideCoursesArray.filter(function (prev, cur, idx, arr) {
        var isDeletedByServer = deletedCoursesIds.indexOf(cur.id) !== -1;

        return !isDeletedByServer;
    });
}

However, jQuery.grep() is the recommended way as it is optimized to perform better:

    function PurgeCourses(deletedOnServer) {
        // To get an array of deleted courses ids:
        var deletedCoursesIds = $.map(deletedOnServer, function (x) { return x.id; });

        clientSideCoursesArray = $.grep(clientSideCoursesArray, function (course, index) {
            var isDeletedByServer = $.grep(deletedCoursesIds, course.id).length > 0;

            return isDeletedByServer;
        }, true);
    }

Note the use of the inverted - the fourth argument of $.grep().

Improve this answer

Comments

0

Instead of storing it in client memory, you can store it in a singleton object in webapi server memory and access that. That singleton object can keep checking database for changes in a pre-defined interval of time (a code of very few lines can do that if you use a last modified field with datetime comparison). It can fetch the entire dataset into webapi memory again as singleton.

This would also ensure that each client is working with consistent copy of data.

Improve this answer

Comments

0

You shouldn't store complex data client-side, there is no reason for the client to find disk-space stolen when you have a server. If your server isn't enough fast, you must provide a better one.

The answer is, that you have to make a choice, repeat the process (slowly) in client-side (considering that the final user can have a bad pc and be a lot slower) or just think a good server strategy to process your data.

If you want to reduce server work, you can query data and cache the results till something changes. When a user changes something, you query again the database and keep saving data.

I have a last advice, when you develop something you must think like you are going to provide your product for billions of users. Considering a large amount of users, are you sure that asking for all the data is a good idea?

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.