SQL
in [OOP]
|
From: Mikito Harakiri on 23 Jan 2006 20:28 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. 2. Is SQL really less powerful? What computational feature is exactly missing?
From: topmind on 23 Jan 2006 21:18 Christian Brunschen wrote: > In article <1137996532.423030.167400(a)f14g2000cwb.googlegroups.com>, > topmind <topmind(a)technologist.com> wrote: > >(Part 1 of reply) > > > >Back in my desktop-DB days, I created a lot of temporary tables to do > >things such as joins, filtering, and aggregation for task-specific > >temporary uses. The results were not kept beyond the task/module. Thus, > >I was using DB tools *without* any sense of "lasting". > > > >What would *you* call that? "Persistence" does not apply there. > > You are still using a persistence mechanis; you're just choosing to not > use it for persistence. Again, persistence is one of MANY features of a DB. > A file system is a persistence mechanism; lots of > applications put data into temporary files, which they delete after > they're done with them, sometimes because the available storage in the > filesystem is larger than in main memory (Photoshop, I believe, used to do > that, and maybe still does). This non-persistent use of the filesystem > doesn't make a filesystem any less of a persistence mechanism. They usually do that because the RAM system is limited, not because they want any special features of the the disk system. > > The relational model, and SQL, were developed specifically for persistent > databases. Because RAM was too expensive to consider non-persistence DB's back then. The history is generally irrelavent. I don't care what they did in 1965; It does not change what I do now. LISP was originally a demonstration tool only. The author never set out to create a new production language. But LISP fans are not going to be halted by ancient intentions. > You can use them in a non-persistent manner, but that is > essentially using them contrary to their original intent and purpose. DB's have a lot of features *besides* persistence, and I use DBs for those features. Label DB's whatever you want, but I find those other features useful. You guys are playing a label game. Focus on potential usage, not your pet classification or what happened 50 years ago. > > By the way, how do you create and destroy these temporary tables? i.e., > does the dbms manage their lifecycle for you, creating them as necessary > and removing them when you no longer need them, or do you have to perform > either or both of those steps yourself? Some table-oriented tools auto-delete them, some are RAM-only, while others require manual intervention. (The ideal system would offer all of these options.) > >I agree that code does some things better and DB other things, and one > >uses them *together* in a Yin-Yang fashion. They compliment each other. > > Relational Databases and SQL are tools for the specific task of storing, > accessing, modifying data - they are single-purpose tools (see definitions > below). They are 'general-purpose' _within their specific area_, as they > are not specific to any particular data access/storage/manipulation tasks, > but they are 'general-purpose' _only_ within their _specific_ domain, > which is the storage of data. Bull. > A 'general-purpose' programming language is > one that allows one to write solutions to essentially arbitrary problems > using it, possibly with some specific exceptions (such as, 'python is a > general-purpose programming language, but due to its interpreted nature, > it shouldn't be used for writing interrupt handlers'). You mean "Turing Complete". We have been over this already. I don't expect a query language to be TC to be considered "general purpose" because one can and perhaps should use multiple tools such that one should not EXPECT to have one tool/language do everything. Your "do everything" assumption is a poor assumption. > > One thing to remember is that a RDBMS does _not_ do _anything_ that one > can't do in code on one's own - they are essentially just a pre-written > library, with a little domain-specific language as part of its interface - > whereas on the other hand, _most_ of the things you can fo in _code_, > _cannot_ be done in an RDBMS. Irrelavent. I don't assume a single tool has to carry the entire load of an app. > >> > A hammer is a general purpose tool, but that does not mean one is > >> > supposed to ONLY use a hammer. You need to clarify your working > >> > definition of "general purpose", and then show it the consensus > >> > definition for 4GL. > >> > >> huh**2?!? A hammer is not a general purpose tool by any stretch of the > >> imagination. > > > >Okay, then what is a "general purpose tool"? If I was going to put > >together a tool box for a trip where the mission details are not given > >ahead of time, I would certainly pack a hammer. > > Yes, but you wouldn't expect to be using the hammer _unless_ you > encountered a problem that _specifically_ included nails. Not true. They are good for pounding things into place, pounding them out of being stuck, prying things off (with the back end), etc. > If you > encountered problems that included only screws, you'd never touch it; > you'd be using your screwdriver set instead. By that definition nothing can be "general purpose" because you are incorrecting looking for an all-in-one tool. (A Swiss Army Knife is actually a collection of many tools, not one tool.) > > >Only an idiot would > >not. No, it is not a one-size-fits-all tool, and I don't expect one. > >Good apps don't need a one-size-fits-all language because they can use > >yin-yang complimentary tools. > > *sigh* Time for some rudimentary definitions: > > single-purpose > useful for a single purpose, for a specific task, only > > multi-purpose > useful for a number of specific tasks, but only a limited number still > > general-purpose > useful for most tasks in general, though possibly with some specific > exceptions Okay, but even your own def does NOT require it to carry the entire load, but simply be *used* for most things. > > all-purpose > useful for absolutely everything > > A hammer is _not_ a 'general-purpose tool', because it isn't intended > or useful for general tasks, but specifically for beating nails into > stuff. I consider the equivalent of an app to be a "project", not a task. For an entire project, such as building a car or a house, most likely you will need a hammer at least once (even if you don't use nails). > If it also has a back end that lets you pry nails out, it might be > considered a 'multi-purpose' tool, but even that would be a stretch, > because you're still only working on the 'nails' bit. Either way, it's not > a 'general-purpose' tool by any stretch of the mind. Is there such a thing WRT physical tools by your def? > > Actually, there's a saying that's apt, and which I think that 'topmind' > very clearly exemplifies: > > "If all you have is a hammer, everything looks like a nail" Like maybe.......Java? > > The point of which, of course, is precisely that a hammer is _not_ a > general-purpose tool, but that if you are accustomed to working only with > a specific limited toolset (and thus the associated set of problems it is > intended to solve), there is a tendency to try to see all other problems > as if theyy, too, were problems of that specific type. However, that is a > fallacy, as there are problems which clearly don't fit into such a narrow > mold. That can apply to anybody. If you are truly experienced such that you tried them all, then you could point to multiple areas where RDB'S stink. > > Even topmind's own comments above show that he is fundamentally aware of > this: he says that a hammer is _one of_ the tools he would pack, so he > recognizes that there are many more tasks that he might encounter, but for > which a hammer is not a useful tool. But he confuses 'general-purpose' > with 'one-size-fits-all': Those are _not_ the same. No, it appears to be you who is making that part of the definition. > > Of course, when it comes to computers, 'general-purpose' can frequently > come very _close_ to being 'all-purpose' simply because there are very few > problems that fall outside the 'general-purpose' area. > > Java is a 'general-purpose' language, because you can write all sorts of > programms in it - from math-intensive scientific number-crunching, to data > storage and access, to graphical user interfaces, to distributed systems, > to ... etc. SQL _isn't_, because there are _vast_ areas of problems that > SQL not just osn't intended to address, but simply _cannot_ address, > however much you try to make it. Addressed above. > > The need for 'yin-yang-complementary' tools arises in cases where it it > difficult to create multi-purpose or general-purpose tools: construction, > woodworking, metalworking etc, are all places where it is difficult to > create such tools. Are you saying that in Java you don't need DB's because you can write your own concurrency management, join systems, aggregation systems, etc? Perhaps, but that just means that you reinvented the DB the hard way, and a proprietary one that new comers have to learn from scratch. Reuse is out the door. [snip] > > And again, 3GL can be used to _write_ RDBMS; the converse is _not_ true. Irrelavent. > > The relational data model is specifically intended for data storage and > access; it isn't intended to address anything beyond that. If that was true, then they would be happy with a file system alone. Besides, original intentions can mean squat, per above. [snip] [re: Text schema example] > But then you have taken what was an arbitrary stream of characters and > already broken it up into a representation that better suits your specific > model. Nothing wrong with that. > And I suspect that the code that would read an arbitrary stream of > characters and puts it into your tables, was written in something _other_ > than SQL - because SQL is not good at the free-text processing that is > necessary to get the data into a tabular format, because SQL is not > general purpose. You mean not Turing Complete, per above. Something does not have to be TC to be "general purpose". Another example would be Regular Expressions. They are not TC, yet are a general purpose string matching/finding tool. (Maybe not the best either, but that is another story.) [snip] > > // Christian Brunschen -T-
From: topmind on 23 Jan 2006 22:06 Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > > Patrick May wrote: > > > "topmind" <topmind(a)technologist.com> writes: > > > > SQL is close to being Turing Complete. > > > > > > In other words, SQL is not Turing complete. That addresses > > > your original question: > > > > No, because I never claimed "all". > > 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? It only means that its role is not to do the whole enchalada. It is not *meant* to do the entire app from end to end. I never claimed that about query languages or DB's. Being an end-to-end tool is not a prerequisite for being useful or being "general purpose". > > > > > > Almost all of these have a fair amount of disagreement among OO > > > > proponents. Check out c2.com. > > > > > > Interesting. I provide explicit examples of what are > > > generally accepted as good OO principles and practices and you > > > refer to a random website. If you have real documentation of > > > getter/setter proliferation being an accepted OO technique, > > > produce it. > > > > Do you have the opposite? > > Provided right above. Here it is again, for your convenience: > > 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. I believe the goal was "consensus". Those who put accessors around everything did it due reading somebody's mantra, not out of their own will. I didn't create the flame-wars between the wrappers and non-wrappers, I only noted their existence. > > > > The existence of legacy systems is just one reason why your > > > suggestion of using '"big-iron" RDBMS such as Oracle or DB2' > > > cannot solve the complex problems of large organizations. > > > > I am not following you here. If some of the processing has to be on > > legacy systems then it has to be on legacy systems. The introduction > > of a DB does not change that. > > 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 would like to see a demo. I know many shops that copy data from legacy systems into RDBMS so that they can more easily query, sift, and search the data. One feature of legacy systems is that a good many cannot handle a lot of data due to their age. Thus, current technology can copy what is there into an RDBMS. > > 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. You show me clear-cut coded proof, and I will change my mind. Until then, the brochure-talk and black-box-bragging can take a hike. OOer's seem so surprised and shocked when people ask for evidence, as if they are above it. "Science is so 70's. Alan Kay made science obsolete." (demonstrative quote only). > > 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. I did not mean to imply it was the current norm. I apologize for my wording there. > > > > > CRUD applications are, however, not particularly complex > > > > > as software systems go. Your claims otherwise indicate a lack > > > > > of experience with anything else. > > > > > > > > Again, please use evidence to prove me wrong instead of > > > > patronizing insults. It is a bad habit of yours. > > > > > > How is that patronizing? It's a simple statement of fact. > > > There is a reason why the CRUD work is typically given to new > > > hires and junior developers. > > > > You have a strange sense of biz apps. > > You have a nasty tendency of equivocating between "CRUD > applications" and "biz apps". In practice the line is blurred. It used to be more separated into "batch jobs" and "front-end" work, but now people expect instant answers, so the line has been fading. There is sometimes a split between "architects" and "coders", but this is largely because architects know the domain better. But, architects are still often involved with front-end/output design. > > Considered technical views of experienced software developers are > valuable, especially for other developers with the experience to > assimilate those views. You demonstrate your inexperience by > repeatedly taking positions like the one above, which boil down to "I > am unable or unwilling to understand your position, therefore mine is > equally valid." Does that make you feel all warm and fuzzy inside? One should not be expected to accept anecdotal evidence on face value here. Opinions from experts and amatures point every which way. If anecdotal evidence is all you have, then I am done here. Few come here to read unjustified positions. There are plenty of other places to get summary opinions. > > > > > > On the other hand, there are some delightfully complex > > > > > software systems that consist of only a few hundred lines of > > > > > code. Functional languages seem especially good for this. > > > > > See one of Peter Norvig's books for a few examples. > > > > > > > > Most FP demonstrations of such are "toy" or "lab" examples. > > > > > > Dismissing out of hand systems of which you know nothing. That's > > > a bad habit of yours. > > > > I gave them a chance to strut their stuff. If they can't strut > > right, it ain't my fault. > > Yeah, I can see how systems like Macsyma, RAX (controlling Deep > Space 1), Orbitz, the scheduling system for Gulf War 1, countless > expert systems, [.....] The challenge was *not* mere implementation. Even assembler has a lot of implementations. They claimed "significantly less code". I gave them a sample application and they made up every (lame) excuse under the sun. But that is another matter. FP is not the topic. > > > Hey, weren't you blown away by others on your claim that > > "relational" was mostly about links? [....] > > No, that wasn't me. [....] I apologize if it was not you. I should have checked. > > Sincerely, > > Patrick > -T-
From: frebe on 24 Jan 2006 01:28 > Codd's definition /is/ the RDB view; it is a specialized application of > more general set theory... Search for "relational model" at wikipedia and you will find no support for this statement. There seem to be a conensus that Codd is the creator of the relational model. I think it is important that we try to keep to generally accepted definitions and not try to invent own definitions to supports our claims. >> Why would line number be the key? > 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. >> In what way does emedded identity attributes limits Codd's RDM to >> persistence? > It doesn't. Good. But why do you use this argument for claiming the opposite? > Just look at the titles of Codd's early books and papers and try to > convince me that his research wasn't /focused/ on RDBs and persistence: I don't find any persistence related word in these titles. It is only in the OO world that Data Base == persistence. Outside this subcommunity databases are used for much more, which I have already many times pointed out. Search for "database" at wikipedia and count the number of times the word "disk" or "hard drive" appear. Personally I like the opening statement as a definition of database. "A database is an organized collection of data." > He was a researcher in IBM's hard disk division, for Pete's sake! Does this makes his research invalid in other areas? Many research results have proven to be useful in completly other areas. Does the fact that Ivar Jacobson has a background in the telecom industry, makes his work invalid in other areas? > you might also look at Chris Date's work for descriptions of the RDM well beyond > the RDB view. Below is one quote from a article from Chris Date: "In the first installment in this series, I said I expected database systems still to be based on Codd's relational foundation a hundred years from now. And I hope you can see, from what we've covered over the past few months, why I believe such a thing. The relational approach really is rock solid, owing (once again) to its basis in mathematics and predicate logic. " I don't think this support your claim that Codd's definition(s) is only a subset of the relational model. Fredrik Bertilsson http://butler.sourceforge.net
From: frebe on 24 Jan 2006 02:09
>> Bull. UML is often a LOWER level of abstraction because it can take >> much more code/language to specify the same thing. > Another example of an utterly absurd assertion whose sole purpose is to > drive an opponent who knows better crazy. I know you better so I'm not > going to bite by dignifying such nonsense with a response. Why is this so absurd? The guys making a RDMS might use UML for designing the software, before coding. Fredrik Bertilsson http://butler.sourceforge.net |