Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?] To : comp.programming,comp.object From : Chris Sonnack Date : Fri Aug 12 2005 06:27 pm Snipping everything that didn't move this forward shorted it a lot... topmind writes: >>>>>> Think you can write an SQL query to return a subset of >>>>>> the records in that table? Of COURSE you can. >>>>> >>>>> If it has one table, it is still relational. >> >> (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 - 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". Given something containing this table that also supported SQL, you could write: Select NAME,COLOR from TABLE order by NAME >> Regardless, in the case I had in mind, it wasn't. The >> question remains: given a flat-table (non-relational) >> database, can you still write an SQL query. Answer: >> of course you can. SQL is JUST a query language. > > What exactly is a "flat" table? See above. Similar to a flat file--an expression I believe I've seen you use recently. >>> I am not sure normalization is a requirement for "relational". >> >> For the pure (mathematical) definition, I'm pretty sure it's >> one of the central, defining features! >> >> http://en.wikipedia.org/wiki/Database_normalization > > I dispute that. Okay..... can you support that disputation in any way?? 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. >>> However, there are different ways to interpret "duplication" for >>> empty cells. Empty cells do not have to take up physical space, >>> especially in "dynamic relational". >> >> Empty cells? Where did that come from? Are you talking about NULL >> fields? Row duplication?? What??? > > This is getting into a long, drawn out debate about the > nature of relational. Here is something related: > > http://www.c2.com/cgi/wiki?TupleDefinitionDiscussion Perhaps related in the sense that other folks (who seem to know what they're talking about) seem to think you don't. Or related in being a long, drawn out debate. 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? >> 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? >>>> No, it's a data storage concept. There are many reasons why the >>>> physical storage location might change. >>> >>> Huh? Please clarify. >> >> Migration, rollups, new systems, OS changes, format changes, etc., etc. > > Yes, but ideally we abstract away from those. For example, we may > create an ODBC name for a database reference. Even if the machine > is moved, that same name can still point to the same one. If the SAME machine is moved, yes. 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. >> File systems have more flexibility than databases. > > Fooey! You already agreed that paths were fragile, being > hard-to-change. I'll accept the "broken path" issue as "cost of business" to gain the inherent flexibility of a file system any day. I don't break file paths THAT often--I do use the power of a file system many, many times every day. >> Consider this: what happens when several of my files *ARE* databases. >> Big ones. > > I am not sure what you are getting at. You want to store files in a database. What happens when those files are very, very, very large? >> 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. > > I see no reason why a relational system cannot have the same > kind of thing. However, usually you will find that security > is not hierarchical as it scales. 1. This has NOTHING to do with hierarchical, this is about the idea of replacing a file system with a database system. 2. Describe how you think an RDBMS would provide such a simple service. >> With a database, you can only hope there's an attribute still attached >> that might turn it up in a query. Maybe so, maybe not. Maybe when >> Fred took over, he changed the attributes just slightly due to his own >> personal preferences. > > 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? -- |_ CJSonnack _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| .