Warp <war### [at] tagpovrayorg> wrote:
> nemesis <nam### [at] gmailcom> wrote:
> > 70-80%?  I thought COBOL was pretty much dead after SQL.
>
>   Is SQL even Turing-complete?

No.  But my point is that COBOL was the language to write your business in when
there was:
1) no standard databases
2) no easier language

Even Perl+SQL database via DBI offer a far more robust and easier solution than
COBOL.  It's a language surviving on name.  Common Business... :P

That said, I think it's truly hard to believe COBOL is more used than SQL in
business today.  Every system these days accesses a SQL database in one way or
another, be it written in Java, C#, C++, Perl or, I believe, COBOL.

So, I believe that 70-80% figure sounds highly overrated unless it's counting
SQL out.

Post a reply to this message

nemesis wrote:
> Warp <war### [at] tagpovrayorg> wrote:
>> nemesis <nam### [at] gmailcom> wrote:
>>> 70-80%?  I thought COBOL was pretty much dead after SQL.
>>   Is SQL even Turing-complete?
> 
> No.  But my point is that COBOL was the language to write your business in when
> there was:
> 1) no standard databases

You got it backwards, actually. The CODASYL database standard is what led to 
needing a business language to access databases, a la COBOL. SQL replaced 
CODASYL only some 10-15 years later (depending on how you define "replaced").

> 2) no easier language

No business-oriented language that was easier, yes. There was basically 
assembler, fortran, cobol, LISP, maybe APL and/or BASIC. COBOL's definitely 
the best of the bunch for business/database apps.

> Even Perl+SQL database via DBI offer a far more robust and easier solution than
> COBOL.

Disagreed. Perl has no decimal money type, for example. Plus, it's up to the 
programmer to ensure that files are laid out correctly between different 
applications, for example. The lack of a file section in the data division 
of Perl means you can screw things up in common files.  It might be "easier" 
in some ways, but I don't think "more robust" is quite right, assuming you 
mean "robust" the same way I do (namely, unlikely to screw up your data).

Plus, why in the world would you run an interpreted Perl program to do 
things like (say) payroll, that you're going to compile once and run 100,000 
times over the lifetime of the application?

> That said, I think it's truly hard to believe COBOL is more used than SQL in
> business today.  Every system these days accesses a SQL database in one way or
> another, be it written in Java, C#, C++, Perl or, I believe, COBOL.

Likely.

> So, I believe that 70-80% figure sounds highly overrated unless it's counting
> SQL out.

I don't think SQL counts as a programming language you write programs in, at 
least in the eyes of the author.

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> Every system these days accesses a SQL database in one way or another

  Btw, is it correct to say "SQL database"?

  AFAIK SQL is a computer language standard, not really a database standard.
SQL is simply the interface (or one of the possible interfaces) which is
used to access the database. Perhaps a good comparison would be like a
Unix kernel and the file system (which would correspond to the database) and
SH scripting (which would correspond to SQL). Just because you can access the
file system using SH doesn't make it an "SH operating system".

  Ok, maybe it wouldn't be too far-fetched to say that "SQL database" is
just short for "a database system which is mainly/exclusively interfaced
with using SQL".

  Btw, do database systems (such as Oracle) support any other interfaces
than SQL? Are there any database systems which would use something else than
SQL as the user interface? (Can MS Access be considered a database system?)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Ok, maybe it wouldn't be too far-fetched to say that "SQL database" is
> just short for "a database system which is mainly/exclusively interfaced
> with using SQL".

Or perhaps "A database compatible with access via SQL"? SQL can't really 
search anything that doesn't fairly closely follow the relational model, is 
what I'm trying to say.

>   Btw, do database systems (such as Oracle) support any other interfaces
> than SQL? 

Sure. There's QBE - Query By Example. There's all kinds of form inputs 
(which eventually probably turn into SQL). There's what's called Relational 
Algebra, where you write out selects, projects, and joins as such, altho I 
don't know any databases that specifically expose that interface.

And of course there's a bunch of interfaces for things like making backups 
or replicating data that access the database in a bulk-like way without 
doing what you might call "queries".

> Are there any database systems which would use something else than
> SQL as the user interface? 

Yes. CouchDB, Google's App Engine cloud database, Google's BigTable, 
Amazon's SimpleDB, a bunch of stuff inside Amazon (like Dynamo), etc. All 
pretty much targetted at spaces where speed or scale (or both) is more 
important than consistency. (I.e., none of them are what you'd call ACID.)

> (Can MS Access be considered a database system?)

I would certainly say so. Not a very sophisticated one, mind. And there were 
tons of such database systems (foxbase, dbase, etc) back before desktop 
machines got powerful enough to effectively support fully relational databases.


http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html
http://labs.google.com/papers/bigtable.html
http://en.wikipedia.org/wiki/Query_by_Example
http://couchdb.apache.org/
http://code.google.com/appengine/docs/java/datastore/overview.html

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > Warp <war### [at] tagpovrayorg> wrote:
> >> nemesis <nam### [at] gmailcom> wrote:
> >>> 70-80%?  I thought COBOL was pretty much dead after SQL.
> >>   Is SQL even Turing-complete?
> >
> > No.  But my point is that COBOL was the language to write your business in when
> > there was:
> > 1) no standard databases
>
> You got it backwards, actually. The CODASYL database standard is what led to
> needing a business language to access databases, a la COBOL. SQL replaced
> CODASYL only some 10-15 years later (depending on how you define "replaced").

