data structure complexity vs. application maintenance cost
in [OOP]
|
Prev: Call for Papers Reminder: The World Congress on Engineering WCE 2007
Next: Call for Papers with Extended Deadline: 2007 International Conference on Computer Graphics and Virtual Reality (CGVR'07), June 25-28, 2007, USA
From: fireball on 23 Feb 2007 05:33 I hope I can express my question..: I need to confront, how data structure complexity implies the cost of coding/maintenance application based on it. It's because I need to argue my principal, he need to focus more on database structure _before we start coding functionalities. Because of deadlines, there is a suggesion, we can simplify database structers after we start writting application. I suggest there is numerously more mony to do so. Any articels, charts, or expert statemets on subject? :)
From: H. S. Lahman on 23 Feb 2007 13:31 Responding to Fireball... > I need to confront, how data structure complexity implies the cost of > coding/maintenance application based on it. First, I am assuming that because of the forum you chose you are doing OO development. Application partitioning is an important feature of the OO paradigm and one usually wants to separate the concerns of persistence from those of the customer problem. (For example, see the Application Partitioning category on my blog.) Second, I am assuming that you are not doing CRUD/USER processing where the application is simply a pipeline converting between the RDB view and the UI view of the data. In that sort of processing one does design the data structures (schemas) first because the RAD IDEs and "canned" layered model infrastructures are abstracted around the RDB view of things (tables & tuples). IOW, the supporting tools are /designed/ to migrate the RDB view to the UI view so they work best that way. > It's because I need to argue my principal, he need to focus more on database > structure _before we start coding functionalities. Because of deadlines, > there is a suggesion, we can simplify database structers after we start > writting application. I suggest there is numerously more mony to do so. If one is not doing CRUD/USER processing, then one wants to solve the customer problem first before worrying about how the data that the solution needs is persisted. That's because the problem solution will be complicated enough so that one does not want to be distracted by persistence issues and because that solution really doesn't care how the data is stored (RDB, OODB, flat files, clay tablets, etc.). An OO problem solution is highly tailored to the problem in hand. That means that the data structures (e.g., objects) will be defined to optimize the solution. In contrast, most data storage mechanisms are designed to provide storage that is independent of particular problems. In fact, the entire relational data model that underlies RDBs is designed around problem-independence. So when solving complex problems one /expects/ the solution and persistence views of the data to be different. So one typically isolates the persistence access in a subsystem that is constructed after the rest of the problem is solved. The interface to that subsystem is based on the problem solution's needs for data and the subsystem exists to convert between the solution view and the persistence view. Then, given that the views are decoupled, it becomes relatively easy to design the persistence view (e.g., RDB schema) that works best. ************* 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: topmind on 23 Feb 2007 15:06 H. S. Lahman wrote: > Responding to Fireball... > > > I need to confront, how data structure complexity implies the cost of > > coding/maintenance application based on it. > > First, I am assuming that because of the forum you chose you are doing > OO development. Application partitioning is an important feature of the > OO paradigm and one usually wants to separate the concerns of > persistence from those of the customer problem. (For example, see the > Application Partitioning category on my blog.) Goddamit! RDBMS are NOT just about persistence. That is a fricken fable! They are semi-standardized attribute and relationship managers. Persisistence is one of many features they offer. Many OO'ers prefer to roll-your-own a-and-r manager, but that is often wastful and bad "reuse". > > Second, I am assuming that you are not doing CRUD/USER processing where > the application is simply a pipeline converting between the RDB view and > the UI view of the data. In that sort of processing one does design the > data structures (schemas) first because the RAD IDEs and "canned" > layered model infrastructures are abstracted around the RDB view of > things (tables & tuples). IOW, the supporting tools are /designed/ to > migrate the RDB view to the UI view so they work best that way. > > > It's because I need to argue my principal, he need to focus more on database > > structure _before we start coding functionalities. Because of deadlines, > > there is a suggesion, we can simplify database structers after we start > > writting application. I suggest there is numerously more mony to do so. > > If one is not doing CRUD/USER processing, then one wants to solve the > customer problem first before worrying about how the data that the > solution needs is persisted. That's because the problem solution will be > complicated enough so that one does not want to be distracted by > persistence issues and because that solution really doesn't care how the > data is stored (RDB, OODB, flat files, clay tablets, etc.). > > An OO problem solution is highly tailored to the problem in hand. That > means that the data structures (e.g., objects) will be defined to > optimize the solution. In contrast, most data storage mechanisms are > designed to provide storage that is independent of particular problems. > In fact, the entire relational data model that underlies RDBs is > designed around problem-independence. So when solving complex problems > one /expects/ the solution and persistence views of the data to be > different. This is mostly unproven bullshit. I don't have to tolerate these fables. How the hell are navigational (OO) structures more "optimized for the solution" than relational? How are you measuring? Subjective feelings? Bzzzzzt! Those don't count here. > > So one typically isolates the persistence access in a subsystem that is > constructed after the rest of the problem is solved. The interface to > that subsystem is based on the problem solution's needs for data and the > subsystem exists to convert between the solution view and the > persistence view. Then, given that the views are decoupled, it becomes > relatively easy to design the persistence view (e.g., RDB schema) that > works best. > > > ************* > There is nothing wrong with me that could > not be cured by a capful of Drano. > > H. S. Lahman -T- oop.ismad.com
From: JXStern on 25 Feb 2007 14:46 On 23 Feb 2007 12:06:06 -0800, "topmind" <topmind(a)technologist.com> wrote: Let me agree and expand. >Goddamit! RDBMS are NOT just about persistence. That is a fricken >fable! They are semi-standardized attribute and relationship managers. >Persisistence is one of many features they offer. Many OO'ers prefer >to roll-your-own a-and-r manager, but that is often wastful and bad >"reuse". A database is an a&r manager like a compiler is a text processor. That is, a database is more than an a&r manager, it is a data model manager, like a compiler is a program translator. OO'rs generally are happy to use existing compilers, but inexplicably want to grow their own DBMS's, or degrade their use of an RDBMS to little more than a text editor with a load and save mechanism. >This is mostly unproven bullshit. I don't have to tolerate these >fables. How the hell are navigational (OO) structures more "optimized >for the solution" than relational? How are you measuring? Subjective >feelings? Bzzzzzt! Those don't count here. Well, it's a double fable. Most OO code today uses one or another gigantic framework of GUI/page management, yet OO'rs continue to view their work as producing customized components on a blank page rather than an assembly and manipulator of the framework. They then fail to view nonprocedural SQL or stored procedure work in the same light. I dunno, apparently people's brains just aren't big enough to hold the two paradigms closely enough to understand the parallels. Massive and repeated reinvention of the wheel results, with most of the efforts coming up with stuff that is less than exactly round. Heck, my current gig, I just discovered they assembled their servers on 100% RAID5 storage, talk about not appreciating anything but the grossest parameters of "persistence"! J.
From: Daniel Parker on 27 Feb 2007 12:09
On Feb 23, 1:31 pm, "H. S. Lahman" <h.lah...(a)verizon.net> wrote: > > So one typically isolates the persistence access in a subsystem that is > constructed after the rest of the problem is solved. The interface to > that subsystem is based on the problem solution's needs for data and the > subsystem exists to convert between the solution view and the > persistence view. Then, given that the views are decoupled, it becomes > relatively easy to design the persistence view (e.g., RDB schema) that > works best. I have to concur with Topmind's and JXStern's comments. It's bad advise, in general, to build up a complete representation of data in the application's space, with code, along the lines suggested here. The RDBMS is a tool for managing data access. It goes far beyond persistence, it's scalable and fault tolerant in the way that many home grown approaches are not, and provides a logic based querying capability that is richer than the typical home grown code based filter. Managing large amounts of state in the application is not usually a good idea, there are tools for that. Generally speaking, the idea in software assembly these days is to leverage tools, where appropriate. Best regards, Daniel |