Business objects, subset of collection
in [OOP]
|
From: topmind on 17 Jan 2008 13:42 H. S. Lahman wrote: > >> Yes, they are quite similar. But apropos of your other message, that > >> just reflects that both are based on the relational model. However, the > >> models are quite different because the collection sets are object-based > >> in the AAL but they are table-based for the SQL. The set of invoices and > >> the set of payments examined in the AAL case will usually be much > >> smaller that the corresponding invoice and payment sets in the RDB. > > > > That is a limitation you have to do, because your solution will > > perform too bad otherwise. A relational database on the contrary isn't > > limited to only operate on small amounts of data. > > We do this because using the RDB query model with table-based indices > would be very inefficient for memory-based computing when solving > particular problems. That paradigm is fine for generic data storage and > access but searching large sets sucks for algorithmic processing. Of course one is going to ask what "algorithmic processing" is and for examples. > > 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. That tailoring > is what application developers /do/. The OO paradigm just provides a bit > of help in formalizing that with object-based relationship instantiation. Local tables are great for such also. I just wish more tools supported it well. Vendors abandened table-friendly tools when OOP became the rage, ruining a good thing. Damned fad-chasers! > H. S. Lahman -T-
From: frebe on 17 Jan 2008 14:46 > >>>> But mixing paradigms is usually a very bad idea from an OOA/D > >>>> perspective once one is outside the realm of CRUD/USER processing. > >>>> That's because the data structures needed to optimize the customer's > >>>> problem solution are usually not the same as those needed to optimize > >>>> data storage or display and the 1:1 mapping breaks down. > >>> The database schema should be optimized for the customer's problem > >>> solution. > >> Such optimization utterly defeats the entire relational database model, > >> which is designed to provide data storage and access that in independent > >> of the way the data is used. > > > 1. Do you have any references to support the claim that the > > "relational database model" is designed to provide data storage and > > access that in independent of the way the data is used? > > Pretty much the entire literature of the field. "Data Modeling > Essentials" by Simsion was the first book I took off my shelf. Chapter 1 > has sections on "data reusability", "stability and flexibility", and > "simplicity and elegance" -- all of which address the notion that the > RDB provides data storage that is independent of the use of the data. Then you would not have any problem giving a quote supporting your claim. > > 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. > > 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. > >> The differences between an OO > >> Class Model and a Data Model lie in the way their relational model is > >> constructed, not in whether they are relational models. > > > From Wikipedia ("Relational model"): "The fundamental assumption of > > the relational model is that all data is represented as mathematical n- > > ary relations". Does the apply to an OO class model? > > Of course. Sure... //frebe
From: frebe on 17 Jan 2008 15:19 > >>>> invoiceSet = this -> R1 WHERE (date=20080113) > >>>> FOREACH invoice IN invoiceSet > >>>> // process invoice objects > >>> or > >>> select invoiceid from invoice > >>> where customerid=? and date=20080113 > >>>> paymentSet = this -> R1 -> R2 WHERE (date=20080113) > >>>> FOREACH payment IN paymentSet > >>>> // process payment objects > >>> or > >>> select paymentid from invoice i join payment p on > >>> i.invoiceid=p.invoiceid > >>> where customerid=? and p.date=20080113 > >> Yes, they are quite similar. But apropos of your other message, that > >> just reflects that both are based on the relational model. However, the > >> models are quite different because the collection sets are object-based > >> in the AAL but they are table-based for the SQL. The set of invoices and > >> the set of payments examined in the AAL case will usually be much > >> smaller that the corresponding invoice and payment sets in the RDB. > > > That is a limitation you have to do, because your solution will > > perform too bad otherwise. A relational database on the contrary isn't > > limited to only operate on small amounts of data. > > We do this because using the RDB query model with table-based indices > would be very inefficient for memory-based computing when solving > particular problems. I solve particular problems using "the RDB query model" every day, and I have not noticed it being "very inefficient". > That paradigm is fine for generic data storage and > access but searching large sets sucks for algorithmic processing. SQL databases sucks for searching large data sets, come on... > >> But the 'n' in > >> O(log n) will usually be much smaller in the OO application because the > >> collections are object-based rather than class-based. > > > Lets say you want to find all unpaid invoices. Why would the n be much > > smaller in a OO solution? > > I said, "usually'. You are postulating a class-based search as a problem > requirement. You might think that my example is too extreme, but isn't it good to use a method/tools that doesn't limit you to work on small amounts of data? > Again, did you miss the part where I said the OP might be able to save a > bunch of keystrokes by not doing OO? Where I said that RAD > infrastructures provide a lot of automation that would have to be done > from scratch in an OO approach? No, I just love to see you repeating this disclaimer... > [Note that I also never said one shouldn't take advantage of the RAD > facilities. One should do that in a client-side data access subsystem > where the RDB schema is relevant. But when customizing the problem > solution data structures one needs to provide the access to those data > structures anyway and one needs to do it efficiently through custom > tailoring.] Your main argument seem to be that the performance of a relational databases should be insufficient, compared to your pointer based solution. There are probably many scenarios there a pointer-based solution would perform O(1) and a relational O(log n). But history (and your previous posts in this thread) has showed numerous disadvantages with data management using pointers (network databases), and the benefits with the relational model are obvious. These days, nobody are proposing pointer-based databases, only when it comes to data in RAM, some people are still proposing this. What if RAM isn't big enough for the data needed in the processing? Recently I worked with an (OO) application loading data from database at startup. I guess I don't have to tell you the problems the applications faced. One was a startup-time of +6 hours. Another was dirty reads. > A SQL database allows him to construct CRUD/USER applications quickly > because the only problem being solved is data view conversion. That is > exactly what the Form/Query/Table RAD paradigm is designed to largely > automate and it does a good job of it. > > But when you have a problem to solve that requires complex processing of > the data, you have to optimize to the problem and provide custom data > structures. IOW, you are going to have to provide unique access because > the mappings are not the same as in the RDB schema. That's what > application design is all about outside of CRUD/USER contexts. Are producing invoices, "complex processing"? There are scenarios of data processing that are not supported very well by existing index types in current mainstream (SQL) databases. But the major part of all processing done in common business applications, perform very well using SQL databases, without having any custom data structures. What about all COBOL applications out there with extremly simple data structures, relying heavily on SQL statements to do the job. Doesn't they perform well enough? > > Your claim that a relational schema is designed for "data storage that > > is independent of the applications", is debatable. When I design > > schemas, I design them to fit the specific customer problem. Why > > wouldn't I? If you look at the schemas for three different invocing > > applications, you will find three different schemas. There doesn't > > exists any application independent schema for invoices. It all depends > > on the specific customer problem. > > IMO, that is very bad practice for a DBA because it precludes reuse of > the data to solve other, different problems. My databases solves problems for my applications. Between applications, data are exported and imported. > When one creates a Data Model, it should be based on the overall problem > domain rather than specific problems within the domain. If you do that, > then the same schema should be reusable by all the core accounting > applications. One could also say that it only need to be one core accounting application. The question is: How do you define the "overall problem", and the "specific problem". You base almost all your argumentation on such fuzzy terms, which makes everything derived from it rather fuzzy too. //frebe
From: Tegiri Nenashi on 17 Jan 2008 16:57 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. I cringe every time I read a CS paper with algorithms in it. As math folks mildly put it: "computer buffs excell in confusing and unjustifiably complicating things".
From: jimbalo22 on 17 Jan 2008 16:58
Frebe, I have not worked with DataSets for a long time and when I tried this approach to see if it would work better for this application, I almost immediately hit some issues. I posted a question in microsoft.public.dotnet.framework.windowsforms (and adonet), but have not yet received any useful replies. Maybe you can take a stab at it? The subject is "Synced databinding between multiple grids" http://groups.google.com/group/microsoft.public.dotnet.framework.adonet/browse_thread/thread/256cea096611b2f/17cb93811aeac249?lnk=st&q=%22synced+databinding%22#17cb93811aeac249 Thanks, Jim |