Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?] To : comp.programming,comp.object From : Chris Sonnack Date : Mon Aug 15 2005 01:29 pm topmind writes: >tm> If it has one table, it is still relational. >CS> (This, as stated, is *absolutely* incorrect, BTW.) >>> Prove it. >> >> 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 - > Note that "relations" (in a link sense) can be to the > same table, such as a table that can represent hierarchies: > [snip] They *can* be, yes. They can also *not* be. Your initial statement is incorrect *as* *stated*. >> 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". > > 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*. >>>> http://en.wikipedia.org/wiki/Database_normalization >>> >>> I dispute that. >> >> Okay..... can you support that disputation in any way?? (Apparently not.) >> The line from that page, "In the relational model, formal >> methods exist for quantifying "how normalized" a database is," >> seems to suggest to me normalization is a fundamental part of >> a relational database. > > 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. >> But I do NOT see any relation to answering the question I asked. >> Can you answer it, or were you just throwing words out randomly? > > Sorry, but I lost the context of this section of discussion. No, you didn't. It was IN the post you're replying to. In fact, you quoted it in YOUR post. Here it is again: >You> However, there are different ways to interpret "duplication" for >You> empty cells. Empty cells do not have to take up physical space, >You> especially in "dynamic relational". >Me> Empty cells? Where did that come from? Are you talking about >Me> NULL fields? Row duplication?? What??? >>>> 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" >> If the database moves to a different machine (with a different >> name, obviously), then no. The ODBC setup must be tweaked for >> the new hostname. > > 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. >> You want to store files in a database. What happens when >> those files are very, very, very large? > > That is an implimentation detail. But a very significant one with regard to, um, implementing such a system in the real world. > I don't know what the upper limits are on the leading vendor's > products. Doesn't matter. What happens when I want to store the DB itself in your virtual file system? You can't store a full ten-gallon container inside another ten-gallon container, because there's no room for the container itself. >>>> Or consider this: in a FS, I can define a folder as publically >>>> shared, read-only, and any file I drop in there is available >>>> to those I've shared the folder to. I can casually share and >>>> unshare files just by moving them in and out of the folder. >> >> [...] >> 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. >>> Just because you are not adept at non-tree searches does not mean >>> the rest of us are also not. >> >> Okay, so describe how you would find Bob's old project files after >> Fred was done changing the attributes? > > How is this any worse than changing tree paths to represent > the newer changed information? 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? -- |_ CJSonnack _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| .