I need a Well documented Report and a Power Point Presentations on the
Limitations of SQL

---

Request for Question Clarification by answerguru-ga on 12 Mar 2004 06:53 PST

Hi kanz2000,

Since SQL is a standard language, are you after the limitations of its
use within a certain context or when used within a specific
application?

Thanks,
answerguru-ga

---

Clarification of Question by kazns2000-ga on 12 Mar 2004 17:19 PST

i am lookin gfor:
Alternatives to SQL
Limitations of SQL 
Applications domians where SQL Fails and justify the faliure and
alternatives in applications domian

hehe ansi sql implementations versus futuristic hybrid databases that
support both ansi sql and object oriented paradigms such as the
ill-fated object oriented database effort by informix or the coming
soon sql server yukon database. frankly i cant wait for sql server
yukon.

sql is limited simply because no language can solve everything in an
efficient manner. example is you could parse through a file/database
and look for records with a certain key using a program you built in
c/c++ but you would have to write the parsing and the actual look-up
code for it probably take a few hundred or thousand lines while with
sql, you can expressively type what you want and will be equivalent to
the manually written thousand line c/c++ program.

anyway with current paradigms and databases, the need for flexibility
as well the ability to choose the best tool for the job mandates the
need for extensions to databases to support more functionality while
still providing optimum performance and reliability as well as better
maintainability of code.

I'm basically with our friend here.. I've never ran across a true
"limit" to SQL. The MySQL system has a great deal of add-on's now,
that take care of just about anything I might be able to come up with.
The Yukon method brought up, is really just an adoption of the AS/400
method of OS'ing to a database format, and being an AS/400 certified
type person, I don't see much in the way of limitations from SQL in
getting data. The OS is nicer, if you are a database type guy, but
this isn't addressing what SQL really does, and to be quite frank, the
OS/400 system uses SQL for reports and such.. so..

I've taught computer illiterate managers in minutes (and I do mean
minutes) how to create custom reports off their data base using SQL.
After a week, they are so comfortable, they don't use the reports I
create for them; they just run a fast query and look up numbers. So
unless the system presented is able to be taught in seconds, and is as
limitless as SQL, ... <shrug> not sure what to say there.

I'm really very interested to see if anyone could present a true
limitation for SQL, that deals with data. I'm sure I couldn?t write a
ti-fighter simulation game in SQL, but then, I wouldn't think of using
my toaster to drive to work either.

I don?t mean to sound flippant here at all. But I am surprised by the
question and perhaps if you could give us some ?area? of where you are
looking for limitations, then we could focus better on what you are
looking for. As it stands now, SQL is the preferred method of getting
fast answers from databases on just about every level I can think of.

For a new method, or language, to be appealing it faces a great deal
of hurdles, and simply having fewer limitations is far from a
resounding factor. First of all there is platform and support issues.
Just about anyone, who has coded any serious program, knows enough SQL
to support existing software using database access. The educational
changes alone stand against such a move. And then, there are the
supporting software packages, such as Excel for instance, or Word, or
? name something.. they use SQL to access and report on data from
available Database sources. Then there are all the languages, C, Perl,
PHP, ? name something? which already have libraries supporting SQL
access. Years (decades) of code have gone into these libraries, and
any perceived limitation from those scopes, have been worked out,
re-hashed and re-hashed until they simply don?t? exist any longer.

To put it on a software shop point of view, even if someone could
present to me a language, which far exceeded SQL as a method of
getting the data from a database, I probably wouldn?t use it, because
the cost ratio to my customers would simply not allow the change. And
to be honest, I may not even recognize the limitations this new
language was fulfilling.

There are four things you do with data. Add, Edit, Delete and Report.
That?s it, there?s nothing else to do with data. What you do with
those four can be as various as fingerprints. But that?s all you are
doing when you go to the database. Someone might be able to argue that
you can also Relate Data, but really, that?s just Report with a bit of
swing in its step. A rather sexy swing, yes, but still the same step.

Most perceived limitations I have found when approaching a set of data
with SQL, have not been in the language, they have been in the design
of the database. A poorly created database is very hard to get data
out of efficiently. But again, this doesn?t address the language, it
addresses the tables, you get the same problem with talking to
children about war or calculus. It is not a matter of the language
being deficient; it is the ears that are listening, and it is not
really a limitation, it is an efficiency problem in getting the
information across. Several more queries than normal, are necessary to
get your point across. But, with SQL, those steps are available, and
can be overcome.

webadept-ga

There are lots of limitations to SQL.. depends on what area you want
to concentrate on. For example, available datatypes in ansi sql will
limit you as to how much float decimals you can use. also, there are
limitations on how indexes work, if you're talking about the various
db engines out there. this would be something significant to problems
with sql databases. For example, no database can go beyond 32 nested
triggers (if it supports triggers). also, from ansi sql, you cannot
specify table scanning options if you are not using indexes. please
provide more clarity on which area of this argument you would like
info on and i can clarify on some of these.

Easy:

Alternatives to SQL: There are no alternatives to ANSI SQL 92, since
its the standard way of querying a database.

*Enhancements to SQL: Procedural languages defined in your RDBMS. For
example, PL/SQL in Oracle, PG-SQL en PostgreSQL, MySQL MaxDB stored
procedures, etc.

What can you do with storaged procedures? Typically, triggers (perform
an action when something occurs), cursors (trace the results of some
query), and operations within data, it depends on the language used.

Limitations of SQL: Too complex to explain in just a comment. Think
about altering data in some ways, create data structures whith that
data, or display data in some ways youd like.

Applications domians where SQL Fails and justify the faliure and
alternatives in applications domian: SQL does not fail in its
application domain. Maybe its not enough for what you want to do, (for
example, views, or reports), and a higher level framework is needed.

*Which higher level frameworks can i use?: It depends on what youd
like to do. Tipical examples are Crystal Reports, Oracle developer
tools, or just a program written in C using the MySQL API.


Remember: SQL just querys a database in a standard, relational way.
Database functions may alter that data in a limited way. Storaged
procedures may handle data, or perform complex actions, as well as
deal with quite simple data structures. Finally, the API of the RDBMS
allows any other language to handle data in an way youd like.

Regards,

Fernando Alvarez-Uria
Madrid, Spain

I just finished reading an excellent book that covers the subject of
SQL limitations in depth.  It is called "Practical Issues in Database
Management", by Fabian Pascal.  Pascal takes the position that the SQL
standard is a flawed implementation of the principles of relational
database design originally articulated by the computer scientist E.F.
Codd.  It is Pascal's view that the design of SQL has a number of
significant problems, and that existing SQL databases compounds those
problems with their own set of flaws.  The book goes into detail about
specific problems, how they could be avoided if one were not tied to
the limitations of SQL, and in many cases how to best deal with the
problems when using existing systems.  Pascal does not however name
individual systems when describing their flaws, so if you have a
particular database system that you wish to critique, this may not be
the book you are looking for.

The main areas he addresses are: data types, integrity constraints,
keys, duplicate rows, trees and null values. Pascal co-authors with
Chris Date a website (http://dbdebunk.com) that covers some of these
same subjects in a less detailed way.  The writing style there, as in
the book, is caustic, at times even perhaps bitter.

There is little denying that whatever the merits of their arguments,
the commercial database world has largely passed over these questions
of correct theoretical foundation, in favour of SQL based
implementations with a variety of vendor specific extensions.

Regards,
Oliver
http://skymind.com/~ocrow