Slashdot Mirror
SQL Vs. Access for Learning Database Concepts?
Jonathan Hamilton asks: "I work at the School of Communications for a major state University. The IT Department for the University (the same people that won't let us have a firewall, and use IIS and Exchange) is trying to talk my boss into switching from using SQL for teaching database concepts to MS Access. My coworkers and I think they are nuts. I have googled for pages comparing the two and can't come up with anything. I know some of the reasons why it is a bad idea, but I can't find any references. Help!" The mantra here is: the best tool for the best job. Is Access a suitable tool for teaching database concepts to students? If not, what would you use instead, and why?
Let them give you MS-Access, and use it like it should be used. MS-ACCESS is a pretty frond end, and sufficient for small databases. It's also a nice teaching tool because it'll let you see the syntax of a query by example. Once those lessons are imparted, and you need to do real work, the fun begins. You can then show how easy it is to install and run a real database server such as MySQL on the backend.
You can then contrast and compare the benchmarks between a system of 20 clients sharing a database on a fileserver, and a properly configured MySql server with 20 Access clients. It should teach the proper lesson once and for all.
--Mike--
Actually, SQL (Structured Query Language) is not a database, it's a language - aka, a tool for accessing databases. Microsoft SQL Server *is* a database application however, and I think their name confuses people, like the poster of this article.
Access has an SQL engine in it (not the best, but hey). I don't understand the SQL vs. Access question. You could teach someone SQL using Access.
Realistically, there are much better dialects of SQL than the Microsoft ones. No need to start them off with the bad habits Microsoft encourages. PostgreSQL has one of the most ANSI-SQL compliant parsers, and it's free. I see no good reason to pay extra to get an inferior product.
Really, Access is more of a database client creation toolkit with a poor-man's database tacked on. It does some things quite well, but it's somewhat crippled to only work well with Microsoft products.
I get the jibblies just thinking about a bunch of first-year students "learning" that relational database == MSAccess.
The relational model, as invented by E. F. Codd, is heavily grounded in mathematics and set theory, and exists independently of higher-level access interfaces such as SQL.
You can certainly teach people to create and use databases through Access or SQL, in the same way you can (to pick a randomly politically incorrect analogy) teach people to create bombs without telling them how chemical reactions work, but then you're not telling them the full story.
Knowing what a Cartesian product is, or what normalization and the five normal forms are, or what relational integrity is -- all that lets you design better, more flexible and extensible schemas, and interact more intelligently with your data. I know Access developers who don't have a clue about the relational model, and as a result design terrible applications.
As a starting point, I recommend the books by C. J. Date, in particular An Introduction to Database Systems, 7th Edition ; his book The Database Relational Model: A Retrospective Review and Analysis: A Historical Account and Assessment of E. F. Codd's Contribution to the Field of Database Technology also looks very interesting.
As an aside, what's surprising is how many people consider Codd's original ideas outdated. The fact is, his ideas surpass what's implemented in database systems at the moment. SQL is a weak language (and SQL99, with its silly object orientation extensions, hasn't made it any better). Database vendors routinely expose underlying implementation issues to the user. They tightly couple physical representation with logical representation, leading, for example, to many people avoiding normalization because it incurs a significant performance penalty with most databases. RDBMSs today are crap.
teaching with access is like straight to the calculator. If you dont have it your're stuck, and you don't really understand the interactions between elements then debugging from the help files can be fruitless.
If you are trying to teach SQL (the language) things like stored procedures and triggers are integral not added extras.
--
"we live in a post-ideological world..." - Billy Bragg.
And neither is MySQL's syntax. The SQL for example has nested queries. MySQL does not have that.
In the end it's all about relational calculus. You can teach that with both tools at hand.
The article seems to suggest that Access is very bad at being serving a database (i.e., it is not suitable for real database work) - and that is certainly the truth, yet you will hardly need a real database for teaching relational calculus. Either Access and MySQL will do.
&& aemula C. ab stirpe interiit
I've just spent the last week or so installing and attempting to uninstall Oracle 9i and 9iAS over and over again. I have *never* seen a piece of software that is as user hostile and fragile as this. Comparing SQL with Access doesn't make much sense to me but bare this in mind whoever you go with. My colleagues at work have had much greater success with the 2 main open source DBs (MySQL and PostgreSQL).
I'll agree with you on some data limits with MSAccess (used it for close to 8 years now, maybe longer... think I started on 2.0 or 2.1).
Once your tables push past around 500,000 or 1,000,000 records, it's all downhill performance-wise. Large inserts into an indexed table were prone to be slow as molasses (usually killed the indexes prior to the insert and then rebuilt).
OTOH, it was a decent way to learn the basics of SQL, limited relational database design, and a way to start learning Visual Basic and how to program forms. (I wrote *a lot* of VBA/MSAccess stuff in my old job... even used it as a poor man's prototyping tool once.)
It's also darned convenient for passing around data sets without constantly having to import/export to CSV or setup dozens of databases on a developer SQL server. Unzip the MDB, open it up, start querying (or running saved queries)... dirt-simple for small data sets (anything less then 100Mb). Screw up the database, easy enough to unzip it from the archive again and have another go (compared to bugging the admin to restore from tape).
Wolde you bothe eate your cake, and have your cake?
Not really. Access has an odd version of non-standard SQL. I write code to interact with mySQL, MSSQL, and Oracle databases at work all the time. Recently, I had to write some code to interact with Access for police laptops as interacting with a central server was too bandwidth intensive for their in-cruiser RF computer network. Access was VERY picky and rejected more than a dozen commands that would have worked fine in any of the three major SQL DBMS products.
In short, Access shouldn't be used to teach SQL. Anything more than basic SELECT operations on integer fields will start requiring the use of non-standard extensions and work-arounds.
Access is great for teaching the basics of relational databases - but Enterprise Manager, which ships with MSSQL, is superior in this respect also.
How many roads must a man walk down? 42.
You might consider taking a step back and actually looking at the class content rather than debating which system to use for it right off the bat. Based on what little I've seen, this course is to teach databases (perhaps use, perhaps design) and underlying concepts. Is this a beginners' course? If so, you should probably strive to stay away from any given platform. I'd suggest taking a look at sqlcourse and maybe conceptualizing a class outline around that. The course itself only briefly grazes various SQL platforms.
I only offer this suggestion, having actually taught database, SQL, and platform-specific SQL classes for a former employer. The software we wrote supported two SQL back-ends: Sybase and MS SQL Server. That alone was enough to put most of the support reps I was instructing into a frenzy. When I started backing away from platforms themselves, and just teaching basic T-SQL along with diagrams of tables on a white board, it went a lot more smoothly. Really, it doesn't matter what platform you write for if you understand the query language enough to write fairly universal queries. To do anything that requires significantly esoteric querying probably requires you to have a very deep insight into the specifics of the platform you use.
It's really pretty amazing the amount of information you can teach without having to really use any SQL--but again I suggest looking at sqlcourse because it has you writing standardized T-SQL queries, but you don't ever see what platform you're using (if you're using one at all).
If this is really a class to teach basic dba functions like writing triggers and tweaking your platforms for performance, then it really comes down to the sad truth that to teach these skills you really need to teach them for a specific platform. Every company has their own esoteric set of tools, commands, and standards that in most cases have some striking similarity to T-SQL, but may do something different (look at how Pervasive.SQL, MySQL, MS SQL Server, and Sybase handle the idea of committing or rolling back a transaction).
I guess in summary it boils down to what concepts you're trying to teach. You may find that teaching database theory doesn't even require real databases. Ask a student, given two small tables, to describe what would be returned if table A and table B were left outer joined. They'll either get it or they won't, and I can't say any given platform will demonstrate it any better than a pencil and paper.