Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?] To : comp.programming,comp.object From : topmind Date : Fri Aug 26 2005 10:50 pm Chris Sonnack wrote: > topmind writes: > >> 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*. 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. > > >> 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. 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. Different paradigms may have their own set of techniques or rules-of-thumb for removing duplication. > > > >> 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" 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. > > > >> 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. Are you suggesting having the configuration point to yet *another* configuration that is virtual? It may be possible, but too much indirection can complicate maintanence just as much as too little. I don't think many DBA's would vote for yet another layer. > > > >> 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. I perfectly agree that the current batch of RDBMS are not tuned to replace file systems as is. It would probably require that a DB engine be tuned for that specific purpose to be competative with tree filers. (Some say the IBM AS/400 does it, but I have not tested it myself.) > > >>>> 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. 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. > > >>> 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? > How is this any easier or worse than somebody changing a file path name? It is possible to change folder names, you know. In fact, Microsoft's file browser makes it too easy to change the name: you click in the wrong spot and you can truncate a folder name. If you argue that it is harder to change tree paths (making them "safer from tampering"), then you have proved my rigidity point anyhow. You are between a rock and a hard-place. Or in your case, a tree and a rock. > -- > |_ CJSonnack _____________| How's my programming? | -T- .