Structured Query Language (SQL)

Structured query language (SQL) was designed to implement both data definition and

data manipulation facilities such as storing, processing, retrieval and management of data

items in the underlying data repository (Database) on which it is running. The foregoing is

substantiated by (Coronel et al., 2013) that, SQL makes it all possible, as a database linguistic

that permits you to construct database and table organizations, implement elementary data

management routines such as addition, deletion, and modification of data items, and execute

composite enquiries intended to transmute the underdone data into advantageous information

resources. SQL abstract details of how the procedure should be carried out and rather dictates

or declares what should be done concerning the structure, definition and manipulation of the

database, thus leaving the implementation details to the relational database management

system (RDBMS). It can be thought of an infrastructure whose intent is to provide a familiar

and friendly interface between the physical database and the developer as well as the users

alike giving them the possession of powerful set of skills to harness huge data resources with

little investment of time and effort consequently. SQL was define as forms of data access and

retrieval mechanism as established by the E.F. Codd’s twelve rules proposition for the

relational data model (RDM) which bear genuine eloquence of homogeneity expected across

diverse implementations by vendors. Consequentially, (Coronel et al., 2013) averred in the

affirmative that, SQL as a database linguistic has essential ability to accomplish the

rudimentary tasks with least user energy, and its command arrangement and grammar are

stress-free to acquire, it can be transferrable; such that, it adapts to various simple standard

that requires that an individual does not have to relearn the essentials when moving from one

RDBMS to another.

The evidence of interoperability among various implementations of SQL have been

enunciated by the foregoing which states unequivocally that it must exhibit characteristic

portability as a fundamental expectation of its implementation, therefore it suffice as matter

of grave concern to discover that vendors are enhancing or extending the laid down

implementation standard specified for the same reasons highlighted earlier. In my humble

opinion it is should not be encouraged. I observed majorly that the motivation that, a vendor

want to outdo other vendors in the RDBMS competition for substantial market share of

client’s patronage of it product it the potential reason for these activities, however, any other

reason(s) are mere secondary issues which should take back sit in the interest of promoting

interests which are beneficial to the majorities.

(Burns et al., 1996) averred vehemently that, “while the SQL standard (SQL92)

provides a starting point for a multilevel SQL, each of the MLS DBMS vendors has

implemented different multilevel extensions. The result is an assortment of concepts and

mechanisms that designers of multilevel database applications must understand and apply

differently for each different DBMS.” Therefore suffice from the foregoing is the fact that

interoperability and portability which are the threshold on which the standard was founded

had been defeated inadvertently. The implications portend grave consequences for the

developers and users alike if they operate in a heterogeneous environment hosting varieties of

RDBMS. (Perkovic, 1991) advanced similarly that, ANSI/ISO SQL 89 standard promoted

language objectives such as client-server model, session management, data types, dynamic

SQL, error handling, information schema and transaction handling to ensuring portability

among different implementations to alleviate unintended difficulties or damage it portends to

user’s data and developer’s development time and effort. The table exemplified the

comparisons of where some of the key implementation items mentioned earlier was

implemented by various vendors’ DBMS:

(Burns et al., 1996)

Another contextual issue rose by (Hossain et al., 2012) suggest that, “Database

synchronization is a complex process in heterogeneous database environment. Maintaining

the uniformity of data and its structure is a fundamental problem of data synchronization.”

This is susceptible to inviting some errors which possibly will materialize in target database

for data type incompatibility or SQL query function discrepancy or unreachability. Except for

the reason mentioned earlier, vendor’s extendibility of the SQL are incomparable and not

interoperable with other vendors alike and on this basis serve no significant advantage(s) for

either the developers or the users community in my opinion and I advised that such practice

should be discouraged with serious resistance. If possible with legislation.

SQL is a declarative programming language as compared with Java programming

language which is object oriented. In Java you need to rap data and functions that operate on

them together as object. Object communicate with other object through an interface define by

the object’s function responsible for the action intended by the calling object. Objects are

instantiated member of a class which is a template that specifies or define the detail of object

instantiation. Every class emanates from the root class and classes are arranged as hierarchies

with each class in the lower hierarchy extending the characteristics and behaviors of it

superclass in the hierarchy. While Java is manipulates and manage objects and their

relationships with other objects, SQL is manipulates table or relations, tuples or rows and

columns or attributes through the basic relational constructs such as SELECT, PROJECT,

UNION, INTERSECTION, DIFFERENCE, PRODUCT, JOIN and DIVIDE.

In my opinion SQL had been a very good initiative placing in our hands a powerful

ability to manipulate and implement certain integrity constraints to maintain autonomous data

structure across the physical data storage infrastructure.

References:

Coronel, C., Morris, S., Rob, P. (2013) Database Systems: Design, Implementation, and Management, 10th Edition. Cengage Learning, 01/2012.

Burns, R.K.; Koh, Y., "A comparison of multilevel structured query language (SQL) implementations," Computer Security Applications Conference, 1996., 12th Annual , vol., no., pp.192,202, 9-13 Dec 1996

Perkovic, P., "SQL access and ANSI/ISO SQL and X/Open," Compcon Spring '91. Digest of Papers , vol., no., pp.120,122, Feb. 25 1991-March 1 1991

Hossain, M.I.; Ali, M.M., "SQL query based data synchronization in heterogeneous database environment," Computer Communication and Informatics (ICCCI), 2012 International Conference on , vol., no., pp.1,5, 10-12 Jan. 2012

Bibliographies:

Reinwald, B.; Pirahesh, H.; Krishnamoorthy, G.; Lapis, G.; Tran, B.; Vora, S., "Heterogeneous query processing through SQL table functions," Data Engineering, 1999. Proceedings., 15th International Conference on , vol., no., pp.366,373, 23-26 Mar 1999

Ju Fan; Guoliang Li; Lizhu Zhou, "Interactive SQL query suggestion: Making databases user-friendly," Data Engineering (ICDE), 2011 IEEE 27th International Conference on , vol., no., pp.351,362, 11-16 April 2011