RS>>> SQL is a bit different and in a sense is just a standardised

 RS>>> language, usually used between systems. Nothing much to do with

 RS>>> users. Sure, you can have the user writing SQL commands manually

 RS>>> which produce a result. But the more common thing would be to have a

 RS>>> say client server approach were the communication between them is

 RS>>> with SQL and the user never actually sees any SQL at all.



 PM>>> SQL is a database query language, it has nothing to do with

 PM>>> client-server.



 RS>> In the strictest legal sense thats true.



 PM>> In *no* sense is SQL client-server.



 RS> We are getting our wires severely crossed here.



What a surprise.



 RS> In a very real sense SQL is in practice the means of communication in

 RS> that config.



If it's used more in that sort of environment then it's because it's a good
database query language, not because it has anything to do with
communications.



 PM>> Certain database systems may be able to ship the query to another

 PM>> machine, but this has nothing to do with SQL



 RS> In practice when that is generally done with SQL, SQL does indeed become

 RS> a standardised form of communication between those components.



SQL is what the application uses to issue the query. The systems that runs
locally may choose to past it on unchanged, or it may choose to do some
processing (say parsing the SQL) and pass on something different.



 PM>> and could be done equally as well using non-SQL calls.



 RS> True, but thats just like saying that you can write a program in a

 RS> standardised language or you can invent a new one.



No, what I'm saying is that if you have a system that uses SQL and one that
doesn't (like Paradox), then the language used to query the database is
irrelevant. The communications side is handed seperately have has nothing
to do with the language being used.



 PM>> It certainly isn't, as you claim "...in a sense is just a
standardised

 PM>> language, usually used between systems"



 RS> In practice thats precisely what SQL actually is used for the bulk of

 RS> the time. It is in fact the standardised communication between those

 RS> systems.



What exactly is you definition of a "system"?



 RS>> But in practice SQL IMO shouldnt be used as a language used by the

 RS>> user to communicate his wishes to the system in say a message reader.

 RS>> The system should be say offering a set of common reading modes,

 RS>> sequentially by area, all the personals, all the messages with a

 RS>> particular subject. The user just specifys the data if necessary and

 RS>> the database system may actually use a SQL query to do the work, but

 RS>> IMO its medieval for the user to be actually writing the SQL himself

 RS>> for stuff like that. Its lower level stuff which is best concealed

 RS>> from the user.



 PM>> Nobody is talking about getting an end user to pound away entering SQL.



 RS> Yeah, it took me some time to realise Paul was talking about code. Some

 RS> systems do indeed allow the user to enter SQL directly. IMO thats an

 RS> abortion of a way of doing things for repetitive ops like mail reading.

 RS> I agree its not proposed here.



Probably the only time a user would be entering SQL directly would be if he
wanted to do some sort of search that wasn't provided as standard with the
application.



 PM>> What we were talking about is the user interacting with the

 PM>> application (as he does now) and the application issuing the SQL. I

 PM>> don't consider SQL to be a language that the average end user should

 PM>> be using (it's way too dangerous for that), but I do consider it

 PM>> desirable for a programmer to know and use it.



 RS> In some ways. OTOH I have my doubts about it in a PC standalone

 RS> situation. You can indeed demand the system supports it, but it limits

 RS> your choice pretty severely. It generally only the expensive end of PC

 RS> database systems which support it. The primary advantage is its

 RS> theoretical portability, but the practical reality is that it in fact

 RS> reduces your portability severely in the PC standalone database situation

 RS> in practice.



SQL biggest advantage is not its portability, it is its power as a query language.



 RS>> Corse the other consideration is the use of SQL as a standardised low

 RS>> level layer which in theory allows portability. Thats true in theory

 RS>> but the PC world doesnt work too much like that.



 PM>> Depends on your definition of portability. Unless your implementation

 PM>> does something *really* strange, then SQL is pretty portable.



 RS> Not if the bulk of the PC database systems you want to port to dont even

 RS> support it at all it aint. Thats all I meant there.



This is this same as saying you can't port you C program to a platform if
you don't have a C compiler. This is *not* portablity, this is
availability.



 PM>> Besides, portability isn't the only reason for using SQL. The biggest

 PM>> reason is the ease of querying databases. Even simple SQL can save

 PM>> you a lot of time coding calls to the database engine.



 RS> Sure, but IMO coding calls to database engines is a fucked way to

 RS> implement things anyway, as is in general coding all the user interface

 RS> stuff. All the decent PC database systems have canned querys, they just

 RS> dont happen to use SQL to do it.



If you're writing in, say, C then you have no choice but to call the
database engine. If this is the case (which *is* what we were talking
about), then SQL if the prefferable way to go.



If you use Access then the canned queries do use SQL. You just draw the
pretty picture of how the tables relate and the query tool generates and
executes SQL.



 RS>>> There isnt even much point in SQL in the situation where
you have say

 RS>>> a database which contains all the messages and say a full database

 RS>>> system which is used for reading the messages by the user. In this

 RS>>> particular case I cant see SQL gets you anywhere in particular.



 PM>>> This is exactly when you *would* want to use SQL.



 RS>> Nope, normally that isnt done with PC class databases and its

 RS>> normally only used in a client server config where the PC database

 RS>> client does all the user interface stuff and then talks SQL invisibly

 RS>> to the user over the client/server link. The results of that query

 RS>> are then presented to the user.



 PM>> Regardless of whether the database is local or remote, on a PC, mini,

 PM>> or mainframe, SQL is the preferable way of accessing even something

 PM>> so simple as the database Paul wants to build.



 RS> Nope, not if the database system you propose to use doesnt support it it

 RS> aint. Even when you are using one which does, its still not necessarily

 RS> the right approach. Paradox is a classic example of that. In a

 RS> standalone PC situation, SQL is not necessarily the way to go at all,

 RS> even tho SQL is an option with Paradox.



If you had SQL available and non-SQL in the same product why wouldn't you
use the SQL?



 PM>> Again, we're not talking about users having to enter the SQL,

 PM>> although you may want to provide the option for the power users.



 RS> Still not necessarily desirable to do it with SQL, either by the code,

 RS> or for the power user querys. In fact its the last thing you should be

 RS> doing for power user querys if Paradox is the database for example.



If you have a pretty query manager then fine, but the database world is a
lot bigger than just PCs, and these tools, more often than not, just don't
exist.





Paul



--- GoldED/2 2.42.G1114