SQL
in [OOP]
|
From: frebe on 24 Jan 2006 13:41 >>>How else would you uniquely identify each line for individual access in >>>a text file? >> By a separate index file. Otherwise I would need a linear search to >> find the records/lines I am looking for. > Exactly my point. You are adding another file to form a database that > is consistent with the RDB view. How do you do it without augmenting > the stored data? Flat files can only be used for linear traversal unless you have some sort of external index. Using it the "OO" way would not make any difference. Fredrik Bertilsson http://butler.sourceforge.net
From: Christian Brunschen on 24 Jan 2006 14:24 In article <1138127666.875967.222550(a)g43g2000cwa.googlegroups.com>, frebe <fredrik_bertilsson(a)passagen.se> wrote: >> If we ignore the persistence aspect, what remains is the organization of >> data according to the relational model. That's certainly useful, but it's >> not 'MANY' features. > >Here are my top four non-persistence related features that I use every >day. I think they are very important. >* Queries. Those I'd generally consider to be part of the relational model - the queries are how you access data, perform joins (which are part of the relational model), etc. >* Transactions. Those are definitely useful, but are not specific to databases, neither in general nor specifically relational ones. >* Referential integrity .... has to be maintained somehow: dangling references would be a problem in any system. SQL can prevent you from putting the database into an inconsistent state, true, but you still have to manually keep the references up-to-date, just as in any other system. >* Caching. Caching also isn't specific to RDBMS:es. If you're using a modern OS, you can hardly _avoid_ some level of caching these days, even if you're using flat files! So, all of these things you mention above are, in my view, either direct consequences of the relational model, or features that are not specific to relational databases (and could thus be available to you using a non-relational system for storing and accessing data). Do you strongly disagree? >> Nevertheless, persistence is considered one of the cornerstones of >> RDBMS:es, and one thing that RDBMS:es are expected to offer. >Do do you have anything to back it up with? Not really - only my general experience with databases, which I admit is not _hugely_ extensive. I am willing to be corrected on this point :) Do you have any examples of relational databases that have specific features for non-persistent usage? All the relational databases I've looked at (again, a limited number) appear to put a lot of weight on the persistence aspect. >> However, if you look around, I think you will see that the >> _vast_ majority of uses of databases are, in fact, for _persistent_ >> storage of data. >Only in the OO world. In the rest of the world there are many examples >of the opposite. I'm open to be educated on the subject - please, could you point me at some examples? [ In my experience, even when I was developing procedural systems, in those systems, relational databases where used to work with persistent data. Transient data was generally stored in bespoke data structures in memory. This is without any OO involved. ] >Fredrik Bertilsson >http://butler.sourceforge.net Best wishes, // Christian Brunschen
From: Mikito Harakiri on 24 Jan 2006 16:11 Dmitry A. Kazakov wrote: > On 23 Jan 2006 17:28:12 -0800, Mikito Harakiri wrote: > > > Patrick May wrote: > >> The most common language for manipulating tables is SQL and > >> it is not as powerful as general purpose OO languages. > > > > There are two incorrect assertions here: > > 1. What power do you have in mind, computational power? Then you made > > it sound like it is OO that added more power, while in fact procedural > > programming without object extensions is as powerful as procedural > > programming with them. > > This is true. It cannot be answered without software metrics or an > equivalent. Under power, abstraction power is meant. Which is quite > difficult to measure. In my view a measure could be the type system, i.e. > the ladder value -> type -> types set -> types sets set ... and > completeness of each footstep*. Others use nGL hierarchy. Well, what about extensible DBMS engines, where you can add new type definitions? > > 2. Is SQL really less powerful? What computational feature is exactly > > missing? > > One could point to Turing completeness, but clearly, it isn't a real, > immediate loss. Is SQL Turing incomplete?
From: Patrick May on 24 Jan 2006 16:08 "Mikito Harakiri" <mikharakiri_nospaum(a)yahoo.com> writes: > Patrick May wrote: > > The most common language for manipulating tables is SQL and > > it is not as powerful as general purpose OO languages. > > There are two incorrect assertions here: > 1. What power do you have in mind, computational power? Then you > made it sound like it is OO that added more power, while in fact > procedural programming without object extensions is as powerful as > procedural programming with them. In this context I used "power" in terms of expressiveness and computational capabilities. You are correct in that I did not need to limit the comparison to OO languages. > 2. Is SQL really less powerful? What computational feature is > exactly missing? It is possible to write a database management system with an SQL interface using any general purpose programming language. It is not possible to implement a general purpose programming language in SQL. That's a clear indication that SQL is less capable, and hence less powerful, than a general purpose language. Sincerely, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)
From: Patrick May on 24 Jan 2006 16:54
"topmind" <topmind(a)technologist.com> writes: > Patrick May wrote: > > "topmind" <topmind(a)technologist.com> writes: > > You asked "But how are tables less close to the domain than > > classes, methods, and attributes?" The answer is, they lack > > behavior. The most common language for manipulating tables is SQL > > and it is not as powerful as general purpose OO languages. > > How does not covering the entire behavior spectrum make it "less > close" to the domain? As Mr. Lahman has eloquently pointed out, only CRUD/USER applications map directly to the relational model. Other applications require different models of both data and behavior. Since SQL has a limited support for modeling behavior relative to general purpose languages, by your own admission, it is less capable of reflecting the abstractions of problem domains other than those of CRUD data pipelines. > > Josh Bloch recommends immutability explicity in "Effective > > Java" and gives solid reasons for his position. > > Proliferation of getters and setters violates encapsulation, > > one of the defining characteristics of object technology. > > Some research will show you that OO designs focus on > > behavior, not state. You should also check out the Law of > > Demeter and similar guidelines that provide further evidence > > that excessive use of accessors and mutators is not good OO > > form. > > > > Now, where is your evidence that proliferation of accessors and > > mutators is considered good OO practice? > > One opinion means diddly squat. If you count carefully, without even the need to remove your shoes, you will note more than one generally accepted guideline mentioned above. Further, dismissing well documented and rationally defended positions as "opinion" is a cheap rhetorical trick. Where is your evidence that proliferation of accessors and mutators is generally accepted as good OO practice? > Those who put accessors around everything did it due reading > somebody's mantra, not out of their own will. So you've seen code that claims to be OO while violating the principle of encapsulation. That's more exposure to OO than I suspected you've had, but it doesn't prove your point. While we're on the topic of you producing evidence for your claims, here's a couple from this thread you still haven't supported: > OO is usually crappy at modeling behavior, at least in the biz > domain. OO is only nice when things split up into nice hierarchical > taxonomies. And: > Plus, what such UML models often do is something like: > > method getGreenScarvesCostingLessThan100dollars(...) { > sql = "select * from products where prod='scarves' and color='green' > and price < 100" > return(foo.execute(sql)) > } Are you going to back these up or should we consider them retracted? > > Exactly. You stateed that: > > > > I would note that a lot of the issues you mentioned, such as > > performance, scalability, resiliency, and recoverability can > > be obtained by purchasing a "big-iron" RDBMS such as Oracle > > or DB2. > > > > This is simply not the case in real world systems. The existence > > of legacy systems is just one reason why your "just use a big > > database" approach won't meet NFRs such as performance, > > scalability, resiliency, and recoverability. > > Are you saying your techniques better fit with legacy systems? I am saying that your claim is nonsense. Given the need to integrate legacy systems and third party products, to expose business functionality to a variety of other business systems, to orchestrate various levels of processes and workflows, and meet all the other requirements of enterprise systems, the idea that the NFRs can be met 'by purchasing a "big-iron" RDBMS' is ridiculous. > > The point here is that statements like the one above indicate > > more about the limited types of systems to which you apparently > > have some minimal exposure than they do about good software > > development practice. Experience in this newsgroup has shown that > > attempting to educate you about software outside of your tiny box > > is a waste of time. Hence, I simply point out when you are saying > > more than you think you are, and move on. > > Perhaps because they use argument-from-authority instead of evidence > out of bad habit. When you've supported some of your own claims, demonstrated a willingness and ability to learn from people with more experience, shown some intellectual honesty by admitting when you don't know about a topic or are proven wrong, and have generally refrained from your typical trollish behavior for some convincing amount of time, it may be worth devoting the extensive effort required to educate you. Given your historical behavior, at the moment it would be a waste of time. > You show me clear-cut coded proof, and I will change my mind. No, you won't. You will ignore evidence, deliberately misunderstand clear arguments, drag threads out interminably with off topic comments, continually introduce absurd claims that you fail to support, and basically waste the time of everyone who grabs the tar baby of your discourse. Pointing out your flawed assertions when you make them is a more rational use of time than is trying to have a rational discussion with you. > > I'll type more slowly. There is no mention of ACLs in the > > references I provided. The references I provided show how some > > important security issues are addressed. This demonstrates that > > your claim that '"Security" is mostly just massive ACL tables.' is > > nonsense. > > Okay, I see where this went wrong. I meant security *could* be > implemented by massive ACL tables. No, it cannot. Either you really don't understand this, in which case you should not be commenting on the topic, or Mr. Lahman is correct and you are deliberately attempting to annoy people who do know something about the issue. ACLs stored in database tables don't even begin to address the security needs of large systems. Read the references provided. Sincerely, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML) |