I vaguely remember about mentions to CODASYL.

> > 2) no easier language
>
> No business-oriented language that was easier, yes. There was basically
> assembler, fortran, cobol, LISP, maybe APL and/or BASIC. COBOL's definitely
> the best of the bunch for business/database apps.

I'd say Assembler and Fortran would be ruled out for business purposes right
away.  LISP was too imature at the time (60s) and was a hog meant for research
on AI and language design.  APL I don't really know, but BASIC is just that,
basic.  So, yeah, right language for the job, *back then*.

> > Even Perl+SQL database via DBI offer a far more robust and easier solution than
> > COBOL.
>
> Disagreed. Perl has no decimal money type, for example.

It was just an extreme example, perhaps not quite accurate, but the point is
that even a scripting language coupled to a RDBMS could do the job today, let
alone performant scripting languages leveraging from fast, robust VMs, like
Scala on JVM.

anyway, is it much of a hassle to use double to represent monetary values?

> Plus, why in the world would you run an interpreted Perl program to do
> things like (say) payroll, that you're going to compile once and run 100,000
> times over the lifetime of the application?

Perl is a glue language:  it's main purpose like should be all scripting is to
integrate different systems and route data between them.  Perl "slowness"
doesn't really get into account when it is expecting data from the RDBMS to
feed the PDF generator.

At workplace, at least, SQL responds pretty much for about 80% of the code, the
rest being forms and reports in Delphi to either enter or extract data to/from
the RDBMS.  Business rules validation on persistence is done by SQL stored
procedures.

> > So, I believe that 70-80% figure sounds highly overrated unless it's counting
> > SQL out.
>
> I don't think SQL counts as a programming language you write programs in, at
> least in the eyes of the author.

SQL alone, no.  But stored procedures get you many new abilities.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> nemesis <nam### [at] gmailcom> wrote:
> > Every system these days accesses a SQL database in one way or another
>
>   Btw, is it correct to say "SQL database"?

It may not be accurate, but the meaning is obvious, I guess: RDBMS employing SQL
as main interface.

>   Btw, do database systems (such as Oracle) support any other interfaces
> than SQL?

I heard Oracle supports Java.  PostgreSQL can have stored procedures written in
TCL, Python and Perl, all being used to *complement* SQL.  I don't think there's
that much more convenient a language to fetch relational data than SQL, even C#
with Linq resembles SQL very much.

If only it had some macro processing, it should be much more handy.  While views
can perform the same job, it's at cost of runtime performance.

I'm no fan of SQL.  I wish I was playing with pointers all day.

Post a reply to this message

nemesis wrote:
> anyway, is it much of a hassle to use double to represent monetary values?

Yes. It's not correct.  Add up a billion dollars in penny increments, and 
tell me you can guarantee it's right.

> At workplace, at least, SQL responds pretty much for about 80% of the code, the
> rest being forms and reports in Delphi to either enter or extract data to/from
> the RDBMS.  Business rules validation on persistence is done by SQL stored
> procedures.

Yeah, OK, if most of your actual code is in SQL, I'll grant you that. :-) 
You still need something that supports the SQL data types, then.

> SQL alone, no.  But stored procedures get you many new abilities.

Granted.

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

nemesis wrote:
> I heard Oracle supports Java.  PostgreSQL can have stored procedures written in
> TCL, Python and Perl, all being used to *complement* SQL.  I don't think there's
> that much more convenient a language to fetch relational data than SQL, even C#
> with Linq resembles SQL very much.

They all eventually translate to SQL, tho, I think. Maybe some of the .NET 
stuff is similar, but I don't know how the internals interface. Maybe 
straight thru a COM-like interface without going thru SQL.

> I'm no fan of SQL.  I wish I was playing with pointers all day.

So learn CODASYL. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Warp wrote:
>   Btw, do database systems (such as Oracle) support any other interfaces
> than SQL? 

This is cool, btw:

http://www.businessintelligencelowdown.com/2007/02/top_10_largest_.html

I know the AT&T database runs SQL. When I was there 15 years ago, they had 
100 million lines of SQL.

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> http://www.businessintelligencelowdown.com/2007/02/top_10_largest_.html

  I can only imagine how expensive it is to backup all that information
(and I have hard time believing they don't backup it). Not only is the
backup medium expensive (because of the sheer amount required), but
physically *storing* it somewhere must also be expensive (after all,
physical storage space is never free). I also imagine that they want to
store the backups in a secure location (from accidents, eg. fires, and
robberies/vandalism), which can only make the storage costs several times
larger.

-- 
                                                          - Warp

Post a reply to this message