Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?] To : comp.programming,comp.object From : topmind Date : Sat Aug 13 2005 02:11 am Chris Sonnack wrote: > 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". Well, my definition is correct. The history of "relational" is based on that usage. Note that "relations" (in a link sense) can be to the same table, such as a table that can represent hierarchies: Name EmployeeID BossRef ---- ---------- ------ Fred 1234 4822 Mike 4838 4822 Jane 4822 5301 ...etc... Here "BossRef" is a foriegn key to the same table. Jane is the boss of Fred and Mike. (I am not necessarily proposing this as a "good" schema, only illustrating self-referencing tables.) > > 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. Perhaps I should avoid it if I do. It can have multiple interpretations. > > >>> 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. Normalization is simply duplication factoring. The principle exists in just about every code or data organizational principle. In other words, it cuts across paradigms. The principles of normalization as they apply to tables is simply a set of "steps" to help provide or recognize duplication removal. (Normalization levels beyond 3 may not reduce duplication and are controversial.) > > > >>> 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. In the end, I don't think anybody challenged the idea of maps and tuples being representationally equivalent. If they did, they stopped defending it such that their arguments are not supplied. > > 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. Please try to provide enough of the original discusion to trigger memories of the context in the future when you trim your replies. I would appreciate that. Use ellipses if necessary. > > >> 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. > > > >>>> 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. 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). That way one can refer to just the configuration name in the software instead of having to supply the configuration details themselves in the software. It is abstraction at its best. If you have a better suggestion, I would like to hear it. It is a logical name, NOT a physical name. > > > >> 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. Few will dare to overhaul the paths of a large system because of the chaos it causes to existing path references, NOT necessarily because they are satisfied with the tree branching. The paths are essentially primary keys that carry meaning but cannot be changed without heavy disruption. The system grows married to the ugly paths. > > >> 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? That is an implimentation detail. There is nothing in relational theory that says "cells must be small". I don't know what the upper limits are on the leading vendor's products. Generally they up the threashold over time. Note that I agree existing RDBMS are probably not up to the task of being file/folder managers. They are not tuned for that use. > > >> 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. UPDATE folders SET shared=true WHERE [folder criteria] However, in practice a given folder is rarely best shared with the whole entire world. Thus, some kind of role-based approach or Access Control list may be more appropriate for larger organizations. > > > >> 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? How is this any worse than changing tree paths to represent the newer changed information? If attributes can lie, then so can tree paths. Either there are sufficient attributes to describe a thing or there are not. If you want to keep a history table for searches based on past attribute settings, you can. (Many RDBMS provide attribute change log options so that one can study the history of something.) It is simply the GIGO principle. Unlike tree paths, adding or removal attributes is usually not going to bust the primary key of a table. Orthogonal info is kept orthogonal. Tree paths don't provide very much orthogonality to attributes. > > > -- > |_ CJSonnack _____________| How's my programming? | -T- .