too much OOP ?
in [OOP]
|
Prev: Should class code access private members or public wrappers for those private members?
Next: Should class code access private members or public wrappers forthose private members?
From: Dmitry A. Kazakov on 4 Jan 2008 04:27 On Thu, 3 Jan 2008 21:17:54 -0800 (PST), frebe wrote: >>> Who's mindset are you talking about, mine? Regardless the mindset, do >>> you think it is a mistake to use SQL databases in applications for >>> accounting, invoicing, inventory management, etc? >> >> That depends on the functional and non-functional requirements of each >> concrete system. The two basic ideas - of separation of data from semantics >> (meaning) and of client-server architecture are ugly remnants of deep past. > > So building an application for inventory management without an > relational database is actually an option for you? I must see the requirements first. If they do not contain "shall use MS Access," then I would certainly consider this option. >>> Would it be better >>> to use some other kind of database instead or implement the data >>> management logic in the application instead? >> >> If you can factor out these accounting etc as an abstraction, then do it. I >> just don't see why it should be "database." Call it "accounting subsystem." >> There is no "data management logic," there is only logic of "accounting." >> This logic is implemented by the program. Who runs the program is of no >> interest. > > Don't you realize that by abstracting "data management" logic, one can > create components (database engines) that handles this logic in a > generic way. At least you would use some low-level data management > components like arrays and maps? Relations are a more high-level way > of doing it. > > It sound like you want to write all logic from scratch? Wouldn't you > benefit from pre-made reusable components? I am vehemently for reusing containers. I am against equating the logic of some specialized class of containers (in this case RA+persistence+concurrency+SQL-interface=SQL database) to the logic of an application. If you try to express all application logic exclusively as one of containers, to think it as containers, then we are exactly where this discussion started. It is low-level when it works, otherwise it doesn't... >> Others >> quietly create their *libraries*. They might call them "engine", >> "middleware", "framework", but show nothing alike that manic disorder the >> former suffer... (:-)) > > What libraries are you suggesting instead of a SQL database? Please > show me some example. There exist lots of container libraries. I see no need in a special language in order to implement RA at the library level. There might exist issues of making the syntax sugar sweeter (for returned tuples etc). But that is irrelevant, after all SQL is far uglier than anything the most poorly designed library could ever present... Now I have a question to you. Why don't you implement RA (as it has to be in your opinion) at the library level in some decent OOPL? Make it in several variants with concurrency and persistency support as options. I bet OO folks will embrace it. That dead DB horse you'll sell to no one. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: frebe on 4 Jan 2008 05:06 > >> Others > >> quietly create their *libraries*. They might call them "engine", > >> "middleware", "framework", but show nothing alike that manic disorder the > >> former suffer... (:-)) > > > What libraries are you suggesting instead of a SQL database? Please > > show me some example. > > There exist lots of container libraries. Please point out one library that could be used instead of a SQL database for an inventory management application? > I see no need in a special > language in order to implement RA at the library level. Just show one example of a RA library, please. > There might exist > issues of making the syntax sugar sweeter (for returned tuples etc). But > that is irrelevant, after all SQL is far uglier than anything the most > poorly designed library could ever present... I think we all agree that SQL isn't the most beautiful language. Even if the standardization issue is important, I think there are room for more than one family of relational languages. What do you think of Tutorial D? > Now I have a question to you. Why don't you implement RA (as it has to be > in your opinion) at the library level in some decent OOPL? Actually I once did (http://butler.sf.net). But later I realized that I was just reinventing the wheel (that wasn't really round). Using SQL directly is far more powerful than building a complex class model. > Make it in > several variants with concurrency and persistency support as options. I bet > OO folks will embrace it. If this should be done without a database back-end, you are simply writing a new database engine. If you are using a database back-end, you are just putting a procedural interface on top of the database, loosing a lot of the power with a 4GL. A lot of people have tried making an OO interface on top of a relational database (Hibernate, JDO, EJB, Rails) and they have not been very successful. Why doesn't you show an OO API that could be used on top of, or instead of a relational database, and that would be useful for example inventory management applications. > That dead DB horse you'll sell to no one. Are your observation of the current software industry, that SQL databases are dead? //frebe
From: Dmitry A. Kazakov on 4 Jan 2008 09:59 On Fri, 4 Jan 2008 02:06:31 -0800 (PST), frebe wrote: >>>> Others >>>> quietly create their *libraries*. They might call them "engine", >>>> "middleware", "framework", but show nothing alike that manic disorder the >>>> former suffer... (:-)) >> >>> What libraries are you suggesting instead of a SQL database? Please >>> show me some example. >> >> There exist lots of container libraries. > > Please point out one library that could be used instead of a SQL > database for an inventory management application? As I said, write the requirements. The problem of you and the OP is that you don't care to write the requirements down. Instead of that you think in terms of DB records, i.e. an implementation. The rest follows. In OO one would first identify and describe the things and only then say, "hey, that looks much like a relation!" > What do you think of Tutorial D? Too much C to my taste. I admire the Third Manifesto, but I consider it rather as a home work for relational guys to do, before they teach the rest of the world. Let's see how it will evolve. >> Now I have a question to you. Why don't you implement RA (as it has to be >> in your opinion) at the library level in some decent OOPL? > > Actually I once did (http://butler.sf.net). But later I realized that > I was just reinventing the wheel (that wasn't really round). Using SQL > directly is far more powerful than building a complex class model. Huh, know what? Nobody needs a class model of cr*p (read SQL). A model of cr*p is itself cr*p. There is the ODBC mess for those who like such things. You promised me clean RA instead. >> Make it in >> several variants with concurrency and persistency support as options. I bet >> OO folks will embrace it. > > If this should be done without a database back-end, you are simply > writing a new database engine. I don't care about back-ends. I want to see the interface of. How do you implement it, is not my business. >> That dead DB horse you'll sell to no one. > > Are your observation of the current software industry, that SQL > databases are dead? You know, there is [economical] life after death... (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: frebe on 4 Jan 2008 10:14 > >>>> Others > >>>> quietly create their *libraries*. They might call them "engine", > >>>> "middleware", "framework", but show nothing alike that manic disorder the > >>>> former suffer... (:-)) > > >>> What libraries are you suggesting instead of a SQL database? Please > >>> show me some example. > > >> There exist lots of container libraries. > > > Please point out one library that could be used instead of a SQL > > database for an inventory management application? > > As I said, write the requirements. The problem of you and the OP is that > you don't care to write the requirements down. Instead of that you think in > terms of DB records, i.e. an implementation. The rest follows. In OO one > would first identify and describe the things and only then say, "hey, that > looks much like a relation!" You claim that it does exists libraries that can be used instead of an SQL database, and do the job better. You have yet failed to point one single library suitable for example an inventory management application. I will not explain in detail for you what such an application do, you have to use you experience or imagination. Please give some examples of libraries that would be suitable instead of a SQL database. Otherwise we have to assume that such library doesn't exists. //frebe
From: Dmitry A. Kazakov on 4 Jan 2008 10:44
On Fri, 4 Jan 2008 07:14:02 -0800 (PST), frebe wrote: >>>>>> Others >>>>>> quietly create their *libraries*. They might call them "engine", >>>>>> "middleware", "framework", but show nothing alike that manic disorder the >>>>>> former suffer... (:-)) >> >>>>> What libraries are you suggesting instead of a SQL database? Please >>>>> show me some example. >> >>>> There exist lots of container libraries. >> >>> Please point out one library that could be used instead of a SQL >>> database for an inventory management application? >> >> As I said, write the requirements. The problem of you and the OP is that >> you don't care to write the requirements down. Instead of that you think in >> terms of DB records, i.e. an implementation. The rest follows. In OO one >> would first identify and describe the things and only then say, "hey, that >> looks much like a relation!" > > You claim that it does exists libraries that can be used instead of an > SQL database, and do the job better. Which job? Describe it in the form of requirements. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |