From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 3FDABBBCA for ; Fri, 29 Feb 2008 08:40:39 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACZFx0fVujhf/2dsb2JhbACSPJp7 X-IronPort-AV: E=Sophos;i="4.25,425,1199660400"; d="asc'?scan'208";a="23192805" Received: from witko.kerneis.info ([213.186.56.95]) by mail4-smtp-sop.national.inria.fr with ESMTP; 29 Feb 2008 08:40:38 +0100 Received: from [2001:660:3301:8061:216:41ff:fe10:7097] (helo=tatanka.kerneis.info) by witko.kerneis.info with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JUzrC-00027I-BL for caml-list@yquem.inria.fr; Fri, 29 Feb 2008 08:40:38 +0100 Received: from localhost ([127.0.0.1] helo=tatanka.kerneis.info) by tatanka.kerneis.info with esmtp (Exim 4.69) (envelope-from ) id 1JUzqh-0001NP-U5 for caml-list@yquem.inria.fr; Fri, 29 Feb 2008 08:40:08 +0100 Date: Fri, 29 Feb 2008 08:40:00 +0100 From: Gabriel Kerneis To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Long-term storage of values Message-ID: <20080229084000.2d3a95fe@tatanka.kerneis.info> In-Reply-To: References: <191751.36007.qm@web54607.mail.re2.yahoo.com> Organization: ENST X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.8; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/oy1yMk9D+9dPDl8qPyAAeqh"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-SA-Exim-Connect-IP: 2001:660:3301:8061:216:41ff:fe10:7097 X-SA-Exim-Mail-From: kerneis@enst.fr X-SA-Exim-Scanned: No (on witko.kerneis.info); SAEximRunCond expanded to false X-Spam: no; 0.00; caml-list:01 data:02 data:02 library:03 thu:05 converting:05 awful:05 brian:05 problem:05 ecrit:06 underlying:06 long:06 pointing:06 structure:07 structure:07 X-Attachments: type="application/pgp-signature" name="signature.asc" name="signature.asc" --Sig_/oy1yMk9D+9dPDl8qPyAAeqh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, Le Thu, 28 Feb 2008 20:14:27 -0500 (EST), Brian Hurt a =E9crit : > So, mistake number one: either use the data, and structure your data > (at that layer) to take advantage of it, or don't use a database. > [...] > So that's mistake number two: you're communicating between different=20 > versions of the program with an ill-defined (at best) and not=20 > generic protocol/file format. Right. But imagine you're communicating with yourself (saving and restoring data). And you need to retrieve the data *efficiently*. Converting from a generic file format is not efficient - not if you have to retrieve the data 100 times per second (imagine a CMS on a popular website). It would be faster to use an internal file format. And, of course, keeping a backup in a generic file format. But now, here is the big deal: when your internal data structure changes (and it might not even be under your control, imagine you're using a third-party library), you have to convert your generic backup to the newer internal format. And if you have, say, an awful lot of backups, it might take soooo long... Of course, it's only once in a while, but when this happens, how do you deal with it? Remember the efficiency is the key point, here. I don't think there is a generic solution to this problem. But I'm just pointing out the underlying requirements, in case some would have one. Regards, --=20 Gabriel Kerneis --Sig_/oy1yMk9D+9dPDl8qPyAAeqh Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHx7bX6a2JmXQu5bYRAvL6AKCPOAcCBfMnSBOETMn4bG/oEZevJACgp8CG RG1pzkwbs/vlyMo7YMdvDPw= =upr8 -----END PGP SIGNATURE----- --Sig_/oy1yMk9D+9dPDl8qPyAAeqh--