Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?] To : comp.programming,comp.object From : Chris Sonnack Date : Wed Sep 21 2005 06:35 pm topmind writes: >>>> I dispute your "relational==table" definition, so I see not >>>> one thing that makes this table "relational". >>> >>> Well, my definition is correct. The history of >>> "relational" is based on that usage. >> >> Then no doubt you can provide a reference beyond your mere >> assertion. Even the example you just provided seems to show >> that it takes a *relation* to be *relational*. > > No. I was showing that one can have links within the > same table. But the links were not the main point being > illustrated. That was to make an "ability" point, not a > definition point. Why would you need to demonstrate an ability no one disputes? How about you back up your original claim "relational==table"? >>> Normalization is simply duplication factoring. The principle >>> exists in just about every code or data organizational >>> principle. In other words, it cuts across paradigms. >> >> But has a very *specific* meaning in relational databases. > > The normalization rules are pretty much *techniques* to > remove duplication. One does not even have to undstand relational > to identify the mere *existence* of duplication. No doubt, but you're dodging the point. Again. How about you stop waving your arms and address the actual point. (Now you'll claim you can't remember the original point.) >>>>>> http://en.wikipedia.org/wiki/Relational_model >>>>>> >>>>>> It starts out, "The fundamental assumption of the relational >>>>>> model is that all data are represented as mathematical relations,..." >>>>>> ^^^^^^^^^ >>>>>> Sounds interconnected to me. >>>>> >>>>> Well, it is misleading. The same link also says: >>>>> >>>>> "A table is an accepted visual representation of a relation; a >>>>> tuple is similar to the concept of row." >>>> >>>> How, exactly, do you think that refutes the first quote? >>> >>> Maybe it doesn't. Either way it does not appear to support >>> your assertation that "relation" means cross-table references >>> in the context of relational. >> >> Don't create straw targets. I never said cross-table. But in the >> interest of moving this along, perhaps there is a problem of lack >> of precision in words here. >> >> By "interconnected" I mean one record referring to another via a >> foreign key link to a primary key in another record--which, yes, >> can be in the same table (*typically* not, but that's irrelevant). >> >> Where we may still disagree (?) is that, IMO, a "flat table", that >> is a table with no relationships, is NOT relational. >> >> Hence "table" != "relational" > > The term "relational" has nothing to do with keys and their > referencing stuff. I used to think it did, but like you now, > I was wrong. You lost this one. Heh, so you say, but I say Michelle Pfeiffer secretly adores me. So, as you see, saying something has no connection with reality. EVERY resource I checked agrees. You have yet to produce anything other than arm waving to support your point. If you are right and I'm wrong, where's the proof? Should be easy enough to find. >>> 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. >>>> 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? 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"? >> Because, as I've said several times before, I can browse around the >> file system looking for likely folders. (I know this to be true, >> because I've done it!) >> >> I note that, in your reply, you didn't answer my question this time, >> either. I'll ask it again. Bob's gone, Fred hates him, so he's >> altered all Bob's attributes. >> >> How do you find the project file? > > [...total non-answer...] Heh, you've got to be an ignorant fool or a troll. NO ONE could be this willfully stupid. I've hung into this thread because it was engaging and there was room to believe you were serious about this stuff, but at this point I think you're either a jackass or a troll or an idiot. I don't have time for any of them, so this will be my final post in this thread. You go right ahead and write your reports -- you're right you probably have very little use for trees in report writing. -- |_ CJSonnack _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| .