views:

56

answers:

4

I have a table (A) that lists all bundles created off a machine in a day. It lists the date created and the weight of the bundle. I have an ID column, a date column, and a weight column. I also have a table (B) that holds the details related to that machine for the day. In that table (B), I want a column that lists a sum of weights from the other table (A) that the dates match on. So if the machine runs 30 bundles in a day, I'll have 30 rows in table (A) all dated the same day. In table (B) I'll have 1 row detailing other information about the machine for the day plus the column that holds the total bundle weight created for the day.

Is there a way to make the total column in table (B) automatically adjust itself whenever a row is added to table (A)? Is this possible to do in the table schema itself rather than in an SQL statement each time a bundle is added? If it's not, what sort of SQL statement do I need?

Wes

+1  A: 

If you need the sum (or other aggregate) in real time, add a trigger on table A for INSERT, UPDATE, DELETE which calculates the sum to be stored in B.

Otherwise, add a daily job which calculates the sums.

Please specify which database you are using.

devio
A: 

This can be accomplished via Triggers which are little bits of code that execute whenever a certain action (insert/update/delete) happens on a table. The syntax is varies by vendor (MySQL vs. Oracle) but the language is typically the same language you would write a stored procedure in.

If you mention the DB type I can help with the actual syntax

DrewM
I'm not positive what my DB type is, but I am using Microsoft SQL Compact Edition with whatever defaults it has set. The information is being stored in an .sdf file.
Wesley
+1  A: 

Are you sure that you don't want to pull this information dynamically rather than storing it in a separate table? This seems like an indirect violation of Normalization rules in that you'll be storing the same information in two different places. With a dynamic query, you'll always be sure that the derived information will be correct without having to worry about the coding and maintenance of triggers.

Of course, if you are dealing with large amounts of data and query times are becoming an issue, you may want the shortcut of a summary table. But, in general, I'd advise against it.

Mark Brittingham
This is a valid point and I may have to reconsider this at some point. But as of right now, the needs to access the detailed bundle weights is very very limited. Nearly every interaction I'll be doing in this database will involve a daily total. I figured it would be a good idea to store that information for easy access rather than dynamically calculating this every time.
Wesley
+4  A: 

It would be a mistake to do so unless you have performance problems that require it.

A better approach is to define a view in the database that will aggregate the daily bundles by machine:

 CREATE VIEW MachineDailyTotals
     (MachineID, RunDate, BundleCount, TotalWeight)
 AS SELECT MachineID, RunDate, COUNT(*), SUM(WeightCol)
 FROM BundleListTable
 GROUP BY MachineID, RunDate

This will allow you to always see the correct, updated total weight per machine per day without imposing any load on the database until you actually look at the data. You can perform a simple OUTER JOIN with the machine table to get information about the machine, including the daily total info, without having to actually store the totals anywhere.

Larry Lustig
A view is really the way to go here.
Andrew Medico
This is a comment I left to a similar answer:This is a valid point and I may have to reconsider this at some point. But as of right now, the needs to access the detailed bundle weights is very very limited. Nearly every interaction I'll be doing in this database will involve a daily total. I figured it would be a good idea to store that information for easy access rather than dynamically calculating this every time.
Wesley
@Wesley: Why do all the hard work now only to reconsider later and rip out the stuff you did? This technique is more reliable and can be completely implemented in ten minutes. Writing and testing the triggers will probably take a couple of hours, at least, and slow down your application.
Larry Lustig
Yes, this does seem like the best solution. I'll need to look into upgrading my SQL software, because Microsoft's SQL Server Compact Edition doesn't support views. It looks like Express edition does. Any other suggestions?
Wesley
+1 - You know, I suggested that you avoid creating another table but I didn't go the next step to suggest a view (which is odd given that I define views for this exact reason in my system). So...*this* is the right answer and I'd highly recommend that you follow Larry's advice here.
Mark Brittingham
My apologies, I've never used CE and I'm shocked to find that it doesn't support views. I work in a lot of databases and many of them have odd things missing from their SQL support, but I don't think I could go a day without views. My ultimate goal is a database composed entirely of views, without any tables!
Larry Lustig