Date: Fri, 11 May 2007 17:54:09 +0200 From: Ivan Voras <ivoras@fer.hr> To: freebsd-hackers@freebsd.org Subject: Re: SQL in the base system Message-ID: <f223ji$7si$1@sea.gmane.org> In-Reply-To: <17988.35412.231093.411177@bhuda.mired.org> References: <200705102105.27271.blackdragon@highveldmail.co.za> <f20c8u$htp$1@sea.gmane.org> <4643C7DB.6000408@elischer.org> <f219f6$3ls$1@sea.gmane.org> <17988.35412.231093.411177@bhuda.mired.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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. 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. > 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. I don't think databases are so scary (but possibly that's lack of experience on my part). 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 (anecdotally, sqlite database can be read even in those circumstances, if you avoid the corrupt table). (And a corrupt block in an important metadata section is the same as a corrupt block in the directory record on the file system). The objective downside is that there are more blocks in a database. > 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. [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGRJGtldnAQVacBcgRAo22AJ9m/aws78NY/jbgLEwV98L9E++3NwCglfwN aV3f2xwPd/Yje/fUIvfFF/s= =m8Eq -----END PGP SIGNATURE-----help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f223ji$7si$1>