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.

Aesthetics of saving 'state' for UI in database

I have a page where I display a list of customers. Depending on 'n' number of factors, a customer can be classified as new or old. The difference of opinion between me and a colleague is about how to get the customer's state(new or old) in the display list.

I suggested that we store the state in a state table in  the database and when the customer's actions qualify the n-th criteria, we change his/her state in the state table.

He suggests that we calculate the state by querying the log tables that has recorded customer actions to see if n-th criteria has been met and then join with the customer table.

I like my solution because I can avoid querying the log table and keep my sql simple.

He likes his solution because he says the 'state' is required only for UI , should be computed when needed and should not be persisted in the database.

What do you guys do when you face such a situation?
Urumi Send private email
Thursday, October 18, 2007
 
 
You have 2 basic choices:
 - your way reduces database access and processing logic (but
 it may require messing the DB and figuring a way do reprocess states at given intervals so they do not unsynchronize with actual data - if that is the case)
 - your colleague's idea means cleaner DB but more DB access and processing costs
The bottom line is that it depends on your context. Is the app under heavy user load and so many requests will need processing again and again? - then maybe your idea is more suitable; otherwise and if you can afford the cost try the other way
AZ Send private email
Thursday, October 18, 2007
 
 
Boy, that's a tough one.  Let me summarize what I think I just read about your colleague's position:

* Don't store customer state in the database because we're going to display it in the UI.

* -DO- store the logs in the database, and read a bunch of them every time we display a web page so that we can derive the state that we're not going to store in the database.

* The logs are completely normalized such that there's no ambiguity at all about what text in the logs triggers a state change.

* If you ever want to know whether a customer is "old" or "new" and you're not the UI that displays the customer list, you're out of luck.  That information is VERBOTEN!!  DO NOT try to use "old" or "new" when you write reports or run a mailing list or compute a discount in your shopping cart.  That's privileged information for use by the UI only.

Is that close?


Ok, that was a little sarcastic.  Sorry - first impression.  If you couldn't tell, I think it makes a ton more sense to store this in the database.  It's a form of customer status, and it is an attribute of the customer.  Events may change the attribute, but the attribute has value before and after the events. 

Deriving the attribute's value by examining the debris of the events is a bad idea.
D. Lambert Send private email
Thursday, October 18, 2007
 
 
"Deriving the attribute's value by examining the debris of the events is a bad idea."

But that's how it's going to be done in either case. The question is whether the value should be cached in the database.
dev1
Thursday, October 18, 2007
 
 
No, not really.  According to the OP, "when the customer's actions qualify the n-th criteria, we change his/her state in the state table".

That's an event.

Combing through the log files (everyone pause and picture the scene from Spaceballs) is examining debris.

But that's just what I think.
D. Lambert Send private email
Thursday, October 18, 2007
 
 
Will an "old" user ever transform back into a "new" user based on subsequent actions? If not (if you can never become new again) then you should store the state in the database. Maybe you should scan the logs so long as the user is new, only setting the state when you see all the required events.

In general, constructing state dynamically is only good when the state can change dynamically. The canonical example (which I don't entirely agree with, but that's another story) is a user's account balance or current bill. Rather than store the current balance in a database table, it is preferred to calculate the current balance based on a sum of activity entries whenever the value is needed. If you were to store the balance in a table you would need to be certain that every process that could add an activity entry also correctly updated the balance entry, which would be MUCH less reliable than just calculating the balance whenever it was needed.
Jeffrey Dutky Send private email
Thursday, October 18, 2007
 
 
Its a property of the customer. It should be in a table as a field. Period.

When you want to display the new/old thing in the UI , it cannot be more than one SQL call. I think its a pretty simple design.
Askar Zaidi Send private email
Thursday, October 18, 2007
 
 
Seems to me you have to ask why you want to be able to tell "new" customers from "old" customers apart.

Most likely there is some (business) logic dependend on this information. That makes it an Customer entity property and should therefore be stored in the database (preferably the Customer table).

UI personalization state of a user would be one of those situations were you deal with non-business entity information. That information could still go into a database, just not the same as were the business data is stored. That way you always have the option to have that UI database close to the UI code (web server) and it would not matter much if that would be somewhat less secure.

Hope it helps.
Marc Jacobi Send private email
Friday, October 19, 2007
 
 
Thanks for all your opinion.
To Dutky's question, the user's status can be reset to new by flipping a switch in the UI. The data displayed is a list of customers in the landing page of the application. I don't like querying and joining with log tables just to figure out the status of a each customer row.
Urumi Send private email
Sunday, October 21, 2007
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz