From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: =?UTF-8?B?QmrDtnJuIEx1bmRpbg==?= Newsgroups: comp.lang.ada Subject: Re: Ada package registry? Date: Thu, 04 Feb 2016 23:04:05 +0100 Organization: A noiseless patient Spider Message-ID: References: <02241ec4-0f95-4f63-9abc-092f167eb59e@googlegroups.com> <56af17b7$0$301$14726298@news.sunsite.dk> <56b06eb8$0$301$14726298@news.sunsite.dk> <1454483747.2785.135.camel@obry.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Thu, 4 Feb 2016 22:01:16 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="6a09ccc49493ecf301ef65af9aa456c7"; logging-data="3437"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18fFvSzi/Yx5MSa9Py9Dnf2" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 In-Reply-To: Cancel-Lock: sha1:eVur8tbSMr0cSM0uOK1/iGSWSHw= Xref: news.eternal-september.org comp.lang.ada:29348 Date: 2016-02-04T23:04:05+01:00 List-Id: On 2016-02-04 22:21, Randy Brukardt wrote: > "Björn Lundin" wrote in message > news:n901l6$b7$1@dont-email.me... >> On 2016-02-04 17:59, Dmitry A. Kazakov wrote: >>> On 2016-02-04 17:52, Björn Lundin wrote: >>>> On 2016-02-03 23:11, Randy Brukardt wrote: > ... >> Especially bad is when a customer cannot pull data to Excel. > > Why would that be hard? I do it all the time in my programs, no database (or > even persistent storage) in sight. It's easy to read/write .csv files in > Ada, and I believe that someone even has a library for writing .xls files. Yeah, having millions of records in .csv and joining with a couple of other .csv files with the same amount of data and sounds like a really good idea... If you got plenty of time, that is. Looking at a customers trace table I see they generate about 100_000 records a day. Order lines are around the same. Data saved for a month or two, before moving to long-term storage (db not connected to production) It very soon becomes messy to make a program to parse/group/join aggregate any sensible information from that using pure Ada constructs. But sql likes it. It gets even worse when you tell the customer - 'Write your own Ada-tool for data mining' > (I'd like a nice spreadsheet program in Ada, too; one would hope it would > stay up more than LibreOffice Calc does. But I can be a realist when > necessary...) > >> As you say - driven by non-Ada tools, but I do not agree upon >> replacing them -from a business point of view. > > The real reason to stick with non-Ada tools is when large parts of the > system already are in a non-Ada language, and you're just adding to it. Nope, the real reason is that SQL is a good enough way for non-engineers (read economists/warehouse manager etc) to make reports. They do not write their own Ada programs. They do not care. They want to use Excel and get data in ways THEY understand. I'd like to hear of an ERP system (or WMS) that does NOT use a DBMS, and has customers with 1_000+ employees. >> DBMS is also motivated by its history. It is a proven concept. > > Yeah, proven to make Larry Ellison very rich! That too. However there are good free RDBMSs too, but that is another story. >The rise of No_SQL has shown > that it's overkill (and even harmful) in many cases. No, it shows that not _every_ area can make good use of a relational data base. That not every problem breaks down to fit Codd's rules But where it fits, it's really good. Like Order/Orderline/delivery per day/ etc > But off topic to discuss here... Indeed. -- -- Björn