|
From: frebe on 18 Jan 2008 00:00 > > By the way, what is your RAD IDE of choice? > > For the last 20 years before retiring I was an R-T/E guy so the only RAD > problems we saw were support tools for the software process (e.g., > defect tracking). For that mundane stuff I usually used Access. I > haven't looked at the market so I wouldn't know what to use for > something like a web-based POS where one has both networking and server > issues. (There wasn't much around back in the '70s when I was doing IT, > but I'm sure we've come a long way since.) When you say "When I need to solve a CRUD/USER problem I forget about OO and use a RAD IDE", you are talking about MS Access? Since you frequently refer to RAD IDE as the silver bullet for everything that the OO model can't solve, it is a little big surprisingly that the only RAD IDE you have experience from is MS Access. Don't you think there are something between the OO approach and MS Access? Currently there are very few RAD IDE's that actually provide some value in software development. They simply not powerful enough. Instead you have to use a normal programming language and use embedded SQL for data management tasks. The 3GL host language should mainly focus on presentation and communication. The more business logic you can put into views, the cleaner your application will be. Unpaid invoices as an example: create view invoice_balance as select i.invoiceid, i.amount - sum(p.amount) from payment p join invoice i on i.invoiceid=p.invoiceid group by i.invoiceid Using such view, you call "select balance from invoice_balance where invoiceid=?", whereever in your application, reusing the business logic above. //frebe
From: Dmitry A. Kazakov on 18 Jan 2008 03:54 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? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: H. S. Lahman on 18 Jan 2008 11:15 Responding to Frebe... >>> By the way, what is your RAD IDE of choice? >> For the last 20 years before retiring I was an R-T/E guy so the only RAD >> problems we saw were support tools for the software process (e.g., >> defect tracking). For that mundane stuff I usually used Access. I >> haven't looked at the market so I wouldn't know what to use for >> something like a web-based POS where one has both networking and server >> issues. (There wasn't much around back in the '70s when I was doing IT, >> but I'm sure we've come a long way since.) > > When you say "When I need to solve a CRUD/USER problem I forget about > OO and use a RAD IDE", you are talking about MS Access? Since you > frequently refer to RAD IDE as the silver bullet for everything that > the OO model can't solve, it is a little big surprisingly that the > only RAD IDE you have experience from is MS Access. Don't you think > there are something between the OO approach and MS Access? To clarify, when I refer to RAD IDE I also include the object-based "canned" infrastructures in things like .NET and J2EE that support the 1D Presentation/Business/Data models. Those are certainly between Access and an OO development. > > Currently there are very few RAD IDE's that actually provide some > value in software development. They simply not powerful enough. > Instead you have to use a normal programming language and use embedded > SQL for data management tasks. The 3GL host language should mainly > focus on presentation and communication. The more business logic you > can put into views, the cleaner your application will be. Unpaid > invoices as an example: > > create view invoice_balance as > select i.invoiceid, i.amount - sum(p.amount) > from payment p > join invoice i on i.invoiceid=p.invoiceid > group by i.invoiceid How is this different than a VBA routine tied to a predefined event in Access and stored by Access for reuse? The VBA syntax will be very similar since it is designed (i.e., has specialized constructs) to be compatible with and easily converted to SQL. > > Using such view, you call "select balance from invoice_balance where > invoiceid=?", whereever in your application, reusing the business > logic above. I am missing the point. This seems like basic modularization that goes bas to function libraries under SA/D/P. Different development environments will have different mechanisms, but they all do the same thing. (The OOP-based agile processes argue that the primary goal of refactoring is to eliminate code duplication and ensure reuse.) -- There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: frebe on 18 Jan 2008 11:59 > >>> By the way, what is your RAD IDE of choice? > >> For the last 20 years before retiring I was an R-T/E guy so the only RAD > >> problems we saw were support tools for the software process (e.g., > >> defect tracking). For that mundane stuff I usually used Access. I > >> haven't looked at the market so I wouldn't know what to use for > >> something like a web-based POS where one has both networking and server > >> issues. (There wasn't much around back in the '70s when I was doing IT, > >> but I'm sure we've come a long way since.) > > > When you say "When I need to solve a CRUD/USER problem I forget about > > OO and use a RAD IDE", you are talking about MS Access? Since you > > frequently refer to RAD IDE as the silver bullet for everything that > > the OO model can't solve, it is a little big surprisingly that the > > only RAD IDE you have experience from is MS Access. Don't you think > > there are something between the OO approach and MS Access? > > To clarify, when I refer to RAD IDE I also include the object-based > "canned" infrastructures in things like .NET and J2EE that support the > 1D Presentation/Business/Data models. Those are certainly between Access > and an OO development. In what way does J2EE support 1D Presentation/Business/Data? > > create view invoice_balance as > > select i.invoiceid, i.amount - sum(p.amount) > > from payment p > > join invoice i on i.invoiceid=p.invoiceid > > group by i.invoiceid > > How is this different than a VBA routine tied to a predefined event in > Access and stored by Access for reuse? If you show the VBA routine, I can tell the difference... The great thing with views is the fact that you can reuse this piece of relational algebra. Lets say I want to find all over due, unpaid invoices for creating reminders. select i.invoiceid from invoice i join invoice_balance ib on i.invoiceid=ib.invoiceid where ib.balance > 0 and datediff(now(), i.duedate) >= 10 How would your solution look like? Collection with all over due invoices automatically updated every 24 hour? > The VBA syntax will be very > similar since it is designed (i.e., has specialized constructs) to be > compatible with and easily converted to SQL. Are you saying that Visual Basic and SQL has similar syntax? If yes, please show it to me. > > Using such view, you call "select balance from invoice_balance where > > invoiceid=?", whereever in your application, reusing the business > > logic above. > > I am missing the point. This seems like basic modularization that goes > bas to function libraries under SA/D/P. Different development > environments will have different mechanisms, but they all do the same > thing. (The OOP-based agile processes argue that the primary goal of > refactoring is to eliminate code duplication and ensure reuse.) Yes, you almost got it. Views corresponds to functions or classes. It is all about modularization. //frebe
From: H. S. Lahman on 18 Jan 2008 12:10
Responding to Frebe... >>> 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. You want me to quote the six pages comprising those three subsections in an email??? If you want a pithy one-liner, I'll go with Simsion's section heading, "data reusability". 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. > >>> 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. > >>> 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. -- There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH |