SQL
in [OOP]
|
From: Christian Brunschen on 28 Jan 2006 18:20 In article <1138483736.500520.123020(a)g47g2000cwa.googlegroups.com>, topmind <topmind(a)technologist.com> wrote: > >> 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"? "Natural' according to whatever structure you have the data to start with; 'natural' in the sense of 'fitting well within the existing framework'. >That is another one of those words that >hurts discussions instead of helps it. I have noticed that a number of discussions in which you have participated have been 'hurt'. There does seem to be a common factor, though. >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. Nevertheless, it is something that people perceive, even if subjectively, rather than objectively measurable. >> >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. Yes, you do: the database stores data, of specific types; strings, numbers, dates. The database _is_ a representation of the data. >It gives me no way to >see what is actually on the disk or in RAM The fact that the database itself may use a different representation of the data than it itself represents, doesn't change the fact that the database is a mechanism for storing data - and that the database thus is exactly a representation of the data. Thus, allowing access to the database, is allowing access the the data, the representation, rather than to the object that is somehow described by those data. >(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. And you will be right to a point, but only to a point. Everything is a 'representation' on some level. But with objects, I can represent the _behaviour_, rather than just the _data_. The objects expose the behaviour and hide the data; the database can expose only the data, because that is the only thing it has. (Again, excluding for this argument the fact that database engines these days have grown extensions which include programming languages, precisely to circumvent these restrictions in the relational model.) >In fact, DB tables are more sharable across languages than objects. >Thus, by that criteria they are more generic. .... but only for storage of and sharing data. If you want to do more than that, the database is simply not sufficient. I have said already that a database is a 'generic tool for storing and accessing data'; you're just repeating that. The fact that it is generic within its domain, still doesn't make it generic _outside_ its domain. >One has to bend over >backward to let Java use Python objects, for example. If you had different query languages, you would find it rather difficult to let a database using one and a database using the other, communicate. This would not, however, be a problem with the underlying relational model. Similarly, just because different object-oriented programming languages may have problemsinteroperating with each other's objects, isn't a failing of object-orientation. Your analogy, once more, falls apart. Furthermore, Java and Python objects can be intermingled quite well: <http://www.jython.org/> >This is one >reason why things like SOAP never really caught on. SOAP just grew too complex and hairy. However, 'things like SOAP' _have_ caught on. You are actually using a distributed object access mechanism every time you are browsing the web: HTTP. HTTP specifies amethod to invoke (PUT, GET, HEAD, POST, ...), and an object to invoke the method on (the URL), as we as potentially some input data (a query string in the URL, submitted form data); and in return, you get a response of some kind. Very nicely generic, very loosely coupled, extensible, and in very wide use throughout the world. >-T- Best wishes, // Christian Brunschen
From: frebe on 29 Jan 2006 00:30 > Why should I be precluded from using a class library that offers me some > reusable functionality? Why should I be precluded from using a component (RDBMS) that offers me some resusable functionality? >>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. I showed a problem with a very simple SQL solutions. You was not able to show a solution using objects referencing one another. Instead you needed a SQL-like query language to provide a solution. > (the code you present doesn't appear to extract the orders for customers > in a given city, but simply the orders of all customers?) q = orderTable.createQuery(); q.join(customerTable); q.setFilter(customerTable.city().eq(city)); > I suggest you take a look at Apple's WebObjects, which includes EOF, a > powerful and mature object-relational mapping tool. The differences between ORM tools and butler is that a ORM tool need a mapping file. Butler works directly on the RDB metadata. > Using objects, the objects themselves can maintain referential integrity But you have to code it by yourself, or? > I may want generic access to the objects, but not to their storage > representation. As pointed out many times before, SQL is not a storage representation. It is a generic way to manage data. How the data is stored on disk is completely hidden. Fredrik Bertilsson http://butler.sourceforge.net
From: topmind on 29 Jan 2006 01:38 Christian Brunschen wrote: > [ 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. ] I had no choice. The machine would not take long postings. And, I'll have to do it again here. > >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. You just happen to use them "few". That does not mean that is the only or best way to use 'em. > > [ 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. ] Writing a Lite DB in Java does not demonstrate anything except that one can write a DB in Java, or C, or Pascal, or Brainf*ck, etc. > >> >> 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. Because RAM *used to* be too expensive. We are now transitioning to a time where the RAM/Disk dichotomy can be blurred much more easily. > > >> >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, Please clarify. Most file systems are hierarchical, and if the app sticks to certain naming conventions, files can be transfered between Unix, Windows, Mac, etc. In many ways, file systems are more cross-compatible than RDBMS brands. > 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. No, it is because files don't offer most of the 10 or so features I listed. Those features are useful. Further, I think you miss the general philosophy behind most DBs: they model the world by associating attributes of things to a virtual model of that thing. There is only one you, and thus you have a unique record and key in the DB and attributes about you such as hair color or bank balance are stored in that record about you. It is a one-to-one match more or less.The "persistence" you often talk about is simply modeling the external world where things don't disappear just because you turn off the lights. In this view, "persistence" is a technique for modeling, and not really a mechanical/electronic issue. (Note that one does not have to use them for one-to-one modeling of external things.) This to me is a large part about what DB's are about: Modeling domain nouns. > >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? I think that was an issue in the 70's, but less and less now. We are fast approaching the time where a wrist-watch can cheaply contain a RDBMS. In the early 80's semi-relational DBMS fit in 64k of RAM I would note. I agree that SQL is a bulky language, but that is another issue and less relavant today. More compact query languages are possible. > >> >> 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. This is back to the Yin-Yang versus Big-Yang argument again. > >> 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). See the modeling note above. > general-purpose programming is about manipulating the data, making > decisions, etc. Yes, and DBs can and often should be a *big* part of this, even decision making. Maybe they won't always perform the final "if", but they may make it possible to have only one IF instead of 200. > > >> 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. Perhaps, but non-trivial apps I encounter can make use of a DB. > > >> 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. You are comparing apples to oranges. It is like saying that the car engine should also be the tires and penalizing it heavily if it isn't. > > >> 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. Because you want to wrap everyting in objects out of mantra. > >> >> 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. If there is ever a manned mission to Mars, they would be stupid not to bring at least one hammer. I bet you can find a hammer in nearly every single shop where even precision machinery is made or used. > >> >> 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. Well, tables are pretty darned flexible. They can be representationally equivalent to any other data structure. The areas where they flop are relatively few. Generally it is embedded apps and text handling where they are more trouble than help. > >> >> 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. So a car engine that is made out of rubber so that it can be a bumper and a tire is "general purpose", but a metal but widely usable engine (in different vehicles) is NOT general purpose? I guess it is a matter of how one defines stuff. I view the DB as more like the engine: most vehicles need an angine and the DB can be it. No, it can't be the bumper nor the tires. If that is what you want out of a DB, then by that view, you are technically right, but wrong from a practical sense. > >> >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. Under Turing Complete, there is no "need to". This a matter of design, implementation, and maintenance simplicity. It makes life easier. DB aspects are needed by *most* applications. If you don't use a DB for those aspects, then you will end up reinventing them from scratch or tying together disparate parts that do it. > > >> 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? I've heard some interesting front-line war stories about those kinds of things, but I think it is kinda gross to bring up here. > > >> 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. A strong enough knife can carve metal also. Thus, a super-strong knife(s) is then a general purpose furniture making tool by your def. P.I.T.A., yes, but possible. > > >> >> 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 ... 3D-graphics and CAD/CAM was my minor in college. I encountered many ways to potentially use a RDB for 3D modeling, which would have been better than d8cking around with pointers and linked lists. Much of the graphics "calculations" involved searching, cross-referencing, and sorting. However, in practice they are not (currently) fast enough for such. It is the machine issue there, not a developer convenience issue. In fact, dedicated graphics cards (GPU) are generally used now instead of software to get the needed performance. > > >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! Irrelavent. Your flight similator claim has been flattened because DBs can have a big use there even if they don't *be* the whole thing. (end of part 1, part 2 will be nearby) -T-
From: topmind on 29 Jan 2006 01:43 (part 2 of reply) > >> 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? There is no comp.anti-object, so stuff related to OO, including criticism, goes into the same topic. This is how it works. > > >> 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?'). Those kinds of things can be wrapped in functions or stored procedures such that one does not have to care about how the back-links work. And, one does not need to duplicate information (two-way links) to do it. On a large scale, such duplication can create nastly concurrency and integrity problems. > > 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. But OO tends to be inconsistent in how it does this. Different languages and different designers all do it very differently than each other. The relational rules of normalization allow less "creativity". Specific views or functions can be created to serve app-specific needs, but for maintaining the info itself, it is all still guarded/guided by the relational normalization. Thus, relational designs look more like a planned city while OO designs look like a hack-as-needed shanty town with telephone and TV wires every which way depending on who made what deal that week. > >> >> 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_. Yes, but the person putting the info in does not have to really worry about that step. Something like Prolog also requires something to actually "run" it, but the programmer is using mostly logical deductions, not being concerned with "run". A DB-centric design is in many ways similar. > > >Sure, something has to "run" those indicators, > > Exactly. But a DB-centric solution tends to consider that an implementation detail. One is more like a general who draws up the plans instead of being the front-line soldier who actually carries out the orders from the general. The general says where the troops go, which attack plan they use, and when to use it. Then he shouts "go!" and soldiers follow those plans. (Sure, this is an oversimplification, but you get the idea). Execution is a necessary step, but not necessary one to get all cought up in. > > >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. True, but from the tune-writer's standpoint they DON'T HAVE TO CARE. The composer does not have to give a flying [bleep] about how the gears work inside the player piano. That's the point. Necessary, yes, but not something that has to be the primary concern. Being necessary and being the primary concern are different issues. > > 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. True, but that is not where the real power lies. The "execution" process of Einstein's brain and Six-Pack Bob's brain are probably nearly identical. It is the attributes and links between nodes that make the difference, not the executor. > > >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_. It is a matter of diminishing what we as the developers are concerned with. Again, execution may be necessary, but does not have to be our *primary* focus. > > >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. But it can be an application-specific interpreter: a special-purpose language of sorts so that we are dealing with domain-specific abstractions. > > >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. The point is to demininish the need for such languages, only using them for what they do best instead of for everything. > > >> 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. It is modeling, not just "storage". Otherwise, files would be used. > > >> >> 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. Objects don't read minds either. > > 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. We've been over this already. One diminishes the need to deal with that concern. > > 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. That is an interesting challenge that I am not up to. I've encountered programmers who claimed they could do such and they gave some interesting examples of what can be done. However, I don't have the link right now. I suggest you try a Perl forum perhaps. Generally they can use strings to represent stacks, queues, lists, passible "functions" (code snippets that are later Eval'ed), etc. and regex's to parse and unparse such 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. DAhhh! Not this again. You are obsessed with the "final button". > > >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. Please clarify "static". [snipped yet more "final button" mantra] > 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. They did it partly to lock in users to their product, and partly to allow the same behavior *regardless* of app language. Thus, a database trigger will execute when an update happens whether the app that did the updating is Java, Python, Fortran, or Brainf*ck. In this sense, it is a better "gatekeeper" than OO's encapsulation. OO cannot so easily provide that. There is currently more knowledge in the world about how to make "data oriented interfaces" more sharable. Consider a graphing utility that makes pie charts, bar charts, etc. A data-oriented interface would have one fill in tables with the various attributes such as graph type (bar, pie, etc.), axis titles, groups/lines, and then actual data (or a query to it). We would have at least the graph table, the line/group table, and the data table (if query not used). One fills in the info, and then executes a "Run" or "Draw" step to draw the chart. I agree that the DB itself may not actually execute the graph and draw it. However, the attribute filler-upper does not have to really care about how it is actually implemenented. The "run" step implementation is not their concern. An OO version of the same thing would generally resemble: g = new graph(graph.context.PieChart()); g.addGroup("North", "Red"); g.addGroup("Middle", "Green"); g.addGroup("South", "Blue"); g.addData(.....); ..... g.draw(); // execute it Most of the "behavior" is simply defining the thing; that is, setting attributes. Running it ("draw") is only about 2% of the whole code deal. > >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_. Only if one has to accept the ridiculous arguement that the car engine should also double as the wheels when needed. > > Best wishes, > > // Christian Brunschen -T-
From: topmind on 29 Jan 2006 01:58
Christian Brunschen wrote: > In article <1138483736.500520.123020(a)g47g2000cwa.googlegroups.com>, > topmind <topmind(a)technologist.com> wrote: > > > >> 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"? > > "Natural' according to whatever structure you have the data to start with; > 'natural' in the sense of 'fitting well within the existing framework'. I think I would have to see a specific example. "Fitting well" can mean a lot of things. > > >That is another one of those words that > >hurts discussions instead of helps it. > > I have noticed that a number of discussions in which you have participated > have been 'hurt'. There does seem to be a common factor, though. Yes. Software engineering is more about psychology than anything else, and everyone's psychology differs. > > >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. > > Nevertheless, it is something that people perceive, even if subjectively, > rather than objectively measurable. Yes, but if people perceive it all different, then it is hard to talk about it with much coherance. > > >> >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. > > Yes, you do: the database stores data, of specific types; strings, > numbers, dates. The database _is_ a representation of the data. > > >It gives me no way to > >see what is actually on the disk or in RAM > > The fact that the database itself may use a different representation of > the data than it itself represents, doesn't change the fact that the > database is a mechanism for storing data - and that the database thus is > exactly a representation of the data. Thus, allowing access to the > database, is allowing access the the data, the representation, rather than > to the object that is somehow described by those data. You lost me here. A database is not just about persistence, we already have a long debate about that going. No need to duplicate it here. > > >(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. > > And you will be right to a point, but only to a point. Everything is a > 'representation' on some level. But with objects, I can represent the > _behaviour_, rather than just the _data_. The objects expose the behaviour > and hide the data; the database can expose only the data, because that is > the only thing it has. (Again, excluding for this argument the fact that > database engines these days have grown extensions which include > programming languages, precisely to circumvent these restrictions in the > relational model.) But data is more "mathable" than behavior in this point in history so that OO drags attribute management down to the low primative level of behavior in order to meld them. And, that is why OO makes hard-to-navigate messes so easily. It has to use the lowest-common-denominator of data and behavior in order to meld them. > > >In fact, DB tables are more sharable across languages than objects. > >Thus, by that criteria they are more generic. > > ... but only for storage of and sharing data. If you want to do more than > that, the database is simply not sufficient. Perhaps, but OO is no improvement over other approaches. Plus, many things that OO calls "behavior" can be *turned* into attributes if one knows how. > I have said already that a > database is a 'generic tool for storing and accessing data'; you're just > repeating that. The fact that it is generic within its domain, still > doesn't make it generic _outside_ its domain. I disagree with that definition of DB. > > >One has to bend over > >backward to let Java use Python objects, for example. > > If you had different query languages, you would find it rather difficult > to let a database using one and a database using the other, communicate. > This would not, however, be a problem with the underlying relational > model. One can still share data using comma-seperated-values etc. No need for a query language for that. > > Similarly, just because different object-oriented programming languages > may have problemsinteroperating with each other's objects, isn't a failing > of object-orientation. Non-OOP protocols are usually easier to share. > > Your analogy, once more, falls apart. > > Furthermore, Java and Python objects can be intermingled quite well: > > <http://www.jython.org/> If you stick with certain conventions for each side. > > >This is one > >reason why things like SOAP never really caught on. > > SOAP just grew too complex and hairy. However, 'things like SOAP' _have_ > caught on. You are actually using a distributed object access mechanism > every time you are browsing the web: HTTP. HTTP specifies amethod to > invoke (PUT, GET, HEAD, POST, ...), and an object to invoke the method on > (the URL), as we as potentially some input data (a query string in the > URL, submitted form data); and in return, you get a response of some kind. > Very nicely generic, very loosely coupled, extensible, and in very wide > use throughout the world. Looks more like a function call to me. > > Best wishes, > > // Christian Brunschen -T- |