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 ?
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.
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:
ORM (object relational mapping - hibernate or JPA)
JDBC
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.
Related
I've been working with yocto for a while. The job involves adding a layer on top of meta-yogurt, and thus adding new or modifying existing recipes in this layer. It has been working out so far.
But through struggling with recipes/rules syntax and relationships between them, my gut told me that it would be much easier for the internal implementation of the build system, as well as how the build system interacts with end-developer like me if a relational database had been involved, which defines things, their attributes and their relationships.
But I am no yocto expert (and cannot spend time on it, considering my project schedule) to evaluate a re-design of yocto with a relational DB. Just wonder if this also makes sense to anybody?
Speaking as one of the developers who's worked extensively on bitbake whilst I can see why you might think this, it doesn't really make sense for many reasons, not least performance. We once did try using sqlite as a data store backend within bitbake and it was orders of magnitude too slow to be useful compared to our python data store.
The flexibility in the metadata also comes from things like the ability to inject python code and with a database engine, this wouldn't be easily possible.
So in summary, I doubt bitbake or the Yocto Project will ever use relational databases in this way.
I tried to post a comment to Richard Purdie answer from Oct 7 '17 but the comment box didn't allow line break and long text...
I was not aware that there was already a python data store besides yocto objects and rules (mixture of variables, string literals, reg.exp., file types eg. layer, bb, bbappend, conf, inc etc and the "half-explicit", "half-documented" syntax and relationship among them :().
Of course in python environment, it makes most sense to use the combination of its data store and language binding and not another relational db. But I imagine with a relational db, every things such as data store and rules can be implemented in one place, querying/modifying is also an integrated part, binding to different languages / scripting should be possible. Was it actually the same, just the "python way" that I am not familiar with?
When it goes to performance, we already needed a powerful machine (Xeon E5 16G DRAM 1T HDD) to clean build one distro (without fetching sources from remote servers) in an hour and believe other people also use their best available PC for such a serious job as building a distro. So without comparing performance of different db engines and programming languages, which can't be different in great magnitude, I would just forget the performance factor.
Injecting code into a database engine might be difficult. But I guess when using a database engine, just a different programming pattern does the job: the logic of the job is implemented outside the db engine and this process contacts the db engine when needed.
I've been actually not working with yocto for awhile because our yocto build setup actually has been working great and producing new distros for us now and then with the previously prepared layer. Just some thoughts ...
I am currently running the local version of Caché on my system in order to determine if I can (and will) take on a new possible project.
The current project uses Delphi 7 as a front end calling a Caché dll where the business logic is stored in the database.
I have a background of Sqlserver and Firebird (and before Access and Paradox) as databases.
I use Delphi 7 for 95% of my Windows development, so I know about object programming.
I would like to recieve opinions from persons having used Caché and either SqlServer, Firebird or Oracle and having developed in Delphi (or C++ or C# - an object oriented language).
I have read the pro's and con's from other questions, but I am not asking for this, I need input from Caché developers.
Thanks in advance.
I am curious about this object database. I don't see any reference to Delphi users with this database on their web site. They do mention they have a COM interface, which might be easier than a Raw C style API (if they also have that) because at least string buffer allocation/management and your wrapper code will hopefully be simpler.
However, you will have no way of connecting to data aware controls, so I would plan on doing a lot of "roll your own" work. My intuitive opinion is that you might be the only guy on the planet using Delphi with this database. Delphi is a small fish in the development tools world though, so that might just more be a fact about Delphi more than a fact about Cache, which is a horribly NON-Googlable technology name, by the way.
You can find information about Caché by googling for Intersystems--that's really the best way. You can also search under the old name of the language, MUMPS.
I knew nothing about Caché when I started working on it fresh out of college, and I don't think it was that hard to learn. Like most scripting languages, it's best to learn by trying things out in the terminal and learning your way around.
Also, Caché has a built-in SQL mapping system so that you can have it behave like a relational database externally but still leverage some of the powerful non-relational concepts under the hood.
The company that I worked just a little time ago uses Caché and they have a bunch of projects using Caché and delphi. In fact, they uses the VISM.OCX just to connect and pass parameters to database (PLIST variable and such) but in any time they run any M command directly from application to DB, just call the routines.
Is not that hard to learn about it, but in nowdays we are leaving it! Beside Caché is incredibly fast, the lack of tools and support don't makes him a good option in nowdays...even there's a rumour that intersystems is "leaving the boat" of caché to work in a new system.
I have been working on the 2008 Caché version for a few months now. It's possible to learn\use, but extremely unpleasant. The IDE is simplistic and unhelpful with errors (it doesn't even pick up case sensitive syntax problems until it crashes at runtime). The documentation is terrible and there's nothing online, compared to to the amount of information on SQL Server or MySql. And you're learning something that probably won't be of much help in your future career. Personally, I would avoid any project that uses Caché if you have any alternative.
Friend, there are two ways to access Caché via Delphi, and is a personal project of Brazil - friends - who are developing a framework for free Caché Object Oriented.
I tell you, you're not only using Caché with Delphi, but I do not recommend. The best would be to use CSP pages, or use some better language like C # or C + +. I worked a lot with CSP and recommend to you. After all, remember, the Internet is all.
I can send you some examples - I think I have at home - just send me a message.
Sucess
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
If someone knew little about databases and wanted to learn about them from scratch, which database would you recommend learning with and why?
MySQL seems ubiquitous, but are there others that are more modern that have learned lessons from the past, or others that are simply nicer or more logical to work with?
Universal compatibility/libraries is not a big concern, unless it is something truly obscure. Mac (Unix) compatibility is a must.
If you just want to be learning the SQL language, and not database administration, I would recommend working with SQLite. If you're on a Mac, it should already be installed. It is a much simpler system than most RDBMSes; there is no server to set up, and client to connect to the server. There are no directories of cryptic files, or anything of the sort. To get started, you can just type:
sqlite3 mydatabase.db
And start working with it. It's so much lighter weight and easier to set up and use than the other database systems that I think it's a good choice for a beginner.
Now, SQLite is a fairly small and lightweight language. If you need be getting into any kind of really complex queries and data mining, I would recommend PostgreSQL. It has a fairly advanced query optimizer, and a pretty long list of SQL features.
And if you want to learn a database as something to use for back-end storage for web programming or something of the sort, MySQL is what I'd choose. It's ubiquitous, supported by almost any web host, and it's pretty fast for very simple queries and updates, which is generally what you need for a web system. It has some real gotchas to avoid when setting it up; you have to choose between several different storage engines, and it can take a lot of work to convince it to actually work with Unicode data. But it's good to learn mostly for its ubiquity.
From what I've seen (at least on the web), MySQL and PostgreSQL are the most ubiquitous free database systems. If you're considering learning one of them, check this comparison out.
You may also want to consider learning SQLite, a "self-contained, embeddable, zero-configuration SQL database engine." It's really easy to get up and going, stored in a single file, and as its description says, has no complicated configuration. SQLite has proved enormously popular as a persistent data store for local apps on the desktop/iPhone. If you're going down this route on a Mac/iPhone, you may also want to check out Core Data, which is an abstraction layer Apple developed on top of SQLite(but can work with pretty much any DB), to simplify working with a database. As a bonus, Core Data includes a nice GUI for forming relationships and entities. You can check out this tutorial for more information.
If you really, truly, want to "learn from scratch", then theory is the first thing to learn. And that means : NOT products, not any. Not DB2, not MySQL, not oracle, not any-of-them.
Hugh Darwen has a freely available e-book entitled "An Introduction to Relational Database Theory". The material is quite "accessible" and quite unlike most other theory textbooks. It's also the accompanying textbook for his university course on database technology.
Chris Date has several books, of which "Introduction to database systems" is the most comprehensive, also the standard textbook in the field, but maybe a little too abstract for some.
If you think that all you need is "just to know a product" and that you can do equally well "without all that theory", then in that case, please disregard this response, because the wording of your question is dishonest.
Sad thing about databases is that each and every one works bit differently. I would most likely pick MySQL first and play with it a bit. Then get PostgreSQL and do the same.
If you need to use databases in corporate environment then I would aim to test also Oracle and SQL Server which both have express versions that can be installed free for yourself.
http://www.microsoft.com/express/sql/download/
http://www.oracle.com/technology/software/products/database/index.html
At start all databases are more or less confusing but I would pick MySQL as first because it can do most of the basic functionalities and has a lot of help available.
I'd go with mysql. It's easy to setup, easy to mess around with via with mysql client, and it's well documented. If you're just starting out, you probably won't need most of the features offered by other databases, like stored procedures and the like.
First of all, MySQL is both ubiquitous and modern.
ANSI SQL is more or less the same in all RDBMs, so you can learn any of them and you'll be good.
Once you've mastered ANSI SQL, then all you've got left is the localized solutions for each one of them, which won't be portable to other systems - and so, totally discouraged to use, unless they simplify your tasks in a way justifying it.
MySQL, PostgreSQL, SQLite - pick one. PostgreSQL is more like Oracle, and in my opinion a bit more mature. It's had stored procedures, triggers, and referential integrity longer than MySQL has. I'll admit that I have both installed, but I use MySQL more often because it's quick and easy.
But do be aware that non-SQL alternatives are out there and growing in importance. BigTable, object databases like db4o, are worth being aware of. "No SQL" is out there.
If you are just getting your feet wet, MYSQL is a great one to start with. Easy install on any platform, great community support and lots of free tools to work with (SQLYog is a favorite of mine).
I agree that theory is very important. Depending on how you learn best, digging in and tinkering may be the thing to do before you try to absorb 40 years of thought on relational systems.
Codd and Date are legends in the field and can help you understand the broader points of relational theory, but are hard to absorb before you have context for the topic.
If you are looking for more pragmatic/immediate guidance, I'd suggest a book like "Databases for Mere Mortals" and anything written by Joe Celko.
Once you get comfortable with the basics, there are lots of other platforms to explore as well. As mentioned above, SQLLite and PostGres are two other great choices for the Mac OS.
If you want to learn SQL : the best way is to choose database who implement more features of the SQL standard. So I would recommand Firebird or PostgreSQL
I might be "sidetracking" a bit with this answer, but I think we're in the same situation!
Check out the "The Manga Guide to Databases"! I haven't read it myself yet, but it's on the way in the mail as we speak! I've heard good things about it from friends and colleges, and it's got some good reviews as well. Albeit a bit "controversial," it's supposed to be a fun and surprisingly in-depth introduction to fundamental techniques and principles!
Alex wrote: "Reading a textbook without incrementally testing your knowledge on an actual database is not going to produce good results for the majority of people."
My book and my university course both use Dave Vooorhis's Rel for that very purpose.
Hugh
A database in the cloud: Amazon EC2, Google App Engine or Microsoft Azure
I'm a research assistant for a university. We're retooling our Software Architecture subject, hoping to "modernize", and address some of the teaching and collaborative learning issues we've discovered in past semesters.
Students are asked to rapidly build a prototype of their architectured system using Eclipse.
For persistence, we've guided students to HSqlDb.
Last semester we received significant feedback that writing the Data Access Layer and mapping to OO has taken alot of time. This plumbing work could be better spent on more relevant things, like scaling, end-to-end perf or satisfying more scenarios.
In a real-world production, I'd pick an ORM tech, like Hibernate, but the subject is already too complex to teach yet another technology (and Hibernate is a massive one to learn for students IMHO).
So, my questions to the SO community:
Should we consider giving students an object oriented database (if they still exist)? This saves time on ORM and plumbing
Should we stick with RDBMS and tell students to roll their own ORM?
Should we point students to a lightweight, simple ORM?
Remember, this isn't real world, but we'd like to teach real world skills as much as possible. Teaching ORM not as important as getting students to rapidly prototype a system that satisfies the scenarios.
I'm a C# dev at heart but the students are only familiar with Java when they come into the subject.
I have to wholeheartedly disagree with the use of ORM in an educational environment. You need to be able to walk before you run, and utilizing ORM eliminates a very important step in the learning process regarding using a relational database in an application. You should stick to a VERY lightweight data access framework--one that requires students to write their own SQL and (at best) doesn't allow this scope of the code to be tied to the UI or (at least) doesn't require it.
I am admittedly unfamiliar with the Java world as it relates to actual enterprise development, but I realize (somewhat begrudgingly) that it's THE environment in the educational system. While I believe that students should be exposed to .NET, that's an argument for another time ;) In any even, I'm quite certain that there's some sort of framework out there that satisfies this.
I'd be willing to wager that there is something out there that provides some code generation functionality. At my old job, we only made use of the .NET database libraries to the point of (relatively) low-level reading of the data from the database. We didn't use any of the repositories or change-tracking technologies, but instead rolled our own. SQL commands were written by hand, but the framework still provided type safety and rich designer support. My point here is that both are possible. I would suggest finding something similar to this in Java, requiring the students to hand-code one or two of these adapters to gain an understanding of what goes into them, then have the code generator do the other "gruntwork" plumbing based on their SQL statements.
Don't use any SQL generation. You MUST be able to write the SQL before you let the computer do it for you. The second you use ORM to do something that you don't know how to do in SQL is the second that you've lost control of your database model, and they need to understand that.
As someone who embraced OO heartily, and RDBMS grudgingly... I would encourage, even beg, computer science departments to keep theory and practice of relational databases in the foreground. If that can be done even while you use an ORM for the OO classes, then go for it. But I'd prefer to see students coming out of college understanding that OO - relational mapping is hard, and why it's hard, and that this does not mean that the relational model is broken.
Not very broken, anyway.
If the primary goal is for the students to learn, then I think using an RDBMS would be the better approach here - they already have to grok the object model on the application side, so reconciling a relational structure into an overall architectural portfolio is an important skill.
Regarding providing an ORM such as Hibernate, I don't really agree that it is something massive for students to learn. One of the best things about Hibernate is that its difficulty level is fairly well correlated to how deep you dig into it. It has a very low barrier of entry (less than a day IMO) to get rolling with the basics, and often the basics are all you need - especially for something like a prototype, which is what you said is the goal of this activity. Certainly it does not require study to such a degree that it will stick with the students beyond the scope of the course. Basic Hibernate use can be a throwaway skill.
So to summarize, I recommend sticking with an RDBMS and providing an ORM like Hibernate.
Take a look at DataObjects.Net - is shares benefits of OR/M framework as well as of object database (if built-in storage providers are used), allowing to transparently migrate between supported storages.
It is quite advanced from the point of architecture and extensions: check out e.g. this post about its query optimization techniques.
I think it depends a lot on what the students know coming into the course. The reason I say this is that it's probably best to start with something they are all familiar with and move forward from there. In my experience, most students understand what objects are and how to use them, so presenting SQL tables as objects seems like a great place to start.
If you agree with me so far, then you might also agree that ORM is a great way to transition young programmers from their comfort zone of object orientated programming into a new world of database programming.
I'm not really familiar with the tools available for Java to implement ORM, but I was able to pick it up in C# (using LINQ to MySQL) in just a few days (after failing miserably at trying to learn PHP for several weeks). If implementing the projects in C# is a possibility, the great thing about using LINQ is that it gives students a feel for how the queries might look in SQL, without leaving their comfort zone of OOP (assuming they are at least somewhat comfortable with developing in .NET). This allows you to teach the concepts of database programming, without spending too much time talking about the implementation of it. Then, once they've mastered the concepts, you can roll back and show them how to perform a similar implementation outside of OOP (using SQL, PHP, JSP, etc.)
Not to mention, it gives them a great preview of how they can use the latest .NET technologies to do some pretty advanced stuff without too much effort (which is probably more beneficial to them in the long term anyway).
Good luck!
I know that in pure object-oriented languages like Java it usually makes sense to use ORMs like Hibernate. But what would I do when writing a CRUD-type functionality in Clojure or Common LISP?
Passing around SQL as the first-order functions? But isn't having SQL in HTML-generating code very ugly?
Thanks,
Olek
Common Lisp is not a self-consciously FP language. Clojure can just use Hibernate.
For Common Lisp: databases. Here's a persistent object one. And here is the first part of a tutorial that uses it with Hunchentoot, a CL webserver and dynamic webpage toolkit. SQL in CL can look like this (which looks longer than it really is, because the SQL is horizontally formatted and the CL isn't). And if you like, this guy is working on a web framework (using CLSQL and Elephant, already linked-to) that aims at tersity, with an eye on the arc challenge.
EDIT: a recent answer expands on this.
Ur/Web may be interesting, although it's not lisp based: http://plv.csail.mit.edu/ur/
As quoted from their site:
Ur/Web supports construction of dynamic web applications backed by SQL databases. The signature of the standard library is such that well-typed Ur/Web programs "don't go wrong" in a very broad sense. Not only do they not crash during particular page generations, but they also may not:
Suffer from any kinds of code-injection attacks
Return invalid HTML
Contain dead intra-application links
Have mismatches between HTML forms and the fields expected by their handlers
Include client-side code that makes incorrect assumptions about the "AJAX"-style services that the remote web server provides
Attempt invalid SQL queries
Use improper marshaling or unmarshaling in communication with SQL databases or between browsers and web servers
an alternative set of Common Lisp tools is described in another answer