The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Monolithic tree in a Multiuser environment

Our boss wants us to design our gui around a monolithic tree that will require queries from multiple sources to populate.

Our environment will be about 100 users pounding away, clicks on the tree nodes will require querying various tables the largest of which will be in the neighborhood of 1 million records. The users can add, change and delete the records which produce the tree nodes.

His position is that it is 'easier for the user' to navigate to the information they are interested in.

Our position is that in a multi-user environment we should minimize the data on the client at any given time due to network traffic and synchronization and data validity issues. We would like to filter off the top levels of the tree.

Please help us gather convincing arguments why this not a good idea.
Pressured Designers Send private email
Friday, May 25, 2007
1.  If done right, this could be a very clever way to give users insight into a lot of data.

2.  100 users is not a lot.

3.  A million records is not a lot.

4.  You've given no data for how 'up to date' the tree must remain.  Synchronization issues (race conditions, etc) could slow performance dramatically.

5.  Is it possible for the tree to have links from 'leaf' nodes to 'root' nodes?  If so, you can have recursive links, which would be VERY difficult to debug.
Friday, May 25, 2007
+1 AllanL5

Representing using a tree is a very good idea from the users point of view.  Most of the information in world of business is heirarchial.

I use trees to represent customers, suppliers, items, addresses, contacts, sub accounts etc containing tens of millions of nodes with 100s of users in my accounting software.  No problem for me because I have written my own (non-sql) database engine that can perform complicated queries on hundreds of millions of records in a jiffy.

For synchronization you can add a refresh button that will update the tree only when it is clicked not every time the data changes.  For example when a customer is created it is not immediately added to the tree.  The user has to click the refresh button to repopulate the tree.

You can also populate branches or folders only when they are opened, though I don't have to do this.
Donald Duck
Friday, May 25, 2007
One word of caution: Don't populate the entire tree at once. You only need 2 levels at a time. The current level and the one below (to be able to know if you need the +/- tree expand/collapse.). If you're smart about it, you can even design your own tree that only populates nodes as they become visible.

Think about it. If the tree could potentially hold hundreds of thousands or millions of nodes, you'd be wasting a lot of time processing those million nodes that the user may not even use.

Go for the lazy approach. Only populate tree nodes as you need them.
Friday, May 25, 2007
To add to what Sgt Sausage said, you don't even need to have all the children of a node. For most stock trees, all you need is one child so that you can get the child indicator and then refresh the child list on open. I've used Count(Children) as the child node simply because I was already retrieving the count of children to show in the parent node.
Ron Porter Send private email
Friday, May 25, 2007
Sorry, OP. By using the lazy load approach, there's no compelling barrier to the tree design.
Mike Stockdale Send private email
Friday, May 25, 2007
Sorry, if I was unclear.

Our concern is not dynamic loading of the tree, it is that the  data that makes up the tree is constantly being updated by other users on the system. Because of this we are concerned with the network and server load in trying to keep the expanded, already loaded and visible nodes synchronized with the constantly updated tree node information on the server. Our strategy was to try and limit the amount of data on the client that has to be kept in sync to the smallest set  necessary to perform the current task. The servers in our situation are single machines also running a number of applications other than ours.

I hope this provides a better explanation of our situation.
Thanks All
pressured designers Send private email
Saturday, May 26, 2007
Exactly what kind of data is it, that requires so much synchronization, without that information we can't advise.

Do you mean to say non-dedicated servers are being used to support 100s of users with millions of tree nodes?

What is the smallest set required to perform the current task?  You can just check that if it is in sync, just before data is saved in the server.  If it is not you can put up an edit conflict notice and ask the user to reedit.  That will not require so much synchronization, so you can still use a tree type view.  Anyway without further info about the data we can't advise.

Instead of looking for convincing arguments for why a tree is not a good idea, you should be looking for ideas for how to make it work given the constraints.  I think that is the right attitude to take.

Anyway to view millions of nodes at a time I think you will need a 64 bit client to hold all the data.  That can be a main argument for not doing it(though that is a lame argument).  I also notice that you never said the tree itself will contain a million nodes, only that it is built from tables one of which contains a million records.
Donald Duck
Sunday, May 27, 2007
This sounds like the usual multi-user stale data problem.

Either push out updates to the clients (the Observer pattern), or refresh the data occasionally, either as the result of some user activity (clicked "near" the data in the tree, where you define what is "near"), or a timer, or both.

It all depends on what your user demands are so far as freshness of the data.  If, while actively using the system, they demand it to be always current, you're probably looking at a publish-subscribe model.  If they're OK with clicking refresh after stepping out for coffee, then that's a much easier implementation.
xampl Send private email
Sunday, May 27, 2007
Besides the type and frequency of synchronization you require, is very important to understand the application overall context, like the type of users (casual user or operator( and the type of application (real time operation? site navigation?).

If what users are changing are attributes of the leave nodes, like number of available items or the current stock price, for instance, I would simply show the latest known value and a "refresh" button somewhere in the interface to refresh the item currently on focus.

Now, if the user neeed to monitor the item's attribute to trigger an action (for instance, the price to decide to purcharse), then I will also add a "keep track" button to allow him/her to subscribe to changes using an Observer pattern (or refresh periodically the data). I would not do this my default because maybe the user is not interested in this kind of updates.

If the synchronization affects which items you shown (for instance, new orders that arrive to be processed, then an Observer pattern could be a better approach. In this case the interface should refresh itself each time a new item arrives.

Pablo Chacin Send private email
Monday, May 28, 2007
Remember, you're coding this solution for the users' sakes, not for the sake of technology.  Make the most amazing user interface these users have ever seen and don't worry about what it takes under the covers (at least as your goal).  You end up being a much better software engineer, will learn a mindset that makes it much harder to duplicate your work and will overcome some very tough programming tasks.

Ask yourself what the iPhone would look like if the engineers worried about the load on the phone's CPU.  Granted, you can't do the impossible, but you'll be surprised what you can do once you put your mind to it.

Good luck!
Tuesday, May 29, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz