Re: SQL in the base system

In <f223ji$7si$1@xxxxxxxxxxxxx>, Ivan Voras <ivoras@xxxxxx> typed:
Mike Meyer wrote:
Perhaps this is a good time I should mention that I think sqlite would
also be good for the password and login databases? :)

Someone has already pointed out the horror that is the Windows
registry. IIUC, even MS has figured out this is a bad idea, and gotten
away from it with Vista. But it's been tried on Unix systems before as

This is the first time I hear about Vista - AFAIK it relies even more on
registry, to the point that the boot process also uses it.

That may be so. I haven't dealt with Vista, but had heard it dropped
the registry dependencies.

Registry was pretty bad in Win9x, but AFAIK most of those issues were
because FAT32 is a bad file system. I never had a registry problem (on
many machines) running Win2k and WinXP.

No, that only deals with it getting corrupted by the file system. I've
had registery problems as late as XP/SP2. And of course, you can't
blame the issues with the AIX object manager on FAT32.

Using a binary format brings it's own problems. How hard is it to fix
a corrupt database? How hard is it to figure out that the database is
so corrupt you aren't going to get anything out of it, so you might as
well give up? How robust is it - can a corrupt block fry the entire
database? How about portability - can I move the file to a completely
different architecture and still get the data from it? If any of these
are noticably worse than they are for text files, changing is probably
not a good idea.
Most of those issues are valid, but don't strongly advocate against
databases, because the same issues (corruption, rebuilding, manual
inspection) are present for directories of text files. Endian issues are
solved in sqlite.

Yes, they are present no matter what representation you use. The
question is - how do the answers change if you change the
format. These days, cross-platform means you deal with length as well
as endian issues. Or maybe you don't, depending on the db. I know the
answers for text files (easy, easy, very, yes). Can you propose a db
scheme that gets has the same answers?

Someone else mentioned XML. Well, it's easy to parse - assuming you
read that as "someone else wrote the parser for us". That's true for
lots of things. I also question the sanity of using it. But I wind up
doing a lot of it, because my clients like the buzzword compliance. I
regularly beat on them to take advantage of what XML can do that other
formats can't. Meaning I make them install validation software, and
pay me to write schemas for them, and get them to add hooks to the
repository so you can't check in xml files that don't validate. But if
you're not going to do that kind of thing, the major feature XML
brings is the buzzword compliance.
Bofore I get misunderstood, I'd like to say that I'm not actually such a
big fan of XML, but I think it's currently the lesser of evils. The
alternative is either to create a one-off file format for each and every
purpose (aka "the unix way"), or use some XML-replacement (JSON &
others) which has most of the evils of XML and introduce lack of support
from existing tools.

I hate to tell you this, but your XML solution would still consist of
a bunch of one-of file formats for each and every purpose. Using XML
just fixes the syntax for the file, not the semantics. Settling on XML
(or JSON, or INI, or cap files, or ...) is sort of like settling on
UTF, only less obviously a win. Sure, you get to use canned code that
will turn you text file into a structure in memory. But you still have
to figure out what it all means.

As you say, the XML toolset is the real win. Smart editors,
validators, schemas (which make the editors and validators even more
powerful) are all good things. Most people don't really seem
interested in this beyond editors. That's not really much of a win.

<mike
--
Mike Meyer <mwm@xxxxxxxxx> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • SQL in the base system (Was: New FreeBSD package system (a.k.a. Daemon Package System (dps)))
    ... Someone has already pointed out the horror that is the Windows ... it's config system as they do about the Windows Registry. ... How hard is it to figure out that the database is ... Someone else mentioned XML. ...
    (freebsd-hackers)
  • Re: SQL in the base system
    ... registry, to the point that the boot process also uses it. ... How hard is it to figure out that the database is ... If you would get a corrupt block in the middle of a complex text file, it would wedge your system just as bad as if you got a bad block in a table in the database. ... repository so you can't check in xml files that don't validate. ...
    (freebsd-hackers)
  • Re: Saving User Application Data
    ... XML, Database and Registry are all possible choices. ... Check out the Configuration Management Application Block, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Config file to turn on/off features ?
    ... > places you could store configuration are in the registry or a database. ... XML files for configuration are easy for users to edit, ... > the user to corrupt the config file. ...
    (microsoft.public.dotnet.framework)
  • Re: My library is gone! "There are no items in this library yet"
    ... Also, FWIW I just tried to reproduce the registry failure below, but I couldn't get the bad behavior that I saw earlier. ... I had begun to formulate an opinion that rebuilding the database does not only fix a corrupted database but also could fix other configuration and settings. ... If there was a way to get this to the Windows Media Player product team, it could help in troubleshooting the high number of reportedly corrupt databases. ... WMP11 isn't letting itself access or create any libraries, ...
    (microsoft.public.windowsmedia.player)