Business objects, subset of collection
in [OOP]
|
From: frebe on 19 Jan 2008 01:54 > > I don't think you should have a grid showing all invoices for one > > vendor. It is not practical in the GUI. > > The invoices shown are for the selected vendor AND day. Fine. If the set of invoices in the grid are limited, it wouldn't take very long time to reposition the cursor. But how long does it take to execute the SQL query? Without the metrics, it is impossible to tell if the solution works or not. > Vendor grid: Contains various levels of summary info for ALL invoices > and scheduled payments for each vendor. I doubt that select vendorid, sum(amount) from invoice group by vendorid would take too long time. And if it do, you should use materialized views. If your database doesn't support that, the last resort would be to create a new redundant column in the vendor table, containing the sum of all invoice amounts. Obviously this would introduce integrity problems, and should only be considered if absolutely necessary. > > What about payments made from other client computers? Are they > > reflected instantly too? > > Payments are only scheduled by one person. In a multi-user > application, there would obviously have to be some persistance to a > shared medium (RDB or similar). If you are building a single-user application, it is easier to live without a database. When you say "persistance", are you talking about writing to disk? Calling insert into payment (invoiceid, date, amount) values ... has very little to do with persistence. If, when or how the database writes something to disk, is controlled by the database. //frebe
From: jimbalo22 on 19 Jan 2008 02:02 Frebe, > What about payments made from other client computers? Are they > reflected instantly too? Another note & question on this: Using business objects, it is very easy to persist any "dirty" objects to the DB, but I do have a question on how other users would be notified of such changes. In an environment like MS Access, this is not much of a problem since you are working in a "data-connected" mode, but when you are working with disconnected datasets or collections of business objects it raises some questions for me. Let's assume my app is a multi-user application. If user A and user B is viewing payments for the same day and user A adds or changes some payments for that day - what would be an efficient way for B's grids to be updated with this new data? Jim Ps. Of course you would also have to put some kind of locking mechanism in place to prevent modification of the same record by two users at the same time, but that would be a separate issue.
From: jimbalo22 on 19 Jan 2008 02:13 > If you are building a single-user application, it is easier to live > without a database. The app is not single user, but the function of scheduling payments is. But even so, without a DB where do you store the data the application is working with? > When you say "persistance", are you talking about writing to disk? > Calling > insert into payment (invoiceid, date, amount) values ... > > has very little to do with persistence. If, when or how the database > writes something to disk, is controlled by the database. With persistence I mean the writing of the data from the business objects or dataset to the DB (regardless of caching mechanisms in the DB, OS, raid controller or HDDs that might delay the data actually hitting the platters). Jim
From: frebe on 19 Jan 2008 02:19 > > What about payments made from other client computers? Are they > > reflected instantly too? > > Another note & question on this: > Using business objects, it is very easy to persist any "dirty" objects > to the DB, As well without business objects: insert into payment values (4, '2008-01-19', 500) or update payment set amount=600 where invoiceid=4 and date='2008-01-19' > but I do have a question on how other users would be > notified of such changes. Triggers > In an environment like MS Access, this is > not much of a problem since you are working in a "data-connected" > mode, but when you are working with disconnected datasets or > collections of business objects it raises some questions for me. > > Let's assume my app is a multi-user application. If user A and user B > is viewing payments for the same day and user A adds or changes some > payments for that day - what would be an efficient way for B's grids > to be updated with this new data? In most applications I have seen, user B has to press the "Refresh", button in order to see the new payment. But you could use a trigger, that would send a notification message to all subscribing clients. After recieving such notification, the clients would have to refresh the grid. > Ps. Of course you would also have to put some kind of locking > mechanism in place to prevent modification of the same record by two > users at the same time, but that would be a separate issue. If you use locking, optimistic locking should be preferred. //frebe
From: frebe on 19 Jan 2008 02:25
> > If you are building a single-user application, it is easier to live > > without a database. > > The app is not single user, but the function of scheduling payments > is. But even so, without a DB where do you store the data the > application is working with? In a file. As I said, it is "easier" to live without a database when developing single-user applications. I would use a SQL anyway, since it provides a lot of useful features. > > When you say "persistance", are you talking about writing to disk? > > Calling > > insert into payment (invoiceid, date, amount) values ... > > > has very little to do with persistence. If, when or how the database > > writes something to disk, is controlled by the database. > > With persistence I mean the writing of the data from the business > objects or dataset to the DB (regardless of caching mechanisms in the > DB, OS, raid controller or HDDs that might delay the data actually > hitting the platters). Communicating with the DB has very little to do with persistence. I just wanted to check your definition, since it is difficult when one is using ambiguous words. What about metrics for your SQL queries? //frebe |