Mitch Bradley wrote: > Hierarchies work well only in very rare cases where the appropriate > structure for the hierarchy is blindingly obvious to everyone. > > In other words, almost never.
:-) I'm not arguing for a hierarchy cast in stone. If the "leaves" are unique, you can change the hierarchy while still retaining access to items that were filed under a previous version of the hierarchy. I view the hierarchy as a tool for finding items that you can answer a few questions about. If the hierarchy can ask these questions, and give you the list of possible answers, you can find the item. The difference to a table is that the questions don't have to be consistent across branches. This is useless of even bad if you have a large number of (more or less) identically structured items, such as picking a capacitor, a diode, or a resistor. Even there, you can occasionally get parameters that are normally unspecified, but this type of surprises is rare. A hierarchy shines where you have lots of properties, of which each only applies to a small number of items, but where these items are parts of easily identifiable clusters. I think this is where a component catalog differs most from a catalog of types of components. The former absolutely needs tables, while the second should contain very few table-izable categories or questions. E.g., right now, we have one "R", yet even the electronics shop around the corner has at least hundreds of different resistors. Again, I'm assuming that you already know what you're looking for, and can thus answer the questions in any order, as long as they are about prominent features of the item. E.g., I would rarely even consider selecting components by weight or thermal impedance. > Companies are forever reorganizing their hierarchical reporting structure. Yes, but that's because certain people need to create work for themselves to appear useful ;-) Besides, I don't think transistors would be concerned whether they report to the same boss as LEDs, or to someone one hierarchical level below :-) > The locations of things in the Unix file system change across Unix > flavors, releases, time, and individual installations. True, sadly. The main problems here were, initially, NIH paired with the need to have a "different" product, and later on mainly legacy. Things have improved quite a bit, mainly through extinction and the understanding that not aiming for gratuituous difference is good. There is also another property that differs from what I'm proposing: on Unix, the directories above a file system object are also part of the unique name of that object. So it's not only the people looking for some file who get confused when something changes, but also any program that knows about that file. That's one reason why changes in the hierarchy are so painful. > Attempts to organize the web (and earlier, all human knowledge) in a > hierarchical fashion have all failed spectacularly. Unstructured search > was the clear winner. But isn't our problem space a little bit smaller ? :-) I think a closer example would be the directory tree of the Linux kernel: there, we have a fairly clear structure where things rarely change place. Yet, new stuff gets added at many levels all the time. If I look for, say, some driver, I usually have a straight path to follow. This consistency is achieved not only by submitters automatically making the right choices, but also through peer review and by limiting checkins to a relatively small group of people. This ensures some degree of consistency, particularly where unwritten laws are concerned. Besides, I'm not against unstructured search, quite to the contrary. But I would view this as a supplement, not as the main way of (not) structuring things. > Very few people can organize their files and email well enough to > remember where they put everything. That's why search functions are > becoming absolutely crucial in the modern era of large disks. That's because they don't take the time to organize, the effort vs. use of organization is high (I have to organize all my mails, and I'm also the only person who benefits from this order), the organization criteria change often, and it's hard to provide generally acceptable templates. The point of having a well-defined hierarchy would be exactly to take the time and expertise to figure out where things should go. At the same time, perfection should be a non-goal, so there has to be room for changes, if and when they are necessary, and there should be a fallback solution. In any case, properly designing a relational database isn't necessarily trivial, in particular if the data actually doesn't fit tables very easily. So, to summarize, here's what I have in mind: - a hierarchy (directory tree) as the basic structure - each item filed under this structure has a unique and permanent name (which may be all or part of the actual file name) - an (unstructured) full-text search over item names and descriptions as a fallback solution Another great advantage of a using a directory hierarchy with flat files is that all the existing tools for manipulating, transferring, searching, etc., files can be readily applied, and we don't depend on the database to have all that functionality. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net/____________________________________________/ ------------------------ Yahoo! Groups Sponsor --------------------~--> Something is new at Yahoo! Groups. Check out the enhanced email design. http://us.click.yahoo.com/SISQkA/gOaOAA/yQLSAA/W4wwlB/TM --------------------------------------------------------------------~-> Please read the Kicad FAQ in the group files section before posting your question. Please post your bug reports here. They will be picked up by the creator of Kicad. Please contribute your symbols/modules to the library folder in the group files section. For building Kicad from source and other development questions visit the kicad-devel group at http://groups.yahoo.com/group/kicad-devel Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/kicad-users/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
