SQL
in [OOP]
|
From: Patrick May on 25 Jan 2006 16:23 "Mikito Harakiri" <mikharakiri_nospaum(a)yahoo.com> writes: > Patrick May wrote: > > 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. > > I wouldn't be so sure. All what is required is to express one of the > standard computational models in SQL. > > Consider primitive recursive functions. That seems to be the missing bit, either direct support for some loop construct or full support for recursion as a means of looping. > Granted yet we need to step up from primitive recursive functions to > recursive functions, the assertion that there is a gap in SQL > expressiveness is not obvious at all. I suspect that you could do something with triggers creating triggers, if a few constraints were relaxed. That would push the issue from theoretical impossibility to practical impossibility. I can't see enshrining "Stupid SQL Tricks" as good programming practice. > (And with those goofy spreadsheet extensions -- aka model clause -- > I doubt there is any gap at all). If you want to address the issue via extensions, just wait for an implementation SQL99's SQL PL. 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 25 Jan 2006 16:36 "frebe" <fredrik_bertilsson(a)passagen.se> writes: > > RDBMS:es only offer transaction support _for things within their > > domain_ > > Of course. Can you name any other product offering transaction > support for things not within their domain? They're called transaction managers. Tuxedo is probably the best known. See http://e-docs.bea.com/tuxedo/tux80/atmi/adtrn5.htm for more details. 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: frebe on 26 Jan 2006 00:08 >>> RDBMS:es only offer transaction support _for things within >>>their domain_ >> Can you name any other product offering transaction >> support for things not within their domain? > They're called transaction managers. Tuxedo is probably the > best known. So, if I want transaction support for my map object, Tuxedo knows how to handle transactions for maps? Fredrik Bertilsson http://butler.sourceforge.net
From: Patrick May on 26 Jan 2006 16:25 "frebe" <fredrik_bertilsson(a)passagen.se> writes: > > > > RDBMS:es only offer transaction support _for things within > > > > their domain_ > > > > > > Can you name any other product offering transaction support for > > > things not within their domain? > > > > They're called transaction managers. Tuxedo is probably the best > > known. > > So, if I want transaction support for my map object, Tuxedo knows > how to handle transactions for maps? If you had read the reference, you would know that transaction managers are a mechanism for resources encapsulated by resource managers to participate in global transactions. That clearly meets your criteria of "offering transaction support for things not within their domain." Provide a resource manager for your map object and it can participate in global transactions managed by Tuxedo or similar products. 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: topmind on 27 Jan 2006 01:21
Christian Brunschen wrote: > 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). Not necessarily. I have used temporary tables for processing, as desribed somewhere around here. > > 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. It can be used heavily or it can be used lightly. Just because you use it lightly does not mean that everyone else does. > > Nevertheless, persistence is considered one of the cornerstones of > RDBMS:es, and one thing that RDBMS:es are expected to offer. Perhaps. But the existence of such does not mean other things are not useful. > > >> 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. Another "is" versus "has" wording battle it appears. > > >> 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. I've read about major vendors researching the issue, but couldn't google up anything immediately. However, I did find this: http://www.provue.com/panorama5.html > > >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_. Well, I dissagree with "for". A file system would be used instead if that was all they really wanted: It's simpler (to understand) and cheaper. > > >> 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. We've been over this already. It does not have to solve the entire problem by itself to be highly useful. All kinds of software tools are employed to help: compilers, report writers, GUI libraries, etc. to solve the entire problem. A one-tool-for-everything approach can be very wasteful. > > >> 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. Your claims were equally unbacked. I just answered unbacked statements with an unbacked answer. > > >> 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 does not guarentee anything about convenience to programmer nor to CPU. > > 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. Irrelavent. It does not have to be everything. It is the Yin to the Yang. > 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, It can access zeros also :-) But again, storage is merely one of many features and abilities. Your statement is like saying that "programming languages are limited because they only deal with variables". > 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. No, only that I found it works best. (Or, at least not objectively worse than the alternatives.) > 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). Everything can be processed with Assembler programming, but that fact is not nearly enough to make me switch. > 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.) I used to have to do without DB's, and I don't wanna go back. > > >> >> > 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. Well, most construction of anything reasonably complex is going to involve pounding of some sort. > 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). Even the blunt end by itself has many uses. > > >> 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. But to reinvent many things from scratch just because you can is uneconomical. > > >> >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. You did not say "If necessary". Are you amending your def? (end of part 1) |