Question

I'm taking a database course and I have to write a command line application. The prof wants us to write an ESQL (embed SQL) application.

I have a feeling that this kind of technology is depreciated.

We have to use oracle precompiler to translate a esql code in c++. This kind of applications look terrible to maintain.

A php application would also work well, but they probably want a command line application to do the grading faster (unit test with input feed). What you guys think, is Embed SQL used in the industry, does it worth to ask the prof to do a java application ? Is there another technology more appropriate ?

Was it helpful?

Solution

Embedded SQL was one of the the most popular way to do SQL in C during the "old days" (C++ was not yet invented).

These days mostly we'll be using an ORM library. It is not recommended to do embedded SQL any more because, as you put it well, it depends on a proprietary pre-processor and makes code difficult to debug, manage, and maintain. It also hooks you to one single database vendor and your code will be extremely difficult to move to another database backend. Generally, we don't do it in "real life".

But as it is only a class, your prof is probably interested in teaching you SQL and database concepts. Embedded SQL is only a tool. You're supposed to learn SQL and databases, not embedded SQL in C++.

However, I believe that you're missing the point by asking about PHP and Java. Not to mention that PHP is a scripting language, and Java is another language that you can (potentially) write a processor for embedded SQL.

So your point about embedded SQL really has nothing with language choices. It has to do with the tradeoffs and balance between (1) proprietary embedded system with preprocessor, (2) using an ORM library, or a data-access library (e.g. ODBC).

Off-Topic:

I first started using embedded SQL when I was in College (that was about 30 years ago!). Actually got programming jobs out of College and still used it, but obviously it was on the way out. Never seen it used ever since 1990 or so.

OTHER TIPS

Yes, but no. I have not met a single line of Embedded SQL in my 10 years in the field. I would say (and hope) this technology only exists in (some) legacy systems.

Nowadays, database related development in the industry would involve:

  • Direct database access using JDBC, ADO .NET, OLE DB, ODBC or native libraries (OCCI in your case).
  • Some sort of ORM (Hibernate, Entity Framework or a home made solution).
  • Some sort of data access layer based on frameworks and/or patterns (think Ruby on Rails, Active Record or a home made solution).

IMHO, home made solutions should be eradicated but they are more common than you would think. Part of this would certainly have to do with students having only experimented with outdated and inadapted tools at school...

ORM (and data access layers) related problems can be very complex and I would say very interesting to have a look at. Especially if you are a student. I would recommend delving into Martin Fowler's P of EAA.

In C++, I would have a look at SOCI.

We have to maintain on an old system here (20 years and older).

ESQL is used massively in here. The most of the problems we had while moving the software to a new OS (it was an 15 year old hpux) where with the ESQL code.

The new software we are writing are all making use of the C++ library. This gives us more readable code + our IDE doesn't say 'invalid syntax' all the time. etc.. The C++ library is in general terms very equal as how I connect to a database in .NET or Java.

Using the C++ library whe have an improvement of speed (if used wisely) and much less errors.

ESQL is deprecated by my point of view. But since we have entered an time where a lot of the written software is to update/upgrade or maintain existing systems, it is very handy to have basic knowledge of old techniques!

I haven't seen embedded SQL in an application for 10 years. The last time I saw it was in a legacy mainframe app written in COBOL. Yes, still being used at electrical utility company.

The little C++ programming I do these days doesn't involve SQL. These days most relational DB programming I encounter is one of these:

  1. ORM (object relational mapping - hibernate or JPA)
  2. JDBC
  3. stored procedures (oracle or mySQL)

While this is probably outdated ( I also did ESQL ~15-20 years ago), it still may serve as a good example on how to also approach things - even if it is only for you to more enjoy ORM afterwards.

Also from my understanding LINQ in .NET is somewhat similar from the idea of embedding SQL in the host language - and LINQ seems to be quite popular.

Extracting from this to broader CS, embedded DSLs seem to be a current topic of research, so the example of ESQL as an early version my not be too far fetched from todays world.

ESQL is the prime language being heavily propagated for IBM Middleware products . Its not an Object Oriented Language but a Procedural language . Its extensively used in some places to do mapping between XMLs (alias for XSLTs) .

I am using ESql as of date on a Informix 9.x database in the legacy C++ application code that I work on as a part of my job.

While I agree to everyone that it is an old technique, and there are better options out there, I would still say it is a very neat technique. The good part is the SQL is embedded as a part of the C/C++ code flow, syntax wise and logic wise. The little syntax change that ESql carries is easy to learn, and hence I say its fun to use it.

Like Heiko mentioned, LINQ is close in the idea to ESql.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top