Business objects, subset of collection
in [OOP]
|
From: jimbalo22 on 18 Jan 2008 12:22 Frebe, You got my attention earlier with your statements, but seem unable to apply your theories to the problem at hand. Would you mind backing up your theories with some advice on how to apply them to this scenario: The app is for scheduling payments of invoices and has three grids (regular DataGridViews): A Vendor grid showing a summary view of each vendor (with total Due, etc.) An Invoice grid listing all invoices for the selected vendor (including a total amount of payments scheduled for each invoice) A Payment grid listing all payments scheduled for the selected Invoice. Any payments added / removed or modifed in the payment grid (or mass- updated via code) needs to be reflected instantly in the other two grids. Note that the vendor grid (parent) is based on the same DB table as the invoice grid (the children), but the vendor grid is a summary view and the invoice grid is a detail view. The DB tables are: Invoice (VendNo, InvNo, DueDate, Amount) Payment (VendNo, InvNo, SeqNo, PayDate, PayAmount) The Vendor Grid should contain the equivalent of this simplified SQL statement: SELECT Invoice.VendNo, SUM(Invoice.BalDue) as TotalDue, SUM(Payment.PayAmount) as TotalPay FROM Invoice LEFT OUTER JOIN Payment ON Invoice.VendNo = Payment.VendNo AND Invoice.InvNo = Payment.InvNo GROUP BY Invoice.VendNo I could of course do this as a view on the DB server and use that for the vendor grid and use the Invoice table for the Invoice grid, but how do you keep them in sync when payments are added / deleted or modified from the invoices? Would I have to persist the data to the DB and rebind the grids? (too slow) Thanks, Jim
From: Tegiri Nenashi on 18 Jan 2008 12:57 On Jan 18, 12:54 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > On Thu, 17 Jan 2008 13:57:11 -0800 (PST), Tegiri Nenashi wrote: > > On Jan 17, 8:42 am, "H. S. Lahman" <h...(a)pathfindermda.com> wrote: > >> The emphasis on avoiding large searches goes back to before Nicolas > >> Wirth's "Programs = Algorithms + Data Structures". When solving complex > >> algorithm problems one /always/ tailors data structures to minimize such > >> searches based on unique features of the problem in hand. > > > This citation is regressive in the context of database management. > > Remember, if you have a problem and two approaches -- algebraic and > > algorithmic one -- the algebraic one always reigns superior. > > Algebraic vs. algorithmic? Did you mean declarative vs. imperative? Take for example: http://citeseer.ist.psu.edu/329441.html at the second page the authors discuss why they favor algebraic approach. Database management field matured to the point where application programmer never have to think in terms of algorithms. One specifies how to get the data in terms of algebraic expressions, and not how to chase the pointers and sort the result set. One specifies constraints algebraically as equations. You may notice that the 6 operations in the relational agebra sound as too many, and indeed RA could be reduced to a nicer algebraic structure, but in practice select-project- join proved to be an extremely intuitive set of operations for everyday programmer.
From: S Perryman on 18 Jan 2008 13:12 Tegiri Nenashi wrote: > On Jan 18, 12:54 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> TN>This citation is regressive in the context of database management. TN>Remember, if you have a problem and two approaches -- algebraic and TN>algorithmic one -- the algebraic one always reigns superior. >>Algebraic vs. algorithmic? Did you mean declarative vs. imperative? > Take for example: > http://citeseer.ist.psu.edu/329441.html > at the second page the authors discuss why they favor algebraic > approach. Thank you. You confirmed and answered Dmitrys' question. > Database management field matured to the point where application > programmer never have to think in terms of algorithms. One specifies > how to get the data in terms of algebraic expressions, and not how to > chase the pointers and sort the result set. Defining solutions declaratively using mathematical notions is something that people often often do. Because such defs do not imply implementation. In Ansa/ODP speak, this would be known as a *computational* viewpoint. > One specifies constraints algebraically as equations. Which then gets converted into embedded SQL etc (ie an *implementation* ) . Or "pointers" and "result set" . Or (you get the idea) ... Regards, Steven Perryman
From: frebe on 18 Jan 2008 13:42 > You got my attention earlier with your statements, but seem unable to > apply your theories to the problem at hand. Would you mind backing up > your theories with some advice on how to apply them to this scenario: > > The app is for scheduling payments of invoices and has three grids > (regular DataGridViews): > A Vendor grid showing a summary view of each vendor (with total Due, > etc.) > An Invoice grid listing all invoices for the selected vendor > (including a total amount of payments scheduled for each invoice) > A Payment grid listing all payments scheduled for the selected > Invoice. > > Any payments added / removed or modifed in the payment grid (or mass- > updated via code) needs to be reflected instantly in the other two > grids. > > Note that the vendor grid (parent) is based on the same DB table as > the invoice grid (the children), but the vendor grid is a summary view > and the invoice grid is a detail view. > > The DB tables are: > Invoice (VendNo, InvNo, DueDate, Amount) > Payment (VendNo, InvNo, SeqNo, PayDate, PayAmount) > > The Vendor Grid should contain the equivalent of this simplified SQL > statement: > SELECT Invoice.VendNo, SUM(Invoice.BalDue) as TotalDue, > SUM(Payment.PayAmount) as TotalPay > FROM Invoice LEFT OUTER JOIN Payment ON > Invoice.VendNo = Payment.VendNo AND > Invoice.InvNo = Payment.InvNo > GROUP BY Invoice.VendNo > > I could of course do this as a view on the DB server and use that for > the vendor grid and use the Invoice table for the Invoice grid, but > how do you keep them in sync when payments are added / deleted or > modified from the invoices? Would I have to persist the data to the > DB and rebind the grids? (too slow) After adding a payment, you obviously need to refresh the grids. How many millis does this take? How many millis does it take to execute the SQL? What is your time constraint? //frebe
From: frebe on 18 Jan 2008 13:47
> It is trivial to develop a schema tailored to a > specific application that will be unusable by another application > solving a different problem and needing the same data. It is also trivial not to do. > >>> Do you have references to a definition of CRUD/USER processing? If we > >>> don't have a working definition, we use of the term seem to be rather > >>> pointless. > >> Google it. You'll find plenty references to CRUD and USER acronyms. > > > I did. But didn't find any definition that could be useful for telling > > if an application is CRUD or not. But obviously you would not have any > > problem providing such definition. > > If the primary tasks of the application are the acronym activities, it > is CRUD/USER. Order entry for a POS system is CRUD/USER. If the acronym > activities are peripheral to the problem being solved, the application > is not CRUD/USER. The forecasting, transportation, and other functions > of an inventory control system are not CRUD/USER. Is this CRUD? select i.invoiceid from invoice i join payment p on i.invoiceid=p.invoiceid group by i.invoiceid having sum(p.amount) < i.amount and datediff(now(), i,duedate) >= 10 > >>> How do you apply 2NF to your classes? > >> The same as you do. Every non-identity responsibility must be a simple > >> domain (1NF) and must be fully dependent on the object identity. > > > "each nonkey attribute in the relation must be functionally dependent > > upon the primary key." > > > Object identity is not the same thing as a primary key. > > OTOH, a primary key is a tuple identity. They are semantically the same > thing in the RDM context. The primary key is part of the tuple. Object identity (RAM pointer) is not. //frebe |