Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Education Software

SQL Vs. Access for Learning Database Concepts? 160

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?
This discussion has been archived. No new comments can be posted.

SQL Vs. Access for Learning Database Concepts?

Comments Filter:
  • by ka9dgx ( 72702 ) * on Thursday December 11, 2003 @07:53PM (#7695634) Homepage Journal
    The secret to dealing with rules like this is to bend with the wind, like a reed.

    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 [mysql.com] 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--

    • by adamy ( 78406 ) on Thursday December 11, 2003 @08:38PM (#7696068) Homepage Journal
      Yep. It works well.

      Better yet, don't teach em Access at all.

      Teach em SQL. Make em do it from the command line. They will thank you in the long run. Why, because then when they have to write embbedded SQL to get their app to run, they will know it.

      • exactly how i was taught... straight from the command line - the most effective way IMO
        • This all depends on what they are trying to teach the students. If they are trying to teach the students relational database basics, then access is definetely the way to go. If they are trying to teach the students SQL, start with Access for the ability to create Queries and view the SQL, but then force a move to an environment where SQL and commands specific to the specific sql backend are required. But I would not suggest MySQL by any means. Postgres or Firebird is the only way to go if you actually w
      • When a friend asked me to teach him a bit of SQL, I did just that.
        To keep it from being boring, we also started doing small web applications with the databases and tables we built - it was actually quite a bit of fun.
        We used MySQL, since it was a simple matter to set up on his Windows 2000 laptop for his practice. Apache and PERL are also braindead easy to set up and offer quite a bit of cross-platform usefulness.

        I used to do a lot of Access, way back when. I'd recommend avoiding it, as I later spent a lo
    • mySQL is a "Real Database"?

      Can you tell us what school you went to, so we can avoid it? Thinking mySQL is a "Real Database" is worse than teaching relational database concepts on Access.

  • Either would be fine for teaching about the concepts that make a datbase what it is. The problem with most computer instruction is the various versions of the program being taught. Because many are going to be on a budget you will see everything from Access 97 to 2003 (hopefully none older than that). With sql you can have all students on one free platform (mysql) and they can take home notes that make sense.
  • For the love of God, stick with SQL - it's a simple case of one being slightly more difficult than the other ("I have to type stuff in rather than letting an anthropomorphic cyber-dog walk me through creating an address book"), but much more powerful. I say "slightly" more difficult because I know people can get into some pretty squirrely territory with SQL but you dont need to in order to learn basic database concepts. A very exaggerated example along these lines would be the difference between TeX and som
  • by cybermace5 ( 446439 ) <g.ryan@macetech.com> on Thursday December 11, 2003 @07:57PM (#7695671) Homepage Journal
    I think you should find out if these students are more likely to use MS Access in an office setting, or developing SQL database applications in some programming language. Once you discover what the students will be using their database skills for, the answer will become obvious.
    • Actually, I don't know many ppl that use Access in an office setting. Most use something like Oracle, MySQL, or DB2...

      If they are enough of a user to NEED Access, they are more likely to use a Web interface to a REAL SQL backend...

      What's more likely is that this school was given free licenses, free books, new computers, or just plain old money to use Access...
      • Gotta disagree with you here. Most non-developers use way more Access that Oracle/SQL Server/Sybase/etc, because everyone has it on their machine (comes with Office). People who are requirements or test people at my work use it to tap into our Sybase database because it's easy to build queries visually. Bunch of data, need to crossreference, don't know Perl? Use Access. Business types use it a lot more than any other database.

        --trb
      • Since this is the School of Communications and not the School of Computer Science, I think that they could use Access in the office life. I know plenty of users who have to compile reports by taking data out of the ERP system and analyzing it. If there are less than 65536 rows of data, then Excel does fine, but if there are more, MS Access is the perfect tool. Access allows for easy generation of reports and easily doing data lookups across tables.

        And since Ms-Access is installed with some/most business
      • I dunno about an office setting, but as a developer, I use Access whenever I'm prototyping a new database. It's easy to create a new database, easy to access through Jet, and easy to modify on the fly when I screw it up. It lets me work out my table structures and run test queries using my programs or directly via the SQL. Okay, I have to work around its fucked up SQL if I work with Access directly, but the Jet engine's SQL seems to be mostly standard and works much differently from Access's SQL builder cra
    • I disagree. If a student wants to learn MS Access, that student should go to a local adult education centre or perhaps a college and learn it there. Universities should teach the knowledge and pay much less attention to the specific, proprietary, tools.

      That's not to say that MS Access has no business being taught at a university. Simply that if it is used, it should be used to teach SQL and relational database fundamentals. MS Access isn't, in my opinion, the best tool to use to teach this knowledge bu
  • SQL Works In Access (Score:5, Informative)

    by avalys ( 221114 ) on Thursday December 11, 2003 @07:57PM (#7695674)
    Somehow no one seems to know this: you can execute SQL queries from within the Access GUI.

    While editing a query, just click the View menu and go to "SQL View".

    So, you can start out with the basics of databases using just Access' GUI tools, and then graduate to SQL without having to switch environments.
    • Using Access to teach concepts isn't a problem. It allows you to quickly set up the database, easily change errors on the fly, and provides a decent automated system for adding data.

      Just make sure that you start with the general "wizard" approach, and then move on to using real SQL for things. They can build a query (or whatnot) and switch to the SQL view to check things as needed, which is a boon while learning.

      Then have an in-class demonstration of benchmarks between Access and any other DB :P

      Also

    • Yes, you can, but the point is whether you teach by building up or down...

      JoelOnSoftware has a good piece on the 'Law of Leaky Abstractions' [joelonsoftware.com] which for me sums up the problem with using Access as a teaching tool.

      When someone doesn't understand that their "report" is returning no rows because they really don't understand outer-joins, then you have frustration. SQL at least forces you to think about those things.
    • 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 S
    • >So, you can start out with the basics of databases using just Access' GUI tools, and then graduate to SQL without having to switch environments.

      No you've just taught students how to click the View menu and go to "SQL View".

      Teaching them how to compose and manipulate a SQL statement is totally different. Except for very basic SQL statements, its a crutch.

    • So, you can start out with the basics of databases using just Access' GUI tools, and then graduate to SQL without having to switch environments.

      Not always. I took my databases course from a prof who specifically said we could not use Access for our projects because "it's a toy, not a real database." He was right.

      Two years or so after taking this course I had to do a complex query at work on an Access database (let me add the caveat here that I am an embedded software developer, not a DBA). I can't recal

  • The mantra here is: the best tool for the best job.

    No, it is not. The mantra is whether you should half-truths about databases and then later someone will be able to use a real database. Access is not a database it is a "database-program" one is inseparable from the other. SQL is a type of database that holds true to what it is, a database. It does not create forms, process charts, or do anything else that databases DO NOT do.

    • Re:You're Wrong (Score:3, Insightful)

      by hawkbug ( 94280 )
      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.
  • some old shit from few brief access lessons back in (local equivalent of)highschool.

    it was just pretty ui playaround, even if i did remember the lessons well i wouldn't be able to use any of that information to my advantage now.

    though, if you do it properly and teach some concepts behind the issues and just use the particular program you're using on the course just as a tool to get something done then you should be ok by going with whatever you choose. teach the concepts, not just what button you click.
  • Database concepts (Score:1, Interesting)

    by adamshelley ( 441935 )
    In our school in our "Database concepts" we were designing databases and creating bachman/bubble diagrams learning the different levels of normalization and talking about uml. When we got deeper into the course (2nd year) we added more practical aspects like writing sql statements by hand: I believe this is where access falls short. I don't believe the syntax of access is 100% standard. Sure its great to be visually able to create queries but it is probably more important to teach the actual concepts an
    • I believe this is where access falls short. I don't believe the syntax of access is 100% standard.

      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 teachin

    • Re:Database concepts (Score:2, Interesting)

      by jonadab ( 583620 )
      > I believe this is where access falls short. I don't believe the syntax of
      > access is 100% standard.

      Last I knew, no available database has 100% standard syntax. They all differ
      from the standard in a number of areas.

      The problem with Access is that it's becomming obscure. It's not included
      with most versions of MS Office anymore, for one reason or another (probably
      because MS wanted to drive sales of their _other_ database offering, SQL
      Server), and so consequently few desktops have it, so nobody know
  • Both (Score:5, Informative)

    by borgboy ( 218060 ) on Thursday December 11, 2003 @08:04PM (#7695744)
    Use both, really. Having Access gives you rights [microsoft.com] to use it in conjunction with the MSDE, which is sql server with some limitations [microsoft.com].
    Access can also be a pass-thru front end to other ODBC enabled RDBMSs.
  • Some Data (Score:5, Informative)

    by BrynM ( 217883 ) * on Thursday December 11, 2003 @08:04PM (#7695748) Homepage Journal
    I don't know if by SQL you mean PosgreSQL, MySQL or SQL server, but I did find some data.

    • Database Journal has an article [databasejournal.com] comparing SQL Server 2000 and Access 2000, but the feature list shouldn't have changed much. The charts that you are interested in are at the bottom right before the conclusion.
    • Here's [kookel.org] a speed comparison between MySQL and Access.
    • Here's [bradley.edu] a great comparison of many SQL technologies including Access.
    You do realize that you can install MySQL on a server and use Access as the front end via ODBC, don't you. If you do that, you can teach both and show the reasons why a particular solution would fit particular needs in addition to teaching the bare DB concepts. To me, this is the most open ended solution without having to create problems with people at work.
    • Re:Some Data (Score:5, Interesting)

      by Nicodemus ( 19510 ) on Thursday December 11, 2003 @08:23PM (#7695937) Homepage
      This is just anecdotal, so take it with whatever grain of salt you want to. I've extensively used a few different database servers in the last 5 years or so, and am an Oracle certified DBA for 8i. Mainly MySQL, PostgreSQL, db2, Oracle and Access. When it comes to performance, Access can be fast. Not sure about the validity of it, but I remember hearing somewhere that Access uses ISAM tables, just like MySQL used to use in the 3.x days before MyISAM and InnoDB. I've done some stuff in Access that was fast, and stome stuff that was painfully slow.

      A project I worked on once initially had a requirement of developing a prototype in Access. This was doing some hard crunching on a lot of data (so much so that we kept hitting the 2 gig limit of Access). It eventually got to the point where we were doing a certain operation that was pretty simple really. Read a bunch of data from one table, and insert results from the calculations in a couple other tables. This was originally developed completely in Access using VBA. It was slow, to say the least. I had profiling code in it so that I could see the current progress, and the projected completion time. The first time we ran it, it projected that it would be finished in a couple months. We spent a week tweaking like mad until we got that down to just under 4 weeks.

      So then we decided it was time to scrap Access as a DB, and moved all the data to a db2 database. Our initial hope was to continue using the VBA code, though... so we hooked up the VBA code to the db2 database through ODBC. Even after another week of tweaking (including figuring out how to sorta do prepares with the kludgy API) the performance was even more abysmal than when it was in Access. Somewhere around 6 weeks if I remember right.

      At this time I convinced the project manager that I could get the performance up if I ported it to Perl. I finally got the go ahead, and spent a few hours porting the code over (remember, this was a pretty simple function, it just had some ugly calculations). My first result with Perl was about 1 week. But then I realized that I had forgotten to prepare my inserts outside of the main loop. Fixed that and the thing ran in 6 hours. I swear... I'm not exaggerating or anything.

      My lesson from the experience, was that Access can't handle large amounts of data (besides the fact that it has a built-in 2 gig hard limit), and that preparing before your loop is a HUGE optimization. I had used prepares like that before, but on such limited samples that it didn't make that big of a difference.

      Like I said, anecdotal, but it definitely tought me some lessons.

      Nicodemus
      • Re:Some Data (Score:3, Insightful)

        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
      • Comment removed based on user account deletion
  • What? (Score:5, Insightful)

    by Bistronaut ( 267467 ) on Thursday December 11, 2003 @08:05PM (#7695754) Homepage Journal

    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.

    • Jet sucks as a database engine. SQL Server is ANSI SQL-92 compliant, Jet isn't.
      • Re:What? (Score:3, Informative)

        by BrynM ( 217883 ) *
        From this [devguru.com] article:

        "Jet SQL has certain limitations compared to the other versions of SQL. In general, Jet SQL is not designed to manage a database, but rather, it is used to retrieve information from a database. To cite two limitations, Jet SQL, by itself, cannot create a database and cannot manage security . This is where the Microsoft Data Access Object, commonly called DAO, enters the scene. DAO contains libraries which are designed to manage databases. While, yes, you can use Jet SQL without DAO, you a

        • I was referring to the Jet engine in my comment. DAO is the API to the Jet engine. In saying it sucked, I wasn't referring just to Jet's implementation of a query parser/processor, I meant all of it.

          Once upon a time I did my share of Jet programming, especially in the context of delivering custom Access "applications." Jet's management capabilities leave a lot to be desired, especially compared to the likes of the SQL-DMO.
          • "Once upon a time I did my share of Jet programming, especially in the context of delivering custom Access 'applications.'"
            Dude. I'm sorry. I've done some Axesucks development in my time as well. I feel for you.
    • I looked, and couldn't find a distro of PostgreSQL for Windows. Given that he's running Access, it's likely (though not given) that he is running Windows. In his case, a Windows product that is already free to him may be a better alternative than a (admittedly free and high quality) RDBMS that doesn't run on his platform of choice.
      • To run PostgrSQL on Windows you will either have to install cygwin first - Cygwin comes with a postgreSQL package - that or purchase it from DBexperts [dbexperts.net].
      • Computer Science Courses shouldn't be taught on Windows. They should be taught on some flavor of UNIX/Linux.

        But But But that is what they will use in industry cry the MS folks.

        Not in my shop.

        I feel better now.

        Teach PostgreSQL.

        SQL != MS SQL Server.
        • I can see no logical reason why a platform should dictate what one teaches or practices in computer science.

          One should be able to learn an MS operating system or a *IX system or a palm or AtheOS or...

          I'm more concerned that they are familiar with a couple of languages out of a CS degree than I am that they can tell me what a wheel group is.

          If it's an administrator, know a scripting language and XML. Know at least three operating systems, and be able to pick up an application in ten minutes because the bo
      • There are lots of client programs for PostgreSQL that run on Windows. Hell, even Access is one of them (though not recommended). My favorite is PgAdmin [pgadmin.org].

        With PHPPgAdmin, any platform with a web browser can interface with PostgreSQL. I don't think client platforms would be a problem.

        Now, if the server is running Windows, well... how about not running Windows on your database server. Really, why would you want Windows on your class' database server?

        If your IT guys won't let you bring in a little Linux box f

    • you're completely right.

      fwiw, our it and mis (academic) departments both use oracle heavily and the cs department uses oracle exclusively in its database classes. as far as i'm concerned, while access has its place, that place is far far far away from anybody whose goal is to actually learn the principles of databases. if you want a well trained monkey who can do basic database stuff, send them to any ms office class. if you want someone who actually understands what's going on and has a set of skills (spe
  • As mentioned above it is a good looking interface but you dont want to teach them to depend on a nice looking gui for a database.

    If they wont let you use IIS then can I suggest Microweb [indigostar.com] for a quick eval to see if you want to go the MySQL route. Just download it and burn it to a CD and then you can quickly and painlessly see how MySQL works on any win32 computer.

    If you also download the phpMyAdmin [phpmyadmin.net] and drop it into the cd you can use the graphical web-based frontend and see how simple and powerful it is
  • by OneFix at Work ( 684397 ) on Thursday December 11, 2003 @08:11PM (#7695829)
    Access has the most overhead according to this [weblogs.com].

    Here's [wku.edu] a link to a discussion where the poster states that Access is not good for large installations...

    You might check with IBM (DB2 [ibm.com]), Oracle [oracle.com], MySQL [mysql.com], or Postgres [postgresql.org] for help as well...I'm sure they'ld be more than happy to help.

    Cross platform compatability. Students with Windoze, Linux, or Macs can run most SQL servers...not so with Access...

    And then there's the corporate settings...most companies are using DB2, Oracle, MySql, or something that is ANSI-SQL compatible...not M$ SQL...

    You also have more utilities and help available for SQL than Access...

    There's GUI tools, schema browsers, etc all available for SQL...

    If your school runs its website on a *NIX server, you could up-play the compatibility angle...you know, senior projects and such...

    One major advantage of SQL is that all of the companies/organizations that I mentioned are free or have a free educational version...I doubt M$ does...
    • most companies are using DB2, Oracle, MySql, or something that is ANSI-SQL compatible...not M$ SQL

      What are you basing that statement on? This [entmag.com] Gartner study released earlier this year has Oracle as no1 followed by DB2 but both of them losing marketshare, while Microsoft in the no3 spot increased revenues for 2002. And, MS SQL is the number 1 db for Windows.

  • SQL is a standardized language (well, at least some common ground for every SQL implementation), knowledge of it has a great re-use value, and is not linked to a particular vendor.

    Learn Access, and be tied to 1 platform. It's a bit like learning VB; yeah it's easier at first but afterwards you're caught in the Microsoft playground.

    Education, I think, must avoid teaching proprietary technologies. I have an Access course, so to work from home I have to buy Microsoft Windows and Microsoft Access. As studen
  • MSAccess is the biggest piece of crap I've ever run across! You would not believe the stupid crap I have to deal with because of Access. It's SQL support is rather limited so I end up having to code VB routines to do anything useful.

    SQL server is better but it's also very vulnerable to attack and virus/worm exploitable!

    The real solution would be to drop in a Linux box, setup telnetd or sshd and let the students telnet into their own shell accounts. Then have them run PostgreSQL and experience a real fr
    • I agree with your feeling about the tools, however, you seem to be explaining a view about teaching database _access_ (not to be confused with MS Access) methods, as in, the front ends and programmatic interfaces.

      I believe the question was, as the titlebar says, "SQL vs. Access for Learning Database Concepts". APIs are not concepts, at least not in this context.

      I'd assert that both Access and [insert SQL RDBMS here] are crap for a theory class. A real SQL database is less crappy, but unless doing nothin

      • I'd assert that both Access and [insert SQL RDBMS here] are crap for a theory class. A real SQL database is less crappy, but unless doing nothing but teaching people to think about FKs and joins is the goal, the class should start on the chalk board. Explain set theory, have people work out the problems on paper.

        Theoretical knowledge is all good and well, but the article mentioned a department of communications, not CS so I doubt this class is very theoretical (otherwise I doubt they'd even consider usin

        • I missed that this isn't a CS class, sorry about that.

          How much theory does one need when it appears that the most common database implementation these days involves nothing more complicated than "SELECT * FROM Authors"?

          I see people using DBs for this and honestly, if that's all you're doing, it is pretty pointless to use an RDBMS for it - the overhead and complexity outweighs the value that you're not using. 5 lines of perl and a flat file are going to be fine for you. I know people do it every day, bu

  • I can tell you that from what I've seen Access here is being presented as seemingly the only database that a user would need, along with Word, Excel, and Powerpoint as the only office apps even available. It seems like somewhat a quagmire for people to get sucked into, depending on Microsoft's crappy software.

    On the educational standpoint, I think it's really hard for the students I am alongside that don't have other database experience to grasp the ideas of Access as a database. It may just be my inst
  • Neither! (Score:5, Insightful)

    by Earlybird ( 56426 ) <slashdot&purefiction,net> on Thursday December 11, 2003 @08:28PM (#7695977) Homepage
    SQL and Access are not the place to start. Relational database theory starts with exactly that -- theory.

    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 [amazon.com] ; 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 [amazon.com] 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 [dbdebunk.com].

    • Re:Neither! (Score:2, Interesting)

      by Frequanaut ( 135988 )
      Good lord, just when I really start to wonder about the cluelessness of the people on slashdot I can always find a perl like your comment.

      I had to scroll to the bottom of the page before anyone even noted the fact that SQL is a language while Access is a database and front end. (with SQL support).

      Nevermind all the non relational databases.
    • Re:Neither! (Score:4, Informative)

      by bpb213 ( 561569 ) <bpbyrne AT gmail DOT com> on Thursday December 11, 2003 @10:14PM (#7696928)
      I second this. In the into to DB class I took, we didnt even get to any languages at all without going through all the basics, normalizations, etc. Only at the VERY END of the class did we actually use databases, and for that we used oracle. (school had a large piece of sun iron running it, but the class was flexible about using mysql and other databases that understand SQL)

      So take the parent posters theme to heart:
      Teach the how and why first, then teach someones interpretation(implementation) of that.
    • Re:Neither! (Score:3, Insightful)

      by Unordained ( 262962 )
      I think you forgot to mention another of their great books -- Foundation for Object / Relational Databases: The Third Manifesto [barnesandnoble.com] by Chris Date and Hugh Darwen.

      In it, they re-iterate their ideas up until now, integrate other stuff, and show how database concepts are completely orthogonal to the object concepts often brought up: datatypes don't matter for relational theory, but they're important for your final database. There's algebra, and then there's math. Relational theory is about the algebra, database s
      • I haven't read the "Third Manifesto" book, only skimmed through it at the book store, and my impression is that it's not relevant for a database course.

        There's algebra, and then there's math. Relational theory is about the algebra, database systems are about math across different domains, using that algebra.

        That doesn't make sense. Algebra is math -- it's a branch of mathematics. Database applications implement the relational model.

        • Def. of Mathematics [hyperdictionary.com]

          I don't mean to make this about definitions -- but I'd like to explain what I mean. It probably would have been safer for me to say that relational theory is about algebra, not arithmetics. However, the definition above is confusing: it cites mathematics, as a whole, as being about quantities and magnitudes. Database theory doesn't care about magnitudes: they are only one particular type of value that can be manipulated. Arithmetic (and by their definition, math as a whole) is about spe
    • > As an aside, what's surprising is how many people consider Codd's original ideas outdated

      Including Codd himself. Not all of them, but he's certainly put them up for revisiting. Specifically, he's not at all fond anymore of NULL (Rule #3 of the 12 rules). Anyone who believes their own principles are final and immutable is simply deluded.
      • Including Codd himself. Not all of them, but he's certainly put them up for revisiting. Specifically, he's not at all fond anymore of NULL (Rule #3 of the 12 rules). Anyone who believes their own principles are final and immutable is simply deluded.

        Details of the original model might be up for discussion, but the general principles of the model are not outdated, and that was my point.

        Codd actually provided two different "null" values which encode two different meanings: A-MARK (data not available) and I

  • First Priniples (Score:4, Insightful)

    by Ratso Baggins ( 516757 ) on Thursday December 11, 2003 @08:28PM (#7695978) Homepage
    As with learning long division, only to be taught the short method, then given a calculator. You are taught how to do it from first principles so you understand why.

    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.

  • Do they want faculty to tell them what email platform to use, or how to configure their switches? No? Then they should shut up and let faculty do what they hell they want, and only offer an opinion if they're asked.

    As say this as an IT worker at a university, who's constantly dealing with faculty who say "Why don't we use Technology X here?".
  • Oracle 9i and 9iAS (Score:3, Insightful)

    by nickos ( 91443 ) on Thursday December 11, 2003 @08:48PM (#7696154)
    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).
    • Did you take time to read the documentation? I have found working with Oracle to be a pleasureable experience. The last 18 months of my employment working with Oracle have been a charm. We have NEVER had an unscheduled outage in that time, thanks to an awesome dba and our unix admin. :) I really love the versitility/scalability/speed/power it provides.
  • you've either failed to communicate or you've demonstrated that neither you nor your it people have a clue.

    sql = structured query language, i.e. a capability that rdbms may implement.
    access = m$ attempt at a rdbms 'lite' which implements part of sql
    sql is not synonymous with dbms, EVER.

    i feel better now. that said, i'd stay the hell away from access if your goal is to teach a *database* class. if students want to learn access, send them to a course about office. if they want to learn about databases, skip
  • Ignoring the "we are contemplating from switching from SQL statement" (what is SQL? I am going to assume you mean SQL server, and are just so familiar with it that you just call it SQL now... if not, you shouldnt be doing any DB work at all, do everyone a favor and stick to excel before you create behemoth database schemas that will give people nightmares for years to come). But anyway...

    Access is nice from a learning perspective in that its easy to install, seperates you from what can be some nasty DB ad
  • I think Access is great for most people to get some understanding of what a database is and does. Start them out on Access. The average person will grasp way more from playing with Access than playing with SQL. After that explain why Access sucks and have them port whatever they created to some other platform. This reflects what I and many others do - prototype on something like Access and then build the final product on something a bit more robust. I know Access has many limitations and we could list t
  • When I started my computer science degree, one of the first-year units was about databases, and they used Access as the basis for teaching and assignments. We had to construct all the queries using that visual tool where you drag lines between the columns of the different tables to represent relations.

    This sucked. I was confused and had no idea what I was trying to achieve with these queries, and found I was spending most of my time fighting a very lame GUI.

    A year later I had to use SQL for some other
  • One Vote for Access (Score:2, Interesting)

    by cookiepus ( 154655 )
    I've in the past built an application that uses Access as a db, using an ODBC::JDBC bridge. My choice for using Access as a db was the correct one given the nature of the application (don't argue design decisions here. Yes, i COULD have told them to convert to Linux and use mySQL. I could also implement it in the way that would be the least pain for the cusomer. I did the later)

    Here's what Access has going for it:

    1. It's easy, and it's visual. You can start creating tables and entering data w/o knowing an
  • Access is good (Score:3, Informative)

    by ttfkam ( 37064 ) on Thursday December 11, 2003 @10:32PM (#7697067) Homepage Journal
    For the visuals. Queries can be made by dragging and dropping columns from tables. Table creation without learning SQL syntax is simple as well. For that alone, I would recommend Access. It makes it easy to teach the concepts before being mired in syntax cruft.

    That said, I would recommend using Access as a frontend to a real database via ODBC. Then you have the ease of use and baby steps at the beginning as well as the power, seamless transition to better functionality, and (perhaps most important) the hint that Access should rarely be used on its own for all but the most trivial of projects.
  • NOT ACCESS!!!! (Score:5, Interesting)

    by JetScootr ( 319545 ) on Thursday December 11, 2003 @11:00PM (#7697252) Journal
    1. Query builder. No one can learn advanced database topics from the Access Query builder. I started trying to learn database after having been a professional programmer for about 10 years (Fortran, C, Asm). When I did, I started with Access. I used the query builder to build SQL, and then tried to learn how the SQL worked. It was a mess. Nothing made sense, syntactically. It seemed that no matter how I tweaked it, the rules for what is legal and what isn't never became apparent. What's worse, even if the syntax was acceptable, sometimes I would get the wrong data back and not know why.
    Access wasn't failing or misbehaving in this - I just couldn't figure out how to make it work using Access's Query builder and just "tweaking" the SQL. I learned Unix, C shell, Bourne shell, C, and Assembler all by grabbing the documentation and a keyboard, and digging in. I know how to figure out a new tool.

    But my difficulty in learning SQL from Access made the REAL knowledge I needed even harder to get to: How to normalize data, how to analyze a process and figure out what's really going on, etc.
    Building the SQL is the last step in the process, and the easiest. That's what SQL is for - so that the tool doesn't get in the way of purely processing truly abstract data. Real SQL does this beautifully.
    I took an Oracle class and learned more in one week than I had with Access in one year. Microsoft's query builder and Access documentation hadn't really helped me.
    UML straightened me out - by teaching first the concepts, then the structure of the SQL language, then the syntax. By that time, the syntax was easy and even made sense. Access really held me back.
    2. Errors in Access's handling of SQL. Here's an example for you. You can set up test tables and prove this to yourself. Create two tables, each with about four fields. (This occurs in both Access 95 and 2000)
    Join them on TWO fields, like this:
    Select * From Alpha INNER JOIN Beta

    ON ((( (ALPHA.KEYONE=BETA.KEYWUN)
    AND (ALPHA.KEYTWO=BETA.KEYTOO)
    )))
    WHERE (ALPHA.ATTRIBANY="WHATIWANT");
    Be sure to add the extra parans on the join clause - I'll explain why. Access will accept this statement. It will actually work - set up some test data and try it. But save and close the query.
    Reopen the query.
    You'll notice that join statement loses the outermost set of parans every time you do this. If you compact the database, and Access has to move this query, it will lose another pair.
    Eventually, it will become this:
    Select * From Alpha INNER JOIN Beta

    ON (ALPHA.KEYONE=BETA.KEYWUN)
    AND (ALPHA.KEYTWO=BETA.KEYTOO)
    WHERE (ALPHA.ATTRIBANY="WHATIWANT");
    Once the "AND" in the join clause is "exposed" without enclosing parans, Access will reject the query, saying "Unsupported join syntax". This will occur to perfectly functional queries that have long been in use, because ACCESS EDITS YOUR SQL WITHOUT YOU KNOWING IT!!!! Once the SQL becomes "invalid", Access won't let you open the query anymore, even in design mode, so you can fix it. There's nothing you can do with it but delete it at that point.
    3. Many more reasons.... But I'm coming in late to this article. If you want to hear them, reply to this post with another post. I don't get modded as a troll, when I'm actually showing facts. I also don't want to spend huge amounts of time if I'm too late and it's not going to be read by anyone.
    • Those of us who have used Access have learned to accept that Access edits our SQL for us. In fact, it's a nice "feature" if you like to bang something out in a hurry - Access will automagically reformat the query so it looks nicer.

      The real issue I have with Access is not the uncommanded editing, but the data corruption. If a database connection is lost during synchronization (phone line gets dropped, etc...), Access will corrupt the database. What's worse is that Access doesn't detect the condition a

      • Re:Yeah, yeah... (Score:3, Informative)

        by JetScootr ( 319545 )
        I certainly agree that the number one "feature", or that is, requirement, of a database is Protect the data at all costs! On that score alone, I'll concede that your point has a higher priority than mine.
        But to me, a parallel requirement of a development environment is Protect the code at all costs. If a developer writes the SQL by tap-tap-tapping it out on his own, the tool should leave it the way the developer wrote it.
        I don't accept as valid that the tool can go into MY code that I wrote with my own
  • I learned SQL by fiddling around is Access. It was great for teaching the basics. The problem is that Access doesn't make you learn proper SQL vocabulary and syntax. Therefore Access becomes a crutch and when conversion with coworkers about queries, I have difficulty because I don't know the proper name for a given type of join; rather I just know to right click on the line joining the tables and toggle the join type.

    I'll also echo other posters who have said that teaching RDB theory is essential. It's

  • Most important (Score:3, Interesting)

    by dtfinch ( 661405 ) * on Thursday December 11, 2003 @11:18PM (#7697361) Journal
    Is that students learn about good database design and the full querying power offered by relational databases.

    Access is an excellent prototyping tool, which saves you a lot of the typing and repetition involved in developing database apps. But for any just about any useful project they're faced with in real life, SQL knowledge will be a must. If they learn Access, and the price was right (academic discounts), that's all good and fun but the focus of the class should not be to get them hooked on a proprietary, non-scalable database app if you want them to get a good education. Don't let their final project be without coding.
  • 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 [sqlcourse.com] and maybe conceptualizing a class outline around that. The course itself only briefly grazes variou
  • Something you mentioned that seems off to me is that you're looking at this from the "School of Communications" point of view. First off, why is the Communications school even teaching a database class? Isn't this usally a CompSci department thing?

    Considering that you're teaching non-major students about databases, learning Access instead of proper SQL gets put in a slightly different context. We're dealing with non-programmers, so Access is probably a better solution for their skillset and scope of int
  • How many Access databases do you know ? You can know only one, since there is only one. It's from MicroSoft and it only runs on Windows. It's a dead end.

    On the other hand, without spending more than three seconds of thinking I can come up with more than half a dozen SQL databases, on all kind of operating systems and in all kind of flavours (from the very simple ones to the overpowered ones).

    When you look into the real world out there you're stumbling over SQL database everywhere. It's what's used out the
  • I work at the School of Communications for a major state University.

    I work in the CS department at a smallish, private university with a liberal arts focus, and I'm responsible for the Oracle systems used in DB/DBA courses. Your question seems strange to me. Some questions/comments:

    1) Why on Earth is the School of Communications teaching database concepts?

    2) Why does University IT care if you use SQL or Access?

    3) Perhaps University IT cares because it has to run an SQL database server for you. It wants
  • The reason there are not pages comparing is because all access does is make the frontend pretty so you don't have to understand the backend concepts. access is also not really scalable without a backend database (oh.. how about mysql?). SQL can be used to help them understand the base concepts, and let them use access to do quick development/propogation of the database... then make them use PERL to work with the database!!!!!! MUAHAHAHAHAHA
  • by Chacham ( 981 ) *
    Access is OK to teach SQL. However, the multi-user environment, transactions, triggers, and the like are mostly availible in SQL Server. And, if you do any massive updates, don't even think of Access. It just isn't made for that.

    To teach a class, it depends what. If just to teach how to query data, Access is cheaper, quicker, and easier. If you want to learn how to use a database, get SQL Server.
  • One of the problems with school is that it doesn't last long enough to get much real-world experience. Adding Access will give students a vastly accelerated timeframe for experiencing horrible things. For example, if they were to use PostgreSQL, they'd probably never once experience the thrill of data corruption during their learning experience. Introduce Access, and they'll be exposed to a great deal of it.

    As a bonus, perhaps they'll savor the real-world experience of spending $100+ to have Microsoft t
  • And just teach them with Excel. A spreadsheet provides a good visualization of a table, and since you can do multiple sheets, you could have multiple tables. Problem solved.

    If you're even considering Access, this class is obviously not meant to be applicable to real databases anyway, so why make the students do all the extra work. If they ever need to use Access for a real job, they will just treat it like a complicated Excel spreadsheet anyway.

    If anyone complains the curriculum is too simplistic, tell th
  • For teaching about basic database concepts, there is nothing wrong with access. It's cheap and relatively robust for what it is.

  • I work for a fairly large HMO in Boston, won't name any names to protect the guilty here, but I have to say that both SQL DBs and Access DBs are used in production or as front ends.

    For the love of god and all the is good, teach SQL, not Access. Part of my job is to convert all the Access DBs into front ends and the designs that I see every day are nightmare-ish at best. General design concepts and best-particies are not followed at all, and forget about transactional controls or any sort of secuirty.

    I'd
    • Simply because the developers in your org are clueless does not automatically mean that Access is not a viable product. Access makes a very good prototyping tool, and as a front end to a more robust backend. Oracle/SQLServer/whatever.
      Is it easy to screw up? Sure. It makes people think they can build a db app. People who no not understand the actual concepts involved in building a secure, stable app.

      Now what if the power goes out inbetween the steps?
      Now what if the DB is Access?

      Answer: Nothing, if the wh
  • Access has it's pros and cons. As stated in numerous other posts, it's not standard SQL.

    Then again, which complex programs use ONLY standard sql? The vast majority of stuff I've seen uses stored procedures or special functions or special syntaxes (like outer join syntaxes) that are database specific. The difference is that Access is tuned to the small, easy, and simple projects, while others are (necessarily) tuned for performance, scalability, or reliability.

    One very big plus with Access is that it
  • Depends on goal (Score:3, Informative)

    by enigma48 ( 143560 ) * <jeff_new_slash@jeffdom . c om> on Monday December 15, 2003 @12:50AM (#7722284) Journal
    I got part-way some of the higher-rated comments and haven't seen many people talk about a very important point:

    Who's the audience and what's your goal?

    At my university (medium-sized, well-known Canadian) first-year students have three places to 'start' in CS. New to computers, new to programming and some experience programming.

    I've worked with the new to computers crowd, so there is my bias/experience. Database and theory were covered for two weeks in lectures and practical knowledge through three weeks of labs. We used Access - if we didn't, we would have needed triple the time to cover the basic (and maybe a little extra).

    More first-year students take this course than there are CS student in the CS program. Their questions are "What is a primary key and why is it there?" NOT "why doesn't my outer join work?".

    MySQL is not appropriate for this group. Given an entire course of databases, sure, but now you're targetting the CS major/minor crowd. How many arts/science students would take an entire course on DBs compared to a well-rounded, multiple application course?

    Give the minors/majors a real DB. They HAVE to know this stuff at a rudimentary level or their CS degree isn't worth the paper it's printed on. Give the other students a once over with Access, tell them small companies and mom-and-pop stores use it for VERY small installations and point them to the DB course if they want to know more.
  • Microsoft Database Engine is a free limited-connection version of SQL server. It is more scalable than Access, and you can use Enterprise Manager with it. One feature missing from Access is stored procedures (I think), which are essential for proper data layer design. Also, MSDE and SQL server are real server apps, as opposed to Access which is ultimately file-based.
  • by Irvu ( 248207 )

    Is Access a suitable tool for teaching database concepts to students?

    Having used both of them I would say no. Access is a nice front-end and can be used for small databases. But, in order to do anything with it you need to spend a great deal of time learning how to do access-specific things such as forms and so on, all of which exist so that the underlying relational database cen be kept hidden.

    If your goal is to teach the students how to make pretty guis but not understand the basic system, and to loc

  • It all depends on what the course being taught is. If you are teaching computer science, I concur with the "read the writings of C.J.Date before touching a computer" post. If the course is "office automation tools" or somesuch(what is the school of communication, anyway ?), Access is certainly suitable - it's very accesible for non-techies.
    For what it's worth, I think it's a mistake for a University to teach people who are likely to end up in a programming career using Access - any prospective employer will

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Working...