Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: topmind on 23 Sep 2005 01:54 > Why would you need to demonstrate an ability no one disputes? > How about you back up your original claim "relational==table"? Somebody else is doing a wonderful job at it for me. A thousand thanks to them. It takes many hunters to down a stubborn elephant. > > >>> The ODBC name is not the same thing as a "machine name". It > >>> is essentially the name of a configuration, a "reference" > >>> to a database (and usually a locally-stored configuration). > >> > >> Yes. And **IN** that configuration is the machine name. > >> If that changes, the configuration must change. > > > > Are you suggesting having the configuration point to > > yet *another* configuration that is virtual? > > No, I'm talking about how ODBC connections work. (Apparently this > is yet another area of ignorance for you.) Under the hood of every > ODBC connection is a machine name. Well of course. On a large scale it is a map (hash) between logical and physical: logicalNameOne ------> PhysicalSourceAlpha logicalNameTwo ------> PhysicalSourceBeta logicalNameThree ------> PhysicalSourceAlpha (Note that two logical names can refer to the same physical name, the Alpha source in this case.) What in it are you not happy about that arragement? By the way, it may be possible for one logical name to reference another logical name, but I've not tried that yet. > > > >>>> Describe how you think an RDBMS would provide such a simple service. > >>> > >>> UPDATE folders SET shared=true WHERE [folder criteria] > >> > >> You've missed the point. This isn't about how to make a folder shared. > >> It's about the ease of--once having a shared folder--dropping files, > >> or copies of files, into that folder to share them. Or the ease of > >> removing them, or deleting the copies, to unshare them. > > > > Having a relational engine does NOT prevent having a one-click > > icon for the masses any more than a tree-based file system > > requires one to type MD or MAKEDIR or COPY. I did not propose that > > every file operation be done with SQL or a query language. > > Um, that's exactly what you DID propose above. How do you expect a one > click icon to know what folder, what criteria? As one of *many* techniques. There are several ways to browse and search relational data. Query languages are one way, Query-by-Example is another, which can be combined with "ID-set-processors" so that one can perform set operations via mouse instead of queries. And it can be combined with semi-natural language query techniques resembling a Google search. Matching keywords could be hilited and close matches could be next to a list of guesses. And a hierarchical-like drill-down view can perhaps be created using arbitrarily ranked "levels" per factor also for you tree fans that don't get it yet :-p > > And once again, you've completely missed the real point. Which is, now > that a shared folder exists, how do you move files and copies of files > into and out of that "folder"? This depends on whether the relational granularity is by folder or by file. If by folder, it wouldn't be much different than hierarchical systems. It would be like moving retail products 1,8, and 13 from store A to store B; just like an inventory system. If at a file granularity, "move" does not have much meaning. Relational transcends many of the physical limitations of our physical world. You change attributes rather than "move". -T-
From: Dusty Bin on 23 Sep 2005 03:18 Chris Sonnack wrote: <snip> </snip> > VERY important distinction. Here's what I wrote over a month ago: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Here's a table (first row headers): > > NAME UID COLOR DATE TYPE > Alice - Blue 5-3-1948 BG45 > Bob - Red 5-3-1948 XL220 > Carol 3345 Red 12-7-1955 E30F > Dave 7709 Green 9-14-2000 - > > I dispute your "relational==table" definition, so I see not > one thing that makes this table "relational". It's just a > (what I'd call) "flat table". Even if no other (meaningful?) relation exists between Alice, -, Blue, 5-3-1948, and BG45, you have defined a relation by putting them in the same row in your table. If the relation did not exist, there is no point putting them in the table. A table defines a relation, and a relation can be expressed as a table. Best regards... Dusty <snip>
From: Christian Brunschen on 23 Sep 2005 04:33 In article <1127454876.745455.176270(a)g44g2000cwa.googlegroups.com>, topmind <topmind(a)technologist.com> wrote: > >> Why would you need to demonstrate an ability no one disputes? >> How about you back up your original claim "relational==table"? > >Somebody else is doing a wonderful job at it for me. A thousand thanks >to them. It takes many hunters to down a stubborn elephant. Please, do not take the fact that I quoted from one of the standard textbooks on Relational Databases, to be in any way shape or form an endorsement of your debating techniques. On the contrary: I think you should have _done your own homework_. It's not like you haven't had *ample* time to look this up yourself. Also don't take my comments as in any way supporting any of your remaining misconceptions. Best wishes, // Christian Brunschen
From: Christian Brunschen on 23 Sep 2005 04:44 In article <43328e59$1(a)news.totallyobjects.com>, Dusty Bin <lixo(a)argus.pt> wrote: >Christian Brunschen wrote: ><snip> ></snip> >> So, without attempting to validate or invalidate anything else on any side >> of any argument, according to what I have quoted above, it should be >> fairly clear that the term 'Relational' in 'Relational Database' has >> _nothing_ to do with relationships between different tables: >true > The term >> 'Relation' is instead a different, more precise term for the type of >> tables used in Relational databases. So, even a database with only a >> single table, is a relational database. >The relationship is the relation between the columns of a table. Um, no. As defined in Codd's paper, a 'Relationship' is the same as a 'Relation', except for one thing. In a 'Relation', the order of the attributes matters, whereas their 'headings' are less important: one can, in a Relation, have multiple Attributes with the same Heading, as each Attribute is uniquely identified by its position within each Tuple in the Relation. In a Relationship, Attributes are unordered, but are identified by their Heading, which must of course now be unique. So the difference, in Codd's paper, is that a Relation is an unordered Set of Tuples, in which the ordering of the columns is significant but the names are less so; whereas a Relationship is an unordered Set of Tuples where each Column is uniquely identified by its Name 9rather than by its position). Or, to quote from Codd's paper, "In mathematical terms, a relationship is an equivalence class of those relations that are equivalent under the permutation of domains [ ... ] ." Of course, the term 'relationship' is another one of those that has become vastly overloaded over the years: For instance, it is used in 'Entity-Relationship modeling', to represent a connection between different entities, and since E-R modeling is often used when designing database schemas for relational databases, well, there's one source of confusion right there. But the term 'relationship' does not in fact as you are trying to state, com from there being a 'relation' between the different columns of a relation. >hth... Dusty Best wishes, // Christian Brunschen
From: Antoon Pardon on 23 Sep 2005 04:44
Op 2005-09-23, Chris Sonnack schreef <Chris(a)Sonnack.com>: > I stand by the original seed: SQL is not a "relational language". > I also stand by the idea that "relational", in "Relational Database" > is about *relationships* between records. I claim that if there are no > relationships, there's no Relational. Then IMO you are wrong. It are the records (the tuples) that make out the relation. >> The term 'Relation' is instead a different, more precise term for >> the type of tables used in Relational databases. > > Exactly. Pay attention to the words: "...the TYPE of tables." Not just > you plain old tables, but (as quoted above), " table of a cedrtain [sic] > specific kind". > > VERY important distinction. Here's what I wrote over a month ago: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Here's a table (first row headers): > > NAME UID COLOR DATE TYPE > Alice - Blue 5-3-1948 BG45 > Bob - Red 5-3-1948 XL220 > Carol 3345 Red 12-7-1955 E30F > Dave 7709 Green 9-14-2000 - > > I dispute your "relational==table" definition, so I see not > one thing that makes this table "relational". It's just a > (what I'd call) "flat table". Then you are wrong. This table is a relation. It is a relation between a NAME, UID, COLOR, DATE and TYPE. Relation is here used in a mathematical sense. If you consider NAME, UID, COLOR, DATE and TYPE as sets (of possible values), then a relation is a subset of NAME * UID * COLOR * DATE * TYPE. A table as shown above represent such a relation, because the tuples represent elements from this product set. -- Antoon Pardon |