From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1920 invoked from network); 18 Feb 2021 00:00:06 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 18 Feb 2021 00:00:06 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 72CCA9C831; Thu, 18 Feb 2021 09:59:59 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 6847F9B95A; Thu, 18 Feb 2021 09:58:58 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="D9Vx7azz"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 187459B95A; Thu, 18 Feb 2021 09:58:56 +1000 (AEST) Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) by minnie.tuhs.org (Postfix) with ESMTPS id 9BC459B55C for ; Thu, 18 Feb 2021 09:58:54 +1000 (AEST) Received: by mail-oi1-f171.google.com with SMTP id j5so76872oie.1 for ; Wed, 17 Feb 2021 15:58:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s8FazZgYGXhrY4wv6EKFyKgXYZHa32vXegEt6uijSRk=; b=D9Vx7azz2P4kxaGx+sIMkhSZw2Sr5mszWHtPjuj2eY44tAeYzmBO6L5h2wQiqyPz4y sHvMxiS5OOc7+g6n3YoxoB1nsOLX1eXTGNiVdOdWMgFw1+ana2cxGxDqm+rZrbpzK+AB EBfKciRM6jqdTiVvIbw1B+tgMi/NSScG81Jn/vLI5lmiNIlO3eYGcICKCc8rbLpI8OJS +SJDEYdVp0Al6aZewJljSxX2ZpvOkZxCzMujnFO6zK1NWkWCSC2ZCZNw4gh5wogMlbMp wq5b2SVMKhuQUz1htyTaXZp13whY+lYj2qML2VC8HWExoHpyub557ScOD141TZ6e+7AR 9K7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s8FazZgYGXhrY4wv6EKFyKgXYZHa32vXegEt6uijSRk=; b=QOVs4wR38LNEIkDoraBrgFXCTraMcrzvpGsS0N/9nnrrDJDkkczYsfaG/hZcybjmoV EocYTg4X8eD4KDqZWZQ3Vuiu0FiIcnPuvxzT/D4PnsdrBW04QEpQ72SP0kxVpetOP93m uIxQrL3VntdVhpJP0ipqtRHAikN12y6jwgO0SKwp0oSTROP1x1EKyFSkIIcHBFaOUZ9l BxvTkTGA9A2yUCgTnuKZYTGs6u15k4mQvxlPOSS+y3zrNNZ5VWyRBsYq32LeYUbEL9fY F5g2loGbT3YNdwAQMi6NF6rDGxuyRkx9PrglbJ9wOTjZNnvbKGd9KA2kVWW6Xu6K7mH7 8vLA== X-Gm-Message-State: AOAM531KqAbr5t4qKGOMlhSLtfdnJUldGEoBbO4vrbp4HAEKU0ikltHR BjPZ1HEutWaEQAuEzIrgA9X2HPMUthwoHXA519pGS9LLoGQ= X-Google-Smtp-Source: ABdhPJz4qPYB4zc897Z9nI4+vkXZzmTbSv46WDFsHbHl1pWO33DyGrfIVT/8X8OBWHgtVPCc9Oobzo4MYwfsw37NZmY= X-Received: by 2002:aca:307:: with SMTP id 7mr883424oid.174.1613606333971; Wed, 17 Feb 2021 15:58:53 -0800 (PST) MIME-Version: 1.0 References: <26484818-2f05-37d3-adff-6e34d383e117@gmail.com> <399f2cdc-d790-c4fe-18e3-0cb6b4c76554@spamtrap.tnetconsulting.net> <55d60220-c22d-c99f-f40c-68a741183213@gmail.com> <21803.1613556854@hop.toad.com> In-Reply-To: <21803.1613556854@hop.toad.com> From: Dan Cross Date: Wed, 17 Feb 2021 18:58:18 -0500 Message-ID: To: John Gilmore Content-Type: multipart/alternative; boundary="0000000000005801bf05bb9100c8" Subject: Re: [TUHS] cut, paste, join, etc. X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list , Grant Taylor Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000005801bf05bb9100c8 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 17, 2021 at 5:16 AM John Gilmore wrote: > Grant Taylor via TUHS wrote: > > I don't know where the line is to transition from stock text files and > > an actual DB. I naively suspect that by the time you need an index, you > > should have transitioned to a DB. > > Didn't AT&T Research at some point write a database, called Daytona, > that worked like ordinary Unix commands? E.g. it just sat there in disk > files when you weren't using it. There was no "database server". When > you wanted to do some operation on it, you ran a command, which read the > database and did what you wanted and wrote out results and stopped and > returned to the shell prompt. How novel! > > Supposedly it had high performance on large collections of data, > with millions or billions of records. Things like telephone billing > data. > > I found a couple of conference papers about it, but never saw specs for > it, not even man pages. How did Daytona fit into Unix history? Was > it ever part of a Unix release? > It seems that Andrew has addressed Daytona, but there was a small database package called `pq` that shipped with plan9 at one point that I believe started life on Unix. It was based on "flat" text files as the underlying data source, and one would describe relations internally using some mechanism (almost certainly another special file). An interesting feature was that it was "implicitly relational": you specified the data you wanted and it constructed and executed a query internally: no need to "JOIN" tables on attributes and so forth. I believe it supported indices that were created via a special command. I think it was used as the data source for the AT&T internal "POST" system. A big downside was that you could not add records to the database in real time. It was taken to Cibernet Inc (they did billing reconciliation for wireless carriers. That is, you have an AT&T phone but make a call that's picked up by T-Mobile's tower: T-Mobile lets you make the call but AT&T has to pay them for the service. I contracted for them for a short time when I got out of the Marine Corps---the first time) and enhanced and renamed "Eteron" and the record append issue was, I believe, solved. Sadly, I think that technology was lost when Cibernet was acquired. It was kind of cool. - Dan C. --0000000000005801bf05bb9100c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 17, 2021 at 5:16 AM John Gilm= ore <gnu@toad.com> wrote:
Grant Taylor via TUHS <tuhs@minnie.tuhs.org> wrote:
> I don't know where the line is to transition from stock text files= and
> an actual DB.=C2=A0 I naively suspect that by the time you need an ind= ex, you
> should have transitioned to a DB.

