🚀 go-pugleaf

Greg

Here is is an extract from the book that Borland included with VDB7. If you
do not have this book it is worth the price just as a reference. I know
this to be the history of SQL as I was in the business at this time and
remember reading articles on the subject.

Teach Yourself SQL in 21 Days, Second Edition
 



- Day 1 - 
Introduction to SQL
A Brief History of SQL
The history of SQL begins in an IBM laboratory in San Jose, California,
where 
SQL was developed in the late 1970s. The initials stand for Structured
Query 
Language, and the language itself is often referred to as "sequel." It was 
originally developed for IBM's DB2 product (a relational database
management 
system, or RDBMS, that can still be bought today for various platforms and 
environments). In fact, SQL makes an RDBMS possible. SQL is a nonprocedural

language, in contrast to the procedural or third-generation languages
(3GLs) 
such as COBOL and C that had been created up to that time. 

    
    NOTE: Nonprocedural means what rather than how. For example, SQL
describes 
    what data to retrieve, delete, or insert, rather than how to perform
the 
    operation.
   Greg 
     
    The characteristic that differentiates a DBMS from an RDBMS is that the
RDBMS 
provides a set-oriented database language. For most RDBMSs, this
set-oriented 
database language is SQL. Set oriented means that SQL processes sets of
data in 
groups.
Two standards organizations, the American National Standards Institute
(ANSI) 
and the International Standards Organization (ISO), currently promote SQL 
standards to industry. The ANSI-92 standard is the standard for the SQL
used 
throughout this book. Although these standard-making bodies prepare
standards 
for database system designers to follow, all database products differ from
the 
ANSI standard to some degree. In addition, most systems provide some
proprietary 
extensions to SQL that extend the language into a true procedural language.
We 
have used various RDBMSs to prepare the examples in this book to give you
an 
idea of what to expect from the common database systems.

-- 
Joe  < jyuzamas@wrdiss1.robins.af.mil or jyuzamas@sprynet.com >

Greg Hill <ghill@n2.net> wrote in article <34B57D9C.1A95@n2.net>...
> Joe Yuzamas wrote:
> > 
> > Greg
> > 
> > Some where along the line, people have lost track of what SQL is. 'SQL'
is
> > being used for anything connected with a database. SQL stands for
"STANDARD
> > QUERY LANGUAGE". It has nothing to do with servers, databases or
> > development languages such as VDB. It is simply an interface to get
data
> > from a data source to an application. It does not require a file
server, a
> > network or even a DBMS (MS SQL SERVER, ORACLE). Many development
languages
> > now allow imbedded SQL commands. SQL commands can be used to access
local
> > DBF files or DBF files located on a file server via the net, but in
either
> > case NO DBMS SYSTEM IS REQUIRED as long as the server supports DBF
formated
> > files. No mid ware, no other support software is required. If the
server
> > does not support DBF files now a DBMS is required. If there are
requirments
> > that require DBMS funtions such as pre-triggers, ect, you will need a
DBMS.
> > I hope this may stop the misuse of the letters SQL.
> > 
> > --
> > Joe  < jyuzamas@wrdiss1.robins.af.mil or jyuzamas@sprynet.com >
> > 
> > Greg Hill <ghill@n2.net> wrote in article
> > <01bcd473$2448a740$828471cf@greg>...
> > > I'm getting ready to set up a wan connection between two offices, I'm
not
> > > sure how much band width I'm going to buy yet but I'm guessing around
> > > 64mbs.  I just did some testing using Visual dBASE 5.5 across a dial
up
> > > connection using Windows 95 on both sides and connecting using 28.8
> > modems
> > > on both sides.  I ran the DBASEWIN.EXE and the program files locally
but
> > > opened the tables on the host computer and it took about 5 minutes
just
> > to
> > > open up 10 tables and set up the relationships no filters. Once the
> > tables
> > > were opened I brought the form up and it took about 5 minutes, once
the
> > > form was up navigation from one record to the next took about the
count
> > of
> > > 8 to 10 seconds (no filters were active).  I executed an onclick
event
> > that
> > > does a couple seeks and replaces, and that took about 5 minutes.
> > >
> > > I keep hearing this SQL stuff.  Things like it brings down the amount
of
> > > traffic across the wire, it is network aware you make a request and
the
> > > work is done at the Server using the servers memory/cpu and when it
is
> > done
> > > it sends back only the requested  information.  I'm not sure how true
all
> > > of this is and also how it applies to my particular applications. 
I'm
> > > running an application that shows appointments for the day and there
are
> > 4
> > > users changing the status of each record that is scrolled to plus
there
> > > will be about 5 other users that will be looking at data pulling up
> > records
> > > for odd reasons, reports will be pulled all day long.  This database
will
> > > contain about 25000 records total.  There is about 125 appointments
per
> > day
> > > and all 125 records require some kind of updating by at least 4
> > > Users/Dispatchers throughout the day.
> > > Should I be considering SQL and if I do how could it help if my app
> > demands
> > > constant refreshes.
> > > If I face the reality of my situation, I think I'm up for a rewrite
on
> > this
> > > app I think I would have to write something that would download the
data
> > to
> > > the local PC and keep synchronizing it at certain breaking points
during
> > > the day.  Which means the end-users and the Boss who wants dynamic
> > reports
> > > will be a little disappointed.
> > >     I think one of the reasons they wanted to put this WAN up is so
that
> > > they did not have to pull separate reports and dial up other
locations to
> > > get reports, they wanted  reports that reflected all offices.  Later
they
> > > will be adding another location so the demand is there for a WAN.
> > >
> > > I know this is rather long but it is the only way I could summarize
all
> > of
> > > it.
> > > Any suggestions appreciated.
> > > Thanks, Greg
> > >
> > >
> > >
> 
> How is this message still haunting me?  It must be 2 or 3 months old.  I 
> learned from you and others in this news group what Client/Server is and 
> what SQL is and the basics of they work together or apart.
> 
> I've also learned that there is not a true definition to SQL and that it 
> is not an acronym or an abbreviation<g>.  See my reply to Keith C.
> Thanks, Greg
>