Re: Ada package registry?

["Björn Lundin" <b.f.lundin@gmail.com>]

On 2016-02-06 01:30, Randy Brukardt wrote:
> "Björn Lundin" <b.f.lundin@gmail.com> wrote in message 
> news:n90hnb$3bd$1@dont-email.me...
>> On 2016-02-04 22:21, Randy Brukardt wrote:
>>> "Björn Lundin" <b.f.lundin@gmail.com> 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.
> 
> Huh? You said that it is hard to pull data to Excel, and I disagreed. You 
> didn't say anything about pulling *all* of the data -- and why would you do 
> that? Excel would fall over if you gave it a million lines of anything - the 
> maximum number of rows is (or at least was) less than that.
> 
> Obviously, you'd do the selection before exporting to Excel (the case I was 
> talking about).


And that is the hard part. Of course you don't pull that kind of data
into excel. But the selection itself  - into useful data from several
sources - is hard using csv-files and ada.
and no one in the business would be able to conclude anything
useful from their own data.

> 
>  > 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)
> 
> Way too much data -- 

for csv-files : yes. for an RDBMS : no
for business analysis : no.
For tracking what store got delivery from what pallet : definitely no.
And that is really important, if you find trouble in a batch of say
food, and want to withdraw it from the stores. Which stores are affected?
- Wait , I need to call an Ada-programmer to write a tool to extract
that data from our many and BIG csv-files...

No - won't work.

> clearly a business that is far too large to be 
> managable. I don't care too much about the problems of entities that we'd be 
> better off without in the first place.

Not at all. Just because it is a type of problem outside your
normal domain, does not make it impossible. And
it does definitely not make you an expert in saying what
is too much data or not.

Especially, since we do have laws here that decides how much
traceability you HAVE to save, and for how long.
As a food supplier, you MUST be able to track your deliveries.

> 
> ...
>>> 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.
> 
> Surely. But the number of such people that can understand SQL well enough to 
> do anything beyond the trivial has to be countable on fingers and toes. 

Not true. But if it was, it is still far more that people who can
make something useful from csv-files of a substantial set of data.

>They 
> typically use report tools to get such data, and those tools surely wouldn't 
> have to be based on SQL (or anything in particular).

No, but most I've seen are.

>> I'd like to hear of an ERP system (or WMS) that does NOT
>> use a DBMS, and has customers with 1_000+ employees. 
> I don't care about systems for organizations that necessarily are in hell.
Who said they are in hell ? Sure, some are, but far from all.
And I'm pretty sure they would be in hell even without an ERP.
That is not was is tipping big organizations over.

> I 
> *hope* they waste their time with fancy ERP systems rather than getting 
> anything done so they can go out of business faster... :-)

A statement that I do not know what to think of.
I see the smiley, but I don't see the fun in it.
I do see it as fairly immature though.

--
Björn