Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
Prev: Use Case Point Estimation
Next: Association Class
From: topmind on 23 Sep 2005 01:24 > > > For example, the function calls. They bust your damned tree > > into a graph yet you refuse to acknolege that. > > If you actually understood what a run time call graph was you'd > realize instantly it's a tree--even a pure tree by your twisted > definition of "pure tree". NOT! It has to turn reference into duplicate nodes to force tree-ness. Normalized, it would NOT be a tree. If you don't see the duplication, you are stubborn or blind. > > But since you never did understand it, the best you can do is > act like a 12-year-old: A 12-year-old who happens to be correct. Neener neener tree f8ck! > >> and don't understand the value of trees--particularly as data > >> structures. > > > > Until I see them donstrated to have real value in my domain, I > > will avoid them except on a small scale. > > As I've said before, for a report writer--as opposed to a real > programmer--there probably ISN'T much value in tree-shaped taxonomies, > although there might be in tree-shaped data. I know I've created > reports that returned hierarchical data. Perhaps you never have. The hierarchical nature of such reports is a particular *view*. The arrangement of the tree can often be changed. For example, one can nest products sold by region, or regions per product. Region A product 1 product 2 product 3 Region B product 1 product 2 ..... OR Product 1 region A region B region C Product 2 region A ... In the old days (read about IMS) the databases hard-wired the hierarchies into its structure. If a particular report was by the same tree, it was okay. If not, you had to bend over and scratch your back with your tongue. > >> Exactly. And a huge amount of it is. My group deals with a major > >> application *designed* for businesses to use out of the box. > > > > Why not point us to its website? > > All our installations are internal, so you can't access ours, but if > you go ogle for major CRM vendors and pick the top one, you'll probably > have it. I have worked with the databases of companies that have tens of millions of customers, and generally they base their classification systems on sets. In fact, some of the biggest problems happened from hierarchical arrangments set up in the days when they were much smaller. The trees failed to scale and they had to overhaul them. For example, they are shifting from "levels" to prequisites based on sets to match which products must be sold together. Levels were sufficient when their product base was small. However, customers want more al-la-carte choice. > > > Your "event-driven" startup drivel was laughable. > > Failing to understand it, you laugh at it. Typical. > > > You conveniently redefined "sequence" as being hierarchical. > > "A" happening before "B" does NOT make anything hierarchical. > > Which just demonstrates how badly you misunderstood the example. > As I recall, I had to explain several times before you even got > close to an understanding, but close was the best you could do. Let's leave it to the reader to decide whither sequences are hierarchical. I am tired of debating somebody who cannot show inharent treeness but insist it is there. I will agree that one *can* implement start-up events as a hierarchy. But it is *not* the only way, and not the way I would choose. > > Why am I bother to explain this to someone who apparently doesn't even > grasp basic set theory (or at least whined about intimidation when I > challenged you)? > > But, once more, sets are fine when the data > is sequential or unordered... You just don't get it. It is not that they are "unordered", it is that they don't hard-wire in ONE-and-only-one order, because the "proper" viewpoint is relative to user needs rather than universal. Relational is the best known relativity tool out there. > -- > |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | -T-
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 |