SQL
in [OOP]
|
From: Dmitry A. Kazakov on 24 Jan 2006 04:13 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. > 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. Completeness is rather a precondition. It does not imply anything. If my application area does not require something a Turing machine can, then I don't care. ---------- * This is why I count SQL as extremely low-level, comparable to Algol-60. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Christian Brunschen on 24 Jan 2006 05:35 In article <1138069132.579407.231900(a)z14g2000cwz.googlegroups.com>, topmind <topmind(a)technologist.com> wrote: > >Christian Brunschen wrote: >> In article <1137996532.423030.167400(a)f14g2000cwb.googlegroups.com>, >> topmind <topmind(a)technologist.com> wrote: > >> >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. Well, the features of a relational database are primarily that it allows you to store data, organised as rows and columns in tables according (more or less) to the relational model, and and it does so in a persistent manner (what you put into the database isn't going to disappear unless you explicitly remove it). 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. It's a very useful one, true, but you are overstating it a bit. Nevertheless, persistence is considered one of the cornerstones of RDBMS:es, and one thing that RDBMS:es are expected to offer. >> 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. But the filesystem remains a persistence mechanism, even though it has been used for its 'size' aspect rather than its 'persistence' aspect. So, the mere fact that you can use a database in a non-persistent manner doesn't make it any less of a persistence mechanism. >> The relational model, and SQL, were developed specifically for persistent >> databases. > >Because RAM was too expensive to consider non-persistence DB's back >then. Interesting assertion - do you have anything to back it up with? From everything that I have read, it has been extremely clear that he relational model was developed for _persistent_ databases, not for _transint_ ones. >The history is generally irrelavent. I disagree: History is never entirely irrelevant, even if only to show where something came from. >I don't care what they did >in 1965; It does not change what I do now. But it may change how one can _view_ and _describe_ what you do now, and indeed, the tools you use. >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. Yes, lots of things end up being used differently than originally intended. 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. So it's not just 'ancient history', it is also _current usage_. >> 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. Well, the potential usage of relational databases is the storage, organization and access to (persistent or non-persistent) data. that still doesn't solve the _vast_ majority of problems out there, because you usually have to _do somethin_ with the data (process it somehow), which SQL doesn't do. >> 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.) Cool. >> >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. Ah, such eloquence, such precise refutation of the points I raise. >> 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". In a programming context, you can't get much more 'general-purpose' than 'turing complete'. But 'general-purpose' does not, per se, imply 'turing complete': it simply implies that something is useful not for a specific task, but for problems _in general_. Turing-complete languages will be general-purpose. But there may well be genera-purpose languages which aren't 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. The 'do everythign' assumption may not sit well with you, but the fact is that there are _lots_ of tools (programming languages) that _can_ 'do everything' (inasmuch as it is possible on a computer), and that SQL isn't one of them. More to the point, however, there are similarly _lots_ of different paradigms (procedural, functional, object-oriented) that likewise 'can do it all', but the relational model _also_ isn't one of them. And SQL is limited _by design_ to _not_ address any aspects other than the data storage and access ones, so it doesn't even attempt to be anything othewr than a single-purpose language. >> 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. You're basicaly assuming, though, that you _need_ to combine different tools. Well, that is true _if and only if_ you are focused on using at least one tool that cannot solve the whole issue (such as, if you are wedded to the idea of using a RDBMS). If you allow yourself to include in your toolchest such tools that _can_ indeed address the while problem, then you do not _need_ to combine different tools. (You may still choose to, for a variety of reasons, but you do not _need_ to.) >> >> > 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. OK, that is just generalizing from 'nails' to 'something' - the point is still that it is a tool specifically for the purpose of _hitting_ something. Actually, if you have a hammer with one of those prying back-ends, you actually have a combination tool, where you've turned the back end of the hammer into a part that is traditionally on a crowbar. The proper 'hammer' bit - the front end - is intended for the purpose of hitting things, with a suitable amount of stored energy (which is why a hammer has a reasonably heavy head and a reasonably long handle). >> 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.) With woodworking, etc, it is indeed difficult to create 'general-purpose' tools, precisely because there are so many different tasks there that may need to be done, and for many of those tasks, specific, single-purpose tools are the best things to do them. Fortunately, with computers, we have an environment where we really _have_ general-purpose tools (programming languages) - that is one thing that sets computers apart form many other areas. >> >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. I actually wrote _useful_, not _used_, if you read carefully. And 'useful' implies 'able to address problems'. i.e., yes, to 'carry the entire weight' if necessary. >> 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. Well, a 'project' falls apart into many 'tasks'. >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). .... whereas for writing a large application, you might never need anything beyond a single programming language, if that programming language is a general-purpose one. You're just showing that your 'hammer' analogy is falling apart, beceause of the differences between physical tools and software development ones. >> 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? As I mentioned above, in many physical disciplines, it is extremely difficult to put together anything that is a general-purpose tool, precisely because the tasks are so completely distinct. >> 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? My 'toolchest' includes C, C++, Objective-C, Logo, Pascal, Simula, Smalltalk, Miranda, Haskell, Perl, Python and SQL (among other things). >> 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. RDBs stink for writing flight simulators. Ever tried it? And I'm not just talking about the lack of support for joysticks or 3-d graphics. A flight simulator _could_ use a relational database to store the state of the simulated world, etc, but the end up being written using specialized data structures - because the relational data model doesn't fit well with the way one would model a plane, the world it flies in, etc. Yes, you _could_ store it in a relational database, but direct references between different parts of the plane, the different parts that make up the environment, etc, simply work better. There are also many problems where the choice of using a RDBMS is made simply because it is there and thus readily available, i.e., just for reuse purposes, rather than because the data fits particularly well into the relational model. My main use of SQL and relational databases is actually for persistence - often through an object-relational mapping tool (Apple's 'Enterprise Objects', part of their WebObjects product). This allows me to use the key strengths of RDMS:es - persistence, organization of data, and through SQL a relatively standard interface - while also allowing me to use the strengths of OO, for implementing the business logic for those objects that are stored in the database. But make no mistake: The database is a _useful_ part for storing the data, but it isn't a _necessary_ part. Other persistence mechanisms could be used. >> 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. Huh? You are the one who keeps trotting out the phrase 'one-size-fits-all' whenever someone else mentions 'general-purpose'. I am trying to show that they are _distinct_. >> 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. Well, you've commented above, but not actually _addressed_ it. >> 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? Exactly: You don't _need_ databases, per se, when using Java, because you can write your own, if necessary. And indeed, for some aplications, you can write something that will work _better_ for that application than using a RDBMS. >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. Or one could just use one that has already been written - in Java: <http://db.apache.org/derby/> The point isn't that one _should_ rewrite everything from scratch: The point is that one _could_. And indeed sometimes there is value in it: Derby is a reimplementation, from scratch, in Java, of a RDBMS. It is now available to use in Java., >> And again, 3GL can be used to _write_ RDBMS; the converse is _not_ true. > >Irrelavent. Only to you. >> 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. What precisely besides data storage and access is the relational model about? You should take note that I wasn't referring to persistence above. It's certainly not about computations or business logic or user interaction, for instance ... >> 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. But it shows that you cannot use a relational database alone as a replacement for text files: You also need some form of parser to separate the text file into parts that you can put into the relational database. >> 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. Not necessarily - please don't put words into my mouth. The point is that SQL was never intended to work with arbitrary streams of characters - it was intended to work with arbitrary tables (and rows and columns). >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.) Um, no. You wrote 'general purpose string matching/finding tool': Even by your own writing they are 'general purpose' _only_ within their specific domain, 'string matching/finding' - in exactly the same way as SQL is 'general purpose' _only_ within its own domain, 'accessing data in a relational database'. The point here isn't turing-completeness, actually: it's that some things only apply to _specific_ domains (such as regular expressions, which apply to the domain of strings; and SQL, which applies to the domain of relational databases), whereas other things are defined to apply _in general_ (such as object-orientation, functional programming, procedural programming, etc). This is a very important distinction. >-T- // Christian Brunschen
From: Oliver Wong on 24 Jan 2006 11:40 Just two small nitpicks: "Christian Brunschen" <cb(a)festis.df.lth.se> wrote in message news:dr4vtn$6am$1(a)news.lth.se... > In article <1138069132.579407.231900(a)z14g2000cwz.googlegroups.com>, > topmind <topmind(a)technologist.com> wrote: > >>The history is generally irrelavent. > > I disagree: History is never entirely irrelevant, even if only to show > where something came from. > topmind claimed history is *generally* irrelevent, not *entirely* irrelevant. "If only to show where something came from" does not contradict with "generally irrelevant". > > Turing-complete languages will be general-purpose. But there may well be > genera-purpose languages which aren't turing-complete. The "infinitely long ribbon of 1s and 0s that Turing Machines read" is a turing-complete programming language, but I don't think it's a "general-purpose" language. AFAIK, their purpose has thus far been limited to proving theorems (about the Turing Completeness, or lack thereof, of other abstractions, for example). So just because a language is TC does not nescessarily imply that it is general purpose, in the sense that this thread seems to be using "general purpose". - Oliver
From: H. S. Lahman on 24 Jan 2006 12:02 Responding to Frebe... >>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. As I said elsewhere in the message, Codd was the first to provide a formal model using existing set theory and predicate logic. However, his goal was to describe a specific data storage mechanism -- the RDB. The RDM has been greatly expanded since to be applied in other contexts. >>>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. 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? >>>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? I never said one can't apply the RDB model to transient data. Quite the contrary, at least three times in this thread, including right here, I have said one could. And I have said repeatedly that OO Class Models are normalized to the RDM. This is the third time in this thread where you have deliberately misrepresented me with a when-did-you-stop-beating-your-wife ploy. Ta-ta. ************* 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 -- Put MDA to Work http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman (888)OOA-PATH
From: frebe on 24 Jan 2006 13:34
> 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. * Transactions. * Referential integrity * Caching. > 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? > 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. Fredrik Bertilsson http://butler.sourceforge.net |