david@daisy.UUCP (David Schachter) (02/20/85)
In article <552@decwrl.UUCP> ddb@mrvax.DEC (DAVID DYER-BENNET MRO1-2/L14 DTN 231-4076) writes: >While I'm not fan of VMS RMS, the fact that it provides reasonably >consistent and compatible file structures is a big win; Since all >indexed files on the system are RMS files, any program g >can read any file. Contrast this to the mess of unique file >structures "optimized" for particular applications, and completely >unreadable by anybody else. > >I'm not totally convinced that this is enough to justify the problems >that RMS often causes. But wouldn't it be nice to have some standard >subroutines to implement some standard more-complex file organizations? >Wouldn't it be nice to read your dbaseII indexed file into a C program? >Or to type your indexed file (assuming only textual data in it) and >see it in order by prin >primary key? > >Yes, you can do a special-case tool for each of these, but what a crock! > > -- David Dyer-Bennet > -- ...decwrl!dec-rhea!dec-mrvax!ddb It depends on the application. For simple operations on small databases, you are correct. But for complex operations on large databases, specialized data structures (not general purpose database management packages) and specialized access paths to disk storage are sometimes mandatory to get the performance of the system up. One of my company's competitors is proud of its "general purpose database" -based product line. In customer benchmarks, time after time, their files are consistently three to ten times the size of ours and their programs frequently run much slower. Does this mean we are right and they are wrong? No, of course not. (Only the marketplace will tell.) It means that our competitor has optimized for something different than what we optimized for. When it is necessary for one set of tools to look at a database that is properly the province of another set of tools, a TTL (a Thing-To-Thing-Lasher) is constructed. If the database contents are properly designed, a TTL can be constructed without much effort. "Proper" design is something one learns from experience. The only remaining problem is back-annotation: keeping all databases consistent so that data duplicated between databases is kept up to date. This "update" problem is, in practice, a red herring. Our customers prefer to be able to have their databases temporarily inconsistent. It allows them to make changes, to play around with different options, to try new ideas quickly, without committing the changes everywhere. It also allows them to split problems up among multi-person teams easily: the divisions fall naturally at the boundaries of the different databases. This is because our different sets of tools are split up the same way. In the few cases where updating is essential (say, in updating physical placement of parts on the printed circuit board back to the schematic diagram), we provide an update path. The code we wrote to do this is not trivial but it is not difficult. And again, it is a matter of trade-offs: we optimize for speed and space, not for generality. Our customers care more for the former two than for the latter one. So, it is not a "crock" to specialize, here and there, even when "there" is all the way to the O.S. kernel. I refer to the specialized flavors of UNIX for real-time work. Different needs require different solutions, that's all. The opinions expressed herein are my own and not necessarily those of Daisy Systems Corp or any sentient being. "Funny quotes cause hair on your palms."