Re: Caldera installation - something Debian should learn
This is getting way offtopic, so this is my last post on this thread.
On Sat, Apr 24, 1999 at 03:24:19PM -0700, R Garth Wood wrote:
> On Sat, 24 Apr 1999, Marsh Ray wrote:
>
> > I think speed is a maybe, but I don't think I would agree with
> > you on the size.
> >
> > The reason the text files in /etc seem complex, is because they have a
> > complex structure to model complex data. I'd like to see someone
> > take a general-purpose database tool and try to model the content and
> > structure of the /etc tree. I've got over 500 files in mine,
> > and probably half of them would need their own table in this schema.
> > This is where the NT registry fails: it's fine for representing
> > heirarchical data (or would be if it were managed properly,) but
> > program configuration data is, by definition, n-dimensional.
>
> This is interesting. What do you mean? Can you give an example?
The relational database model has shown itself useful for storing large
amounts of data consisting of multiple records with a semi-regular
structure. Tools (like SQL) have been optimized for processing this type
of data.
A quick look through my /etc shows many files have a structure in one
of three categories:
1. lists of unique parameters and their associated values
2. lists of records containing a sequence of values
3. some combination of the two
Data like (1) isn't cleanly represented in the relational model, IMHO. You
have 2 options for that. One way is to have a big table with columns for
each parameter, and a single row which holds their values. This is going
to be wasteful in the typical DB backend (compared to a textfile) and isn't
easily expanded (you have to alter the tables). Another method is to define
the parameters in some tables, and in another table store their values.
The problem with this approach is that SQL queries against this kind of
data are exponentially more complex than against actual relational-model
data. You can usually construct a query, but you have to use subqueries,
and you may lose proper data-type checking. Your DB backend optimizer
may have a difficult time with it, too.
Data like (2) is perhaps better suited for the relational model, but you're
still going to need at least one table for each config file. This is what
I meant by that last sentence. A good example would be passwd and groups.
They are, in fact, relational tables managed by a DB library. Two files
that represent two tables.
Data like (3) combines the complexities of both structures.
> > If you're going to claim this speed benefit, you're going to have to
> > build indexes into this database. That's gonna grow your size enormously.
> > My /etc is 2 MB, probably much less if you strip out all the comments.
>
> I wouldn't do that, comments are good.
Yes, but when was the last time you saw them in a database schema?
[lines cut]
> > user figure out how to fix a binary file that some program rejects?
> > We're back to the "oh, the registry's become corrupted, nothing-we-can-do,
> > better re-install" that the NT users are so familiar with.
>
> I think the problem of corruption will be great;y helped by the
> open source model:
> * If it does corrupt you have the source and can probably fix it.
> * will prob won't become corrupt for the same reason linux
> doesn't crash that often
Open Source developers have to maximize their resources, too ya know. There
is a finite number of person-hours available for projects like Debian.
If the current way works well (and IMHO it does) no reason to throw it out.
Why don't you contribute to the PAMifying work? You could consider that to
be a start on your DB-ifying work, because the library interface could be
your backend, too. When that was finished, you could then rewrite the
configuration routines for every other program, as well.
> Well promise me you'll try it with an open mind and not one
> poisoned by registry troubles.
I hope NT hasn't poisioned my mind. :-)
- Marsh
Reply to: