Nikon FDUtility
in [Scanners]
|
From: Marjolein Katsma on 13 Feb 2006 05:26 Don (phoney.email(a)yahoo.com) wrote in news:osuru11dufql8eeu6jiqq6btcf3t5i01ms(a)4ax.com: >>And have you even considered *how* a hierarchical database has >>similarities with hierarchical directories? Have you ever *used* a >>hierarchical database system? I suspect not. > > You would suspect wrong. Since you want to get personal, I've > programmed hierarchical databases probably before you were even born, > or at least shortly thereafter. They didn't exist when I was born, and not for a long time after. In fact, I was legally of age by the time IBM came public with IMS thopugh development started a few years before. ;-) So now I'm even more puzzled why you bring in relational databases when a hierarchical model is clearly the best fit... -- Marjolein Katsma *Help with HomeSite/Studio: http://hshelp.com/ *Travel blog: http://blog.iamback.com/ *Spam reporting addresses: http://banspam.javawoman.com/report3.html
From: Don on 14 Feb 2006 08:03 On 13 Feb 2006 10:26:44 GMT, Marjolein Katsma <nobody(a)example.net> wrote: >So now I'm even more puzzled why you bring in relational databases when a >hierarchical model is clearly the best fit... That's because you're locked into the MS "solution"/thinking. Data can be encapsulated in many ways. That's what a (good) database designer does. They're not swayed by how the data *looks* at first blush but take the full context into consideration i.e. think laterally. The relational model is far more flexible than hierarchical and e.g. therefore more likely to be future proof. To discount it a priori just because the data may appear hierarchical is very shortsighted. Don.
From: Marjolein Katsma on 14 Feb 2006 10:53 Don (phoney.email(a)yahoo.com) wrote in news:h2l3v1t8nitrcgjud5tsle04gb8ftcqj5c(a)4ax.com: >>So now I'm even more puzzled why you bring in relational databases >>when a hierarchical model is clearly the best fit... > > That's because you're locked into the MS "solution"/thinking. I'm not locked into any OS/software manufacturer's thinking at alll - I've worked with way too many OSs for that to happen. I am simply stting that a file system that uses nested directories is more closely related to a hierarchical database than to a relational one. That applies equally to *nix as to MS OSs. > The relational model is far more flexible than hierarchical and e.g. > therefore more likely to be future proof. On flexibility we agree - but it's not always the most efficient solution. > To discount it a priori just because the data may appear hierarchical > is very shortsighted. I'm not discounting anything. I'm merely comparing a hierarchical *file system* with a hierarchical database, with its direct "links" to parents and siblings. In a sense a file system *is* a database, it's just not called that. ;-) -- Marjolein Katsma *Help with HomeSite/Studio: http://hshelp.com/ *Travel blog: http://blog.iamback.com/ *Spam reporting addresses: http://banspam.javawoman.com/report3.html
From: Don on 15 Feb 2006 06:40 On 14 Feb 2006 15:53:46 GMT, Marjolein Katsma <nobody(a)example.net> wrote: >>>So now I'm even more puzzled why you bring in relational databases >>>when a hierarchical model is clearly the best fit... >> >> That's because you're locked into the MS "solution"/thinking. > >I'm not locked into any OS/software manufacturer's thinking at alll - Yes you are because you are not even considering the relational model. Indeed, you can't even understand why I mentioned it showing how locked you are into the hierarchical MS thinking. >I've worked with way too many OSs for that to happen. I am simply stting >that a file system that uses nested directories is more closely related >to a hierarchical database than to a relational one. That applies >equally to *nix as to MS OSs. Which is all fine but not the point. The context was how bad MS design is. Therefore, when looking for alternate designs the last thing a good designer does is stay locked in the old paradigm. >> The relational model is far more flexible than hierarchical and e.g. >> therefore more likely to be future proof. > >On flexibility we agree - but it's not always the most efficient >solution. Which is why the*full* context must be taken into account. And by eliminating the relational model up front just because "it doesn't fit" the hierarchical *appearance* of the registry (which itself is a tiny part of the big picture!) you are not doing that. >> To discount it a priori just because the data may appear hierarchical >> is very shortsighted. > >I'm not discounting anything. I'm merely comparing a hierarchical *file >system* with a hierarchical database, with its direct "links" to parents >and siblings. Didn't it occur to you that the hierarchical appearance of the registry could be a *consequence* of the whole MS design? A good analyst does not accept that design but looks at everything. That's the whole point and why I mentioned the relational model. Don.
From: Marjolein Katsma on 15 Feb 2006 07:34
Don (phoney.email(a)yahoo.com) wrote in news:qe46v1p5vi2ctinapamqj0dhk0ishngc8n(a)4ax.com: >>I'm not locked into any OS/software manufacturer's thinking at alll - > > Yes you are because you are not even considering the relational model. I did consider teh relational model and rejected it as a poorer "fit" to how a file system with a nested directory structure works. Nothing to do with MS. Like I said, equally applicatble to hierarchical file systems in *nix. > Indeed, you can't even understand why I mentioned it showing how > locked you are into the hierarchical MS thinking. Indeed I can't. Because hierarchies are not MS' territory only - may OSs use hierarchical file systems. So what's MS about it?? > Which is all fine but not the point. The context was how bad MS design > is. Therefore, when looking for alternate designs the last thing a > good designer does is stay locked in the old paradigm. Of course. But I wasn't "looking for alternate designs" at all - I was looking for the best fit of a database system to *describe* a hierarchical file system. And that still is a hierarchical database in my book - as the best fit for *any* hierarchical file system (of which there are many). For an alternative system - it's possible a relational model may work; but the problem here is efficiency. Relational database systems may be flexible, but they're not always the most efficient systems for all applications. And for a file system efficiency is critical. Think about why hierarchical file system are so ubiquituos - MS is just one among many, and in good company ;-) > Which is why the*full* context must be taken into account. And by > eliminating the relational model up front just because "it doesn't > fit" the hierarchical *appearance* of the registry (which itself is a > tiny part of the big picture!) you are not doing that. I'm not eliminating anything, let alone "up front". It's *possible* that a relational system (model) may be a "better" solution than a hierarchical file system. > Didn't it occur to you that the hierarchical appearance of the > registry could be a *consequence* of the whole MS design? No, because we were talking about file systems and their parallels with database (system) models. In this context I wasn't considering the appearance (which is what it is: appearance - technically it's more like a network database) or the actual organization of the Registry at all. The registry is a non-heirarchical database, implemented in the hierarchical file system (just like any other database system implemented in a DOS / Windows environment). -- Marjolein Katsma *Help with HomeSite/Studio: http://hshelp.com/ *Travel blog: http://blog.iamback.com/ *Spam reporting addresses: http://banspam.javawoman.com/report3.html |