SQL
in [OOP]
|
From: topmind on 27 Jan 2006 01:24 (part 2 of reply) > > >> 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'. Perhaps. But the DB can still carry a large load without having to carry all of it. Dumping it just because it cannot carry the entire load by itself is dumb. Dump the Yin just because it is not Yang also? > > >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. Well, I have not seen very many non-trivial apps that could not make use of a DB and/or table engine at least somewhere. > > You're just showing that your 'hammer' analogy is falling apart, beceause > of the differences between physical tools and software development ones. If it falls apart, nail it back together.......with a hammer. See, it even fixes criticisms. > > >> 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. But being TC does not mean convenient even if possible. It is possible to create almost any furniture with a single (strong) carving knife if you have enough patience and big trees. TC is the same way: it says nothing about convenience or efficiency. Thus, a carving knife is "Furniture Complete". > > >> 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). Or objects. > > >> 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? This comes back to the response time max threashold issue again. However, I can imagine using a DB to store flight scenarios/paths/situations/obsticals. Maybe each scenario would have to be read into RAM, but it may not be practical to put them all in RAM, and thus a DB to keep track of them and maybe find the best match based on the user's previous flight, something files may not be good at because the "indexing" would be on multiple factors. > > 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. Some GIS systems use RDBMS. > > 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 - Gee, I would have never guessed. > 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. Strength of OO? You are talking to the wrong guy. oop.ismad.com > 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. OO'ers tend to use very little of what DB's can offer. They like to reinvent the other items on that list outside of "persistence" just because they can. If you want to have fun, look at how OO apps tend to implement many-to-many relationships. > > >> 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. I doubt the economics are for it most the time. > > >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/> One could write a DB in any TC language. > > >> 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 ... What do you mean "not about business logic"? I've seen complex IF statements that could be reduced to table attributes. Sure, something has to "run" those indicators, but the runner is just like a player piano: it does not care what the actual notes are in the paper roll, it just "executes" them. The knowledge in your brain can be represented as attributes in neuron tables. table: Links ================= sourceNode_ID destinationNode_ID weight // weighting factor, can be negative in some models table: Node =============== node_ID activationFuncIndicator // (unit_step, sigmoid, piecewise_linear, gaussian, and identity) activationWeight // the "volume" given to activation function Now, whether all "IF" statements should be turned into table attributes and set logic is a separate issue. The fact is it can be and is done to various levels. What I put in code and what I put in tables is mostly a decision about what is most convenient, not what is possible. They are generally *interchangable*. (Putting 99% of the app in tables is generally creating a table-oriented interpreter for the most part.) Generally I use program code for Boolean statements. Boolean statements are usually combersome to represent and manage in tables. > > >> 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. So? Maybe that kind of parser is not something best done with a DB. However, it is perhaps prudent to store a complex grammar in a DB. > > >> 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). But one *can* represent text as rows and columns. Maybe it is not the most convenient approach in some cases, I will agree. > > >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'. I don't think this will be settled without specific use cases. The issue of can/can't is getting mixed up with easier/hard. > > 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; I am not sure if I would call string handling a "domain" in the sense it is usually used. Strings are a general-purpose tool also, BTW. > 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. Well, OOP only applies to the domain of objects. How is seeing most things as objects worse than seeing most things as tables? And don't bring in the "behavior" argument again. We've been over that already. You haven't shown how OO better handles behavior anyhow outside of shape, animal, and device driver examples. > > // Christian Brunschen -T-
From: Christian Brunschen on 27 Jan 2006 07:31 [ could you please stop splitting articles into two? it makes having a single, contiguous thread of discussion more difficult than necessary. If you find the postings are becoming too long, you could try snipping quoted material. ] In article <1138342882.711540.150900(a)z14g2000cwz.googlegroups.com>, topmind <topmind(a)technologist.com> wrote: >Christian Brunschen wrote: >> >> 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. True. I have since corrected my incorrect presumption on this issue. >> 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. I said nothing about something being used 'lightly' or 'heavily': I was simply pointing out that there are _a few_ (very useful) features of database systems that make them distsinct from other kinds of systems, not 'MANY' as you were proclaiming. [ Yes, recent versions of SQL include lots of things, like linkages to other languages, their own procedural languages, which are then used for things like triggers, stored procedures, etc, but those are mainly features that are borrowed from other, general development systems, and simply 'hooked into' the database, without having anything to do with the relational model per se. You might as well claim that tables etc are features of Java, just because there exist libraries that implement RDBMS:es in and accessible from Java. ] >> 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. Which I never said they weren't. >> 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. Considering that 'being' versus 'having' is a rather important distinction, your attempt at handwaving is perhaps not as good an argument as you might want it to be. >> >> 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 Other in-memory databases have been pointed out already; but that is _now_. Interestingly enough, if you read the very page you linked to above, you see that <quote> When writing Panorama, ProVUE engineers decided to rethink the fundamental disk based database technology that had been in use since the 1960's. </quote> .... which certainly suggests that the developers of Panorama, ProVUE, are suggesting that their in-memory database system is soemthing new and innovative, as contrasted to the 'fundamental disk based technology' that databases have been based on up to now. >> >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. .... but also less powerful, which is what the relational organization of data addresses. Yes, the relational aspect is not theoretically linked to the persistence aspect, but practically, those cases where data hase been in use mainly transiently have been possible to address with bespoke in-memory data structures (often containing data that has been read from, and will ultimately be written to, a persistent, relational database). Relational databases were developed to offer a general, generic way of storing data, including relationships between parts of those data, and they do so very well; they were also developed in a context where one of the reasons to do this was to allow multiple different applications access to the same data, without having the data locked into a format that was preferrable to any one of the applications that needed to work with the data. That very point, making data storage non-specific to any one application, suggests that the data are going to be _persistent_ between runs not juyst of the same application, but of different applications. Filesystems were already in use for persistent storage of data at the time, but were found wanting precisely because files that contained application-specific records did not offer portability of the data, because the data were locked to a specific structure. Relatinal databases solved that problem by releasing the data from being stored in an application-specific format, to being stored in a format that is generic and general. >> 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. I never said they did, I never said they weren't useful - so please stop putting words into my mouth. >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. But similarly, an approach where you feel a need to use a given tool 'becuase it's there', even though you may be able to create something for that specific purpose using your general-purpose environment, can _also_ be wasteful. If all you need is a simple ordered list of things in memory, which you will only ever traverse sequentially, then using an in-memory SQL database is going to be just that - wasteful - right? >> >> 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. However, I was being civil, I was making claims of a technical nature, which should (if they are wrong) be fairly easy to disprove, perhaps by a simple counterexample. You, on the other hand, resorted to profanity. >> >> 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. True, but it guarantees that you can achieve anything computable - including putting together soemthing that is more convenient, if necessary. >> >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, > >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". Um, no. The relational model is not about anything other than data, its storage, and how to access that data (insert, update, delete, fetch). general-purpose programming is about manipulating the data, making decisions, etc. >> 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.) It depends very much on the situation; existing tools may be too imprecise, or may require too much effort to use, and thus it may be easier to use a bespoke solution. >> 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. Of course, general-purpose programming languages built on top of assembly language don't offer any less conceptual power than assembly language itself does, so they can still address the exact same range of problems. The relational model _doesn't_ offer that same power. >> 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. Cool, don't. Indeed, I love having a database around for storing data, being able to search it, etc. But I don't consider the database the cornerstone of my software development existance. >> >> >> > 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, that only applies if you expect things to have tolerances that are too tight, or expect to be using friction to hold things together. If you build things using precise tolerances, precise assembly methods, glue or welding or similar for bonding, etc, you can get away without any 'pounding' whatsoever. >> 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. which uses other than pounding are you thinking of? >> >> 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. That, too, depends. Choosing soemthing that is pre-existing, and 'almost right but not quite', can be more costly than redeveloping something that may be similar to something existing but fits your problem _perfectly_ rather than 'almost'. It all depends on your situation, the problem, and so on. >> >> 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? No, I am not - I am simply pointing out that just because soemthing _can_ carry the whole load, it may not end up being _used_ in that fashion. For instance, an even more appropriate tool may be found (in your 'yin-yang fashion'), which thus allows the general-purpose tool to only carry parts of the load, while a single-purpose one carries another part. The difference being, again, that the general-purpose tool _can_ carry the the entire load, whereas the single-purpose (or multi-purpose) tool can only carry a _part_ of the load. >> >> 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'. > >Perhaps. But the DB can still carry a large load without having to >carry all of it. Dumping it just because it cannot carry the entire >load by itself is dumb. I am not suggesting 'dumping databases' - again, please don't put words into my mouth. I am simply saying that databases should be seen as what they are: specific solutions to specific problems, rather than a general-purpose solution to all sorts of problems. >> >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. > >Well, I have not seen very many non-trivial apps that could not make >use of a DB and/or table engine at least somewhere. But do they _need_ to? Strictly speaking, no. Would it be a good idea? In some cases, definitely; in others, possibly; in still other, probably not; and in further others, no. It all depends. >> You're just showing that your 'hammer' analogy is falling apart, beceause >> of the differences between physical tools and software development ones. > >If it falls apart, nail it back together.......with a hammer. See, it >even fixes criticisms. So if you fall down and split your head apart, should I put it together with a hammer and nails? Or would you prefer if I used, say, something like needle and thread instead? >> 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. > >But being TC does not mean convenient even if possible. It is possible >to create almost any furniture with a single (strong) carving knife if >you have enough patience and big trees. TC is the same way: it says >nothing about convenience or efficiency. > >Thus, a carving knife is "Furniture Complete". It does, however, restrict you to using raw materials that are availabel in sufficient dimension, and which hame all the desired properties. So, if your requirements were a bit more than 'soemthing chair-shaped', such as 'something chair-shaped, with leather upholstery', your knife would find itself being useful only for _part_ of the process. In other words, your physical-word tool _still_ doesn't work properly. >> >> 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). > >Or objects. Objects are available in some, but not all, of the languages listed above. Miranda, Haskell, C, Pascal, Logo - neither of them have objects; neither does LISP in itself (though CLOS can be added to LISP, of course). So attemptign to paint me as an 'object bigot' isn't going to work :) >> >> 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? > >This comes back to the response time max threashold issue again. Um, not just that - also to the things like driving the simulation (one tick at a time - in SQL (not counting the procedural add-ons likw PL/SQL, which are not part of the core and not related to the relational data model - strictly looking at the data definition and query languages here) there is no facility for that sort of thing. Also, as I mentioned, there's the whole lack of support for input from arbitrary devices like joysticks, nor for 3-dimensional graphics ... >However, I can imagine using a DB to store flight >scenarios/paths/situations/obsticals. Maybe each scenario would have to >be read into RAM, but it may not be practical to put them all in RAM, >and thus a DB to keep track of them and maybe find the best match based >on the user's previous flight, something files may not be good at >because the "indexing" would be on multiple factors. Well, as I wrote below (and why are you trying to answer me before reading the entirety of my argument on this point anyway?), a flight simulator might indeed use a database to store >> 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. > >Some GIS systems use RDBMS. GIS systems are about handling lots of information that is related in lots of different ways, some of which may not be known initially, have to be able to be modified dynamically, etc - all things that relational databases are _great_ for, and using a relational database is an excellent choice for a GIS. But a GIS is not a flight simulator; also, GIS:es are not written _in_ a database, they are written in general-purpose languages and they use databases for - storage of and access to data. Wow, what a surprise, using databases for their intended purpose! >> 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 - > >Gee, I would have never guessed. > >> 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. > >Strength of OO? You are talking to the wrong guy. oop.ismad.com Then why are you talking in the comp.object newsgroup? If you have so much against objects, then go away and play in a sandbox where your views are more likely to be shared. Unless, of course, you really are, as has been suggested, a troll ... >> 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. > >OO'ers tend to use very little of what DB's can offer. They like to >reinvent the other items on that list outside of "persistence" just >because they can. If you want to have fun, look at how OO apps tend to >implement many-to-many relationships. OO'ers tend to use very little of what databases have to offer, because they tend to think that the other things that databases these days offer (stored procedures, triggers, extensions in all sorts of directions) should be handled in other parts of the system than in the database, because OO suggests a certain organization of code - with objects carrying data and methods to operate on that data - and from such a standpoint, the main use for a database is indeed for persistence, rather than for any of the extensions that are cheerfully added onto them to bring them out of the 'just storing data' niche. To-many relationships are generally represented, in OO code, as an object holding a collection of the objects it is related to; if the relationship is many-to-many, then the related object will in turn have a collection of objects that it is related to, and the first object will be in the second objec's collection just like the second ons is in the first's. Yes, this means that in order to make certain that the relationships are always many-to-many, i.e., that no object is ever only on one end of such a relationship, you need to update two collections (that of the source object, and that of the destination object) whenever you create or destroy sich a relationship. However, this is just a direct consequence of the fact that each object knows about the objects that related to it (i.e., for a 'friends'' relationship, each object keeps track of the object that it considers to be its friends); and if such a relationship is always supposed to be reciprocal (i.e., either both peopel consider each other their friends, or neither of them does), then both objects need to be told of any changes to this status (so, if one object decides that 'you are not my friend anymore', then the other object also must remove the first object from its 'friends' list). Now, in a relational database, a one-to-many relationship is represented by a foreign key in the _related_ object, identifying the _source_ object: I.e., each row keeps track of which other row (singular) is related to it. So, if you were representing a tree structure, each 'child' row would hold a foreign key to its 'parent' row; whereas the 'parent' rows would not explicitly hold any information about their children. To find out what rows are the children of any given parent, a join has to be performed (which is cool, because databases are built aroudn that concept); but it still leaves the, from some points of view slightly strange, situation that in one direction the information is immediately there (each child row has a reference to its parent row), whereas in the other direction, the information must be deduced (by, essentially, asking all the possible rows 'do you consider me to be your parent?'). And many-to-many relationships are represented _only_ by indirect information - a join table; which is a table that holds _only_ foreign keys. In this case, neither one of the tables that are related to one another, actually hold the information about which other rows thay are related to, themselves; only the join table holds this information. each row in the join table relates one source and destination row; so in order to traverse the relationship, two joins are required, one to join the source table and the join table, and one to join that result with the destination table. This, too, could be considered 'weird', because once more, the information about which other rows a certain row is related to, is not stored intrinsically along with the row itself, but extrinsically in a different table; except now, this is the same for both the source and destination. Of course, most people have no great problems wrapping their heads around both of these approaches, and don't consider either one 'weird', but simply a consequence of the general environment in which they occur. When you have a system of objects which have unique references, and you can easily refer from one object directly to another (and there are ways to collect references of objects together), the OO way comes out as being quite straightforward. Even without objects, per se, but 'only' records and arrays or sets, such organization makes quite a lot of sense. Similarly, in the relational data model, where rows have primary keys by which they can be identified, but where rpws also have fixed columns, and where join operations are the fundamental way of putting things together, using foreign keys and join tables is the straightforward, simple, effective solution. it is only if you view either solution from a viewpoint that does't take into account its environment, that things look weird. And in the end, both approaches are isomorphous and can be translated between automatically: whether you use pointers/object references on the one hand or joins on the other, both represent relationships between 'things', and both have the same power of expressiveness. >> 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. > >I doubt the economics are for it most the time. Again, this depends on the precise problem. Quite frequently, using a database _is_ going to be very useful. But even then, whether one should but much code into the database engine, or just use it for simple storage of data, may not come out in favor of putting the logic into the database. >> Or one could just use one that has already been written - in Java: >> >> <http://db.apache.org/derby/> > >One could write a DB in any TC language. Indeed - but not vice versa. That's the whole point. >> >> 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 ... > >What do you mean "not about business logic"? I've seen complex IF >statements that could be reduced to table attributes. In that case, the business logic is represented as code in a language, which happens to be stored in the database; it still has to be read from the database and executed. The database is simply used as a mechanism to _store_ the code, not to _execute it_. >Sure, something has to "run" those indicators, Exactly. >but the runner is just like a player >piano: it does not care what the actual notes are in the paper roll, it >just "executes" them. But that analogy fails: the indentations on the roll for a player piano may not 'know' which notes they represent, but the player piano _does_ know: for a specific indentation, it will play a specific note. In a player piano, that knowledge is encoded in the piano's hardware (the linkage between the parts that read the paper roll, and the parts that actually play the notes), but it is definitely there. The paper roll is useless without the knowledge about which indentation causes which note to be played on the piano. There has to be something that interprets >The knowledge in your brain can be represented as >attributes in neuron tables. > > table: Links > ================= > sourceNode_ID > destinationNode_ID > weight // weighting factor, can be negative in some models > > table: Node > =============== > node_ID > activationFuncIndicator // (unit_step, sigmoid, piecewise_linear, >gaussian, and identity) > activationWeight // the "volume" given to activation function But something needs to know what to do with all this data. This is going to be something other than the database. >Now, whether all "IF" statements should be turned into table attributes >and set logic is a separate issue. The fact is it can be and is done to >various levels. Again, that's just using the database for _storage_ of the program. Something else still has to interpret the data in the databae, and use it; without that knowledge, the database, the schema, the data in it, are all completely useless. You could replace the database with a flat file, or an in-memory data structure, with no difference in what you're saying. There's a difference between soemthing that has been written down, and soemthing that has been written down _and the ability to interpret it_. >What I put in code and what I put in tables is mostly a decision about >what is most convenient, not what is possible. They are generally >*interchangable*. (Putting 99% of the app in tables is generally >creating a table-oriented interpreter for the most part.) Exactly. >Generally I use program code for Boolean statements. Boolean statements >are usually combersome to represent and manage in tables. .... which just goes to show that source code is often the most convenient representation for a programming language. >> 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. > >So? Maybe that kind of parser is not something best done with a DB. >However, it is perhaps prudent to store a complex grammar in a DB. But again, this is just using the database _for storage_. Which is fine,. of course, but again, you are just giving examples of using a database for _storing data_, which is what they should be used for. >> >> 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). > >But one *can* represent text as rows and columns. Maybe it is not the >most convenient approach in some cases, I will agree. One can represent _almost any_ form of data in tables of rows and columns - that's what the relational data model is about. But one can _not_ take an arbitrary set of data and let a database magically read it - because the organization of the data has to be done by something that knows how the data can be broken into the appropriate parts, as well as, of course, there needs to be something that describes what these appropriate parts are, how they are related to ne another, etc - you know, the database schema. The point is that just because you have some set of data, and a database, you don't have a complete solution. You need to organize the data, and format the data into that organization. This requires things that the relational database model does not offer - but turing-complete languages do. Even if you were to write a parser whose rules you store in teh database, it's not the relational database doing the parsing, it's 'the parser' which will be a construct which is written, fundamentally, in a general-purpose programming language, even though it may be driven by data which is stored in tables in a database. >> 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'. > >I don't think this will be settled without specific use cases. The >issue of can/can't is getting mixed up with easier/hard. OK, show us some use cases that support your assertions, then - that show that it is even _possible_. Show how a 'general-purpose string matching/finding tool' is a 'general-purpose tool' _outside_ of its domain - which is finding predefined patters within strings. >> 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; > >I am not sure if I would call string handling a "domain" in the sense >it is usually used. Strings are a general-purpose tool also, BTW. In what sense are strings a 'general-purpose tool'? They too don't _do_ anything - they are simply a set of data (much like a relational database). One can certainly use a string as a description of a program (hey! source code stored in a text file!), but the string itself is just a string. >> 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. > >Well, OOP only applies to the domain of objects. ... which are about data _and behaviour_, rather than just data - and which is realy just a paradigm for how to organize code and data together in coherent units, within the scope of general-purpose programming. One can write object-oriented code in assembly language, if one judiciously follows certain principles. The Objective-C programming language is a very small extension to C, and its fundamental semantics are implemented using a small C library, and can thus be called from C (without having to use any OO syntax at all). The relational model, however, is about data, and only data. That's it. You need something else to do something with that data, to interpret it, to use it, to give that data its usefulness. >How is seeing most >things as objects worse than seeing most things as tables? Tables are static things, that just are; objects are dynamic things, that both are _and do_ things. As are functions and values in the functional paradigm, as are data astructures and procedures in a procedural paradigm, etc. If you're only talking about data _storage and representation_, then any facility that will allow the representation of an arbitrary structure of interrelated data will be a candidate - and those that are easiest to work with will win. This means that things like tables, records+sets, objects, are all candidates, and for different uses, different ones may be more appropriate than others. However, that only addresses data _storage_. You still need a general-purpose tool to use the stored data, construct it perhaps, process it, modify it ... and the database alone can't do that. With objects, the objects themselves can; with records+sets, as well as with tables, you need soemthing else. records+sets are usually found within procedural programmig languages, and have what they need right there; the relational model has nothign like that though. That, of course, is the reason why database vendors started adding procedural languages as extensions to their database enginesm even though those have nothing to do with the relational model per se. Basically, if you see some data, and you immediately try to shoehorn it into your favourite data paradigm, then you are probably skipping a couple of steps, whether your favourite paradigm is relational, or object-oriented, or functional, or something else. >And don't >bring in the "behavior" argument again. We've been over that already. Just because you have 'been over' an argument and rejected it, doesn't make it any less true. >You haven't shown how OO better handles behavior anyhow outside of >shape, animal, and device driver examples. This isn't specific to OO: the relational model is simply not a general-purpose tool outside its domain (managing data in tables); it simply can't handle anything outside that. Specifically, the relational model doesn't handle _behaviour_ _at_ _all_. The OO model _does_ handle behaviour. Even if it were to handle behaviour _badly_, that still means that it 'wins' over the relational model, because, as I mentioned, the relational model doesn't handle behaviour _at all_. >-T- Best wishes, // Christian Brunschen
From: frebe on 28 Jan 2006 09:00 > In many respects, lists, maps, tables, relations, arrays, sets, SQL, > files, XML are _all_ low level, depending on your point of view. In many respects, objects are much more low-level than SQL. > I don't _need_ Cocoa Ok, so why don't you show your solution without Cocoa and we can compare if SQL is more high-level than basic data structures, or not. > Cocoa is not a DBMS, it's an object-oriented class library. hsqldb is also a class library and because it is written in java I think you may say that it is object-oriented. (Don't get me wrong, I don't say Cocoa is a bad product). > instead of representing relationships as joins, they will be represented as direct > references to the related object(s). As I showed in my customer order example, direct references (pointers) may not always be the best way to structure data. > Even in the relational model, you need to know which tables can be joined > with each other, and on which columns. You don't necessarly need to know on which columns a joind should be made. Foreign keys defines this already. Using my framework, butler, you can do a join like this. q = customerTable.createQuery(); q.join(orderTable); Iterator i = q.run().iterator(); while (i.hasNext()) { customer = (CustomerRecord) i.next(); orders = customer.getOrders(); .... } > You don't need to know any > more about the data in my model, than you need if you model it in a > relational fashion. The main difference between the network and the relational model is the lack of queries and referential integrity in the network model. > The relational model was developed to offer a neutral, flexible, generic > way to store and manage data. That is a good thing, right? > In some contexts, this particular genericity isn't so important And? Lets say we have a graphics library that is neutral, flexible and generic. Should I drop it because I don't need genericity? > In particular, if you have a generic, well-defined interface that lies > above the level of the storage of data, then it becomes less necessary for > the storage to be done in a generic fashion. I have done it this way before, and the main disadvantage is that we ended up with a not so well-defined interface with a large number of methods that were only called from one client. Soon you start to make generic methods like findByCriteria(generic_criteria). > For instance, if you make all your business objects available through a generic and > comprehensive interface over, say, SOAP, then it becomes somewhat irrelevant > whether those objects are stored in a SQL database, in flat files, in XML, or > whatever. First you don't want a generic interface. But now you want it? Problem is that your business interface is not generic, it is very customized. But if you had choosen to publish the database over SOAP, you would have a genric and comprehensive interface. If you choose SQL as your interface it becomes somewhat irrelevant wheather the objects (records) are stored in a database, in flat files, in XML or whatever. Fredrik Bertilsson http://butler.sourceforge.net
From: Christian Brunschen on 28 Jan 2006 15:30 In article <1138456837.103293.22920(a)g44g2000cwa.googlegroups.com>, frebe <fredrik_bertilsson(a)passagen.se> wrote: >> In many respects, lists, maps, tables, relations, arrays, sets, SQL, >> files, XML are _all_ low level, depending on your point of view. > >In many respects, objects are much more low-level than SQL. Objects are a general-purpose construct, whereas SQL is a single-purpose one (specifically about data access and modification). The objects that one can can construct can be low-level ones or high-level ones. >> I don't _need_ Cocoa >Ok, so why don't you show your solution without Cocoa and we can >compare if SQL is more high-level than basic data structures, or not. Why should I be precluded from using a class library that offers me some reusable functionality? That (being able to put together nicely reusable objects) is one of the things that are usually considered one of the strengths of object-orientation, after all. >> Cocoa is not a DBMS, it's an object-oriented class library. >hsqldb is also a class library and because it is written in java I >think you may say that it is object-oriented. hsqldb is an implementation of a SQL database, and happens to be implemented in an object-oriented fashion. Cocoa is a general-purpose class library, which is largely intended to offer services to the writers of other classes. There is a significant difference. >(Don't get me wrong, I don't say Cocoa is a bad product). From your comments, I am not entirely certain how closely you have had the opportunity to look at Cocoa. >> instead of representing relationships as joins, they will be >represented as direct >> references to the related object(s). >As I showed in my customer order example, direct references (pointers) >may not always be the best way to structure data. I disagree that you showed any such thing: your example didn't show that a relational representation was significantly better than one using objects referencing one another. >> Even in the relational model, you need to know which tables can be joined >> with each other, and on which columns. >You don't necessarly need to know on which columns a joind should be >made. Foreign keys defines this already. But still, this means that the knowledge about what joins need to be performed to resolve a relationship is encoded somewhere - specifically, in this case, in the foreign key constraints. >Using my framework, butler, you can do a join like this. >q = customerTable.createQuery(); >q.join(orderTable); >Iterator i = q.run().iterator(); >while (i.hasNext()) { > customer = (CustomerRecord) i.next(); > orders = customer.getOrders(); > .... >} (the code you present doesn't appear to extract the orders for customers in a given city, but simply the orders of all customers?) I suggest you take a look at Apple's WebObjects, which includes EOF, a powerful and mature object-relational mapping tool. >> You don't need to know any >> more about the data in my model, than you need if you model it in a >> relational fashion. >The main difference between the network and the relational model is the >lack of queries and referential integrity in the network model. Using objects, the objects themselves can maintain referential integrity (by having methods to properly add other objects to relationships, remove them, etc). So there is a distinct difference here. >> The relational model was developed to offer a neutral, flexible, generic >> way to store and manage data. >That is a good thing, right? Yes, of course, for those cases where that is what you need. >> In some contexts, this particular genericity isn't so important >And? Lets say we have a graphics library that is neutral, flexible and >generic. Should I drop it because I don't need genericity? if that genericity comes at a cost, and the library perhaps due to its genericity forces you to adapt your application to the library in a way that is not entirely natural, and there are alternatives available that offer you the necessary functionality with a different set of costs whose overall sum is less, then yes. Genericity is good, but sometimes something specific, or something that has been made bespoke for a particular purpose, can be better. >> In particular, if you have a generic, well-defined interface that lies >> above the level of the storage of data, then it becomes less necessary for >> the storage to be done in a generic fashion. >I have done it this way before, and the main disadvantage is that we >ended up with a not so well-defined interface with a large number of >methods that were only called from one client. Soon you start to make >generic methods like findByCriteria(generic_criteria). It depends on your needs. >> For instance, if you make all your business objects available through >a generic and >> comprehensive interface over, say, SOAP, then it becomes somewhat irrelevant >> whether those objects are stored in a SQL database, in flat files, in XML, or >> whatever. >First you don't want a generic interface. But now you want it? I may want generic access to the objects, but not to their storage representation. The whole 'information hiding' thing. >Problem >is that your business interface is not generic, it is very customized. >But if you had choosen to publish the database over SOAP, you would >have a genric and comprehensive interface. It may indeed be too generic and comprehensive - again, might break encapsulation and expose things on a lower level (storage) than I want to expose (object identities and methods). >If you choose SQL as your interface it becomes somewhat irrelevant >wheather the objects (records) are stored in a database, in flat files, >in XML or whatever. But then you are indeed talking about records rather than objects. Objects offer other facilities that also allow you to represent away the storage abstraction underneath - including, perhaps, precisely which data are indeed stored. And I might not actually want to allow access to the objects' stored data directly, but only to the objects and the methods they implement; and the objects would then themselves alter the stored data as and when necessary, whether stored in a database of some kind, or in a flat file, or just transiently in memory. >Fredrik Bertilsson >http://butler.sourceforge.net // Christian Brunschen <http://www.smilemu.org/>
From: topmind on 28 Jan 2006 16:28
> if that genericity comes at a cost, and the library perhaps due to its > genericity forces you to adapt your application to the library in a way > that is not entirely natural, and there are alternatives available that > offer you the necessary functionality with a different set of costs whose > overall sum is less, then yes. How does one measure "natural"? That is another one of those words that hurts discussions instead of helps it. It is probably a more problematic word than "complexity", which caused a stir before here, and is probably tied to personal psychology in the end rather than something objectively measurable to any usable sense. > > >First you don't want a generic interface. But now you want it? > > I may want generic access to the objects, but not to their storage > representation. The whole 'information hiding' thing. I don't see the representation when I use a DB. It gives me no way to see what is actually on the disk or in RAM (unless one hacks a backdoor or the like). That is hidden behind the relational model and query language. If you say tables are a specific implementation, then I will say that objects are a specific implementation. In fact, DB tables are more sharable across languages than objects. Thus, by that criteria they are more generic. One has to bend over backward to let Java use Python objects, for example. This is one reason why things like SOAP never really caught on. -T- |