Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: topmind on 12 Aug 2005 01:07 [Part 2 of reply] > > >>> "Locations" are increasingly obsolete and meaningless in cyberspace. > >> > >> [The] bits still need a home *somewhere*. > > > > The "real world" is not tree-shaped for the most part. > > Mu. Un-Mu. > > > >> If you can't answer trivially simple questions about trivial examples, > >> what's the point in discussing more complex ones? > > > > If you can demonstrate that "structure" is a mathematically precise > > term, I will lend credence to your claim of my delusionment. Deal? > > Nope, since it really wasn't a structure question. Your inability to > answer a simple set theory question indicates you don't know set theory. > That's fine. Just checking. End of story. You are trying to use social intimidation instead of facts to back your points. > > > >> So, you bumped the issue up to a higher level and let them work out > >> which of THEM had a higher priority for your time. In other words, > >> it was *entirely* hierarchical. > >> > >> Which was exactly my point. > > > > Being "higher" is not necessarily hierarchical. Jet "A" may be higher > > than Jet "B" in the sky, but that does not necessarily imply that the > > placement of jets is hierarchical, for example. > > Jets in they sky don't have a relationship. Bosses and employees do. > So trees are about *social* relationships??? Your fuzz factory is working all 3 shifts this week. > Hierarchies *are* about relationships, and like it or not, the world > is *filled* with them. > Relationships, yes. Trees, no. > > >> You DO understand the difference between *using* a browser and writing > >> the code for it, don't you? > > > > To keep things clear, let's stick to one viewpoint or the other. You > > pick. Then, let's revisit the topic. Deal? > > Let's recap. You claimed GUI software--note the term: SOFTWARE--was > not hierarchical. I showed you that it was. Then you shifted to talking > about GUI usage. I meant it from the point-of-view of the application developer, and not the builder of the tool ("boxed" software). If that was not clear, I apologize. > > Software--in general--is hierarchically structured. It has high-level > routines, mid-level routines and low-level routines. Not event-driven software (from custom app perspective), at least not on the large scale. The closest thing would be a start-up form, which simply has an attribute or reference somewhere marking it as the starting point. However, it is trivially changable to another form just like picking a different student to be the hall minitor. > > > >>> You know, it is tough to describe this very well with words. > >> > >> For the fourth or fifth time: I UNDERSTAND THE PICTURE! > >> Do you understand the question? > > > > No. > > Once more: > > >You> But a pure tree has no duplicate nodes. > > >Me> Show me one authority that agrees. > > I don't know how to make the question plainer. Sigh. This gets back to the interchangability between duplicate nodes OR cross-branch links. They are interchangable views of the same thing. > > > >> Just because multiple node happen to *refer* to the same thing, the > >> nodes themselves--their place in the tree--ARE NOT DUPLICATES. They > >> represent distinct, *necessary* (we presume) occurrances. > > > > They *are* duplicates or pointers (cross-branch). As proof, if we > > want to change the name of or address in RAM of the called routine, > > we have to update multiple spots. It is a fricken graph. I would > > bet a paycheck on it if my wife would let me. They are multiple > > references to the same thing and they bust tree-ness. > > You'd lose that paycheck. Neener neener tree poop! > > Consider the "list" of routines visited during the execution of > a program. It represents the thread of execution. It is a DYNAMIC > thing generated by a running program. > > If that thread of execution re-visits a routine more than once, then > that routine MUST appear in the list more than once. THAT IS THE > REALITY--the program re-entered that routine. > > If you treat the "main" function that started the program as the root, > you can draw a tree that represents that list of routines. That tree > is "perfect" in the sense that no node "cross-connects" to any other > node. > > Yes, it does have "duplicate" nodes, but NO that doesn't bust "treeness" > (no matter how much you might wish it did). It is a "perfect" tree that > represents the thread of execution of the program. Like I keep saying, ANY graph can be turned into a tree with no cross-branch links simply using node duplication. That is not the issue. I don't dispute that hat-trick, but you keep wording this like I do. Any graph can be a "perfect tree" by your loose definition (allowing dups or CBLs). That does not get us any where. The more duplication and/or cross-branch links, the less useful tree-oriented tools and techniques will be. Maybe our threashold is just different: I may switch to sets when the dup/cross factor is something like 15% and you will wait until something 50%. > > > I am only defining "pure tree" as one without duplication. > > Your definition is seriously broken. Find one authority that agrees. It is a working definition to describe a situation, not a formal one. It would be interesting to see an algorithm that scores node dup or cross-branch-links of a candidate tree. > > > Are you suggesting that since reality has duplication that our > > databases should also even if there are techniques to remove it? > > But they don't *remove* it, they (in a sense) compress it by normalizing > the data. In a database version of the call graph, you'd have one record > for each routine and a separate--"duplicate"--record in some other table > for each time you visited that routine. Normalizing it just turns the duplication into a cross-branch "pointer". Like I keep keep keep saying, both representations are interchangable. But the "pure tree" buster is still there regardless of wether you represent it with dups or CBL's. > > (In fact, given the appropriate query, the duplication "returns".) > > > >>>> ...the parse tree itself is still a "pure" tree, > >>>> because each "IF/ELSE" is contextually different. > >>> > >>> ...I ignore the IF/ELSE issue here, but would like to point out > >>> that in some languages control constructs such as IF and WHILE are > >>> simply function calls with some fancy scope management features > >>> used rather than being built into the language. > >> > >> 1. That doesn't change a thing with regard to parse trees. > >> 2. That is USUALLY the case unless you're programming in assembly. > >> (That is, If/else and while are high-level constructs implemented > >> by the language--they ALL translate to something more complex > >> than the words "if" and "While".) > >> > >> We can apparently add parse trees to the list of things you don't > >> really understand. > > > > In languages such as SmallTalk, LISP, and TCL, one can roll-their-own > > control structures using the language itself. Do you question this? > > Not at all, but it has nothing to do with parse trees. Then please clarify. I see no need to make a distinction between control structures and functions because in some languages that are the SAME thing. The other languages simply "hard-wire" them into the syntax or lang definition. > > > If not, then please apoligize for insulting me. > > It still looks like you don't know what a parse tree is, so no. Whenever you lose and argument, you seem to accuse me of ignorance. Prove I am ignorant with details instead of claim it with vague accusations. By the way, here is an example from c2.com wiki: This code: sub x(a,b,c) { i = a while (i < 20) { if odd(i) { i = i + b } else { i = i + c print("in else") } print("in loop") } // end-while print(i) } Can be represented as a tree: sub x(*) -------- * * * * * * * * * * * * * * * * * * i = a while(*) print(i) ----- ----- -------- * * * * * * if(*) print("in loop") -- ---------------- ** * * * * * * i=i+b else ----- ---- * * * * i=i+c print("in else") ----- ---------------- (*) = full expression not shown > > > >> So? The point was that this GUI program definitely has higher and > >> lower level functions. Apparently you no longer disagree. > > > > It *can* be implemented that way under the hood, but the implementation > > is moot to the user (app developer). > > I have been *talking* about the app developer all along. > I have not been talking about implementing the GUI engine. > > The code I showed you was developed (by me) as an APPLICATION. > As I said last time: Yes, but I asked for an *event driven* example. That is not event-driven, or at least is not the event-driven part of the code. > > >> This isn't about anything hidden or under the hood. > >> It's about how you write a program. > >> It's about how you analyse a problem and break it down. > > > > Where is the "tree" in an event-driven application? > > I **showed** it to you several posts ago. That was APPLICATION code. app, yes. Even-driven, no. Please, show us an "event-driven tree". I have never seen a Unicorn. > > > Remember, I am NOT asking how one may impliment the event manager. > > We are using the tool, not making it here. > > And I have responded ALL ALONG as an app developer. Only if one is rolling their own event handler. > > > -- > |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | -T-
From: Chris Sonnack on 12 Aug 2005 14:22 Dmitry A. Kazakov writes: >> Do you think fuzzy logic is implemented without binary? > > Implemented is a wrong word here. Logic isn't implemented. Oh. So....er.... those fuzzy logic tools I was using a few years ago.... were they grown from, like, seeds or raised from pups? (-: >> Multi-state logic is built on binary logic. Learn basic information >> theory. It ALL can be broken down to 1s and 0s. Every, um, BIT of it. > > No, this is wrong. (Has anyone informed Shannon?) > Though it is possible to build some meta system based on crisp > logic to analyse the propositions of the "object" [non-crisp] > logic. Probably this what you meant. Yep. -- |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________|
From: Chris Sonnack on 12 Aug 2005 18:27 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 <Chris(a)Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________|
From: Chris Sonnack on 12 Aug 2005 19:14 topmind writes: >> Your inability to answer a simple set theory question indicates you >> don't know set theory. That's fine. Just checking. End of story. > > You are trying to use social intimidation instead of facts to back your > points. You find it intimidating being asked to demonstrate that you know what you're talking about? How sad. >>>> So, you bumped the issue up to a higher level and let them work out >>>> which of THEM had a higher priority for your time. In other words, >>>> it was *entirely* hierarchical. >>> >>> Being "higher" is not necessarily hierarchical. Jet "A" may be higher >>> than Jet "B" in the sky, but that does not necessarily imply that the >>> placement of jets is hierarchical, for example. >> >> Jets in they sky don't have a relationship. Bosses and employees do. > > So trees are about *social* relationships??? Don't be willfully stupid, there are many types of relationships. I'd think someone hot for RELATIONAL databases would understand that. >> Hierarchies *are* about relationships, and like it or not, the world >> is *filled* with them. > > Relationships, yes. Trees, no. Fine. You can open an office between the Flat Earth Society and those twits that think we didn't *really* go to the moon. >> Let's recap. You claimed GUI software--note the term: SOFTWARE--was >> not hierarchical. I showed you that it was. Then you shifted to talking >> about GUI usage. > > I meant it from the point-of-view of the application developer, and > not the builder of the tool ("boxed" software). If that was not > clear, I apologize. Once, again, I understood and have been answering that way all along. The code I showed you was a VB **application** I wrote. VB comes out of the box. >> Software--in general--is hierarchically structured. It has high-level >> routines, mid-level routines and low-level routines. > > Not event-driven software (from custom app perspective), at least not > on the large scale. Have you ever actually *written* a GUI application of any size? Are you under the impression that "event driven software" is JUST event handlers? The larger the application, the more it does (besides handle various events). The more it does, the more it's going to be hierarchical. > The closest thing would be a start-up form, which simply has an attribute > or reference somewhere marking it as the starting point. And you don't think there's start up **code** that sets things up? You don't think some events result in executing large bits of code? Sometimes there's quite a lot of it, in fact. When I launch the WebSphere App Developer Studio, it takes a couple *minutes* to launch. It's doing a LOT of set up stuff--all (I have no doubt) hierarchically structured. When I compile all projects in the workspace, it can go on for several minutes. Again, I'd bet you a year's salary the code behind the compile is hierarchically structured. >>>You> But a pure tree has no duplicate nodes. >> >>>Me> Show me one authority that agrees. >> >> I don't know how to make the question plainer. > > [..yet another non-answer...] Fine, whatever. Obviously you can't cite a single authority, and for good reason. No part of the definition--even of formal trees-- prohibits duplicate nodes. > [big snip] What's gotten lost here is your understanding of the context. What most of this has been about is the occurrence of trees in nature and programming. As *data* *structures*, they are natural and vital. As *taxonomical* structures, you can run into problems, and that's where the idea of duplicate nodes or cross-branches can be an issue (albeit, in programming, a solvable one). (I think you'd do better if you recognized how important and useful trees are--particularly as data structures--and didn't try to do the equivalent of claiming we never landed on the moon. Intelligent people know we did and that trees do occur in many places in nature and programming and are terribly useful. That you can only push your own agenda at the expense of another is--in my book--an almost certain sign of a kook and a fool.) >> Not at all, but it has nothing to do with parse trees. > > Then please clarify. I see no need to make a distinction > between control structures and functions because in some > languages that are the SAME thing. The other languages > simply "hard-wire" them into the syntax or lang > definition. Agreed with you last time. Once again, it has nothing to do with (1) parse trees in general and (2) duplicate nodes in a parse tree, which (3) IS A PURE TREE (no branches reconnect). >> It still looks like you don't know what a parse tree is, so no. > > Whenever you lose and argument, you seem to accuse me of ignorance. I don't think I'm losing this argument at all! In fact, I'm quite sure that, were it being judged purely on its debate points, you'd have lost it long ago. But regardless of that, I just plain think you ARE ignorant. > Prove I am ignorant with details instead of claim it with vague > accusations. The fact that you don't seem to recognize how badly you've lost this debate or how often I have apparently overwhelmed you with techical details ought to make it pretty plain that I HAVE proved it. > By the way, here is an example from c2.com wiki: Gee, you can copy and paste. Can you *discuss* what you pasted? Do you understand why (1) how an "if/else" is implemented is totally irrelevant, or (2) why a parse tree is a pure tree? > This code: > [snip] > Can be represented as a tree: > [snip] Indeed it can. Do you understand what you pasted? >> The code I showed you was developed (by me) as an APPLICATION. >> As I said last time: > > Yes, but I asked for an *event driven* example. That is > not event-driven, or at least is not the event-driven > part of the code. And, in fact, as a medium-small-sized application, the event-driven parts are not the bulk part of the application. I showed that to you to counter your claim that GUI software was not hierarchical. It most certainly is. The event handlers may all exist at the same level of the hierarchy (although this doesn't have to be true), but they--if they contain much code at all--will be their own little hierarchies. In fact, here's an example of hierarchy in event-handlers: In some systems, the main window receives events, which it may process and return as fully processed or pass on to a child element of the window. That child element may fully process the event OR pass it in turn to a child control. So there ya go--you're even wrong about events not being tree-shaped. -- |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________|
From: topmind on 13 Aug 2005 04:11
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 <Chris(a)Sonnack.com> _____________| How's my programming? | -T- |