Didn't AT&T Research at some point write a database, called Daytona= ,
that worked like ordinary Unix commands?=C2=A0 E.g. it just sat there in di= sk
files when you weren't using it.=C2=A0 There was no "database serv= er".=C2=A0 When
you wanted to do some operation on it, you ran a command, which read the database and did what you wanted and wrote out results and stopped and
returned to the shell prompt.=C2=A0 How novel!

Supposedly it had high performance on large collections of data,
with millions or billions of records.=C2=A0 Things like telephone billing data.

I found a couple of conference papers about it, but never saw specs for
it, not even man pages.=C2=A0 How did Daytona fit into Unix history?=C2=A0 = Was
it ever part of a Unix release?

It seem= s that Andrew has addressed Daytona, but there was a small database package= called `pq` that shipped with plan9 at one point that I believe started li= fe on Unix. It was based on "flat" text files as the underlying d= ata source, and one would describe relations internally using some mechanis= m (almost certainly another special file). An interesting feature was that = it was "implicitly relational": you specified the data you wanted= and it constructed and executed a query internally: no need to "JOIN&= quot; tables on attributes and so forth. I believe it supported=C2=A0indice= s that were created via a special command. I think it was used as the data = source for the AT&T internal "POST" system. A big downside wa= s that you could not add records to the database in real time.
It was taken to Cibernet Inc (they did billing reconciliation = for wireless carriers. That is, you have an AT&T phone but make a call = that's picked up by T-Mobile's tower: T-Mobile lets you make the ca= ll but AT&T has to pay them for the service. I contracted for them for = a short time when I got out of the Marine Corps---the first time) and enhan= ced and renamed "Eteron" and the record append issue was, I belie= ve, solved. Sadly, I think that technology was lost when Cibernet was acqui= red. It was kind of cool.

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 - Dan C.

--0000000000005801bf05bb9100c8--