Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Learning SQL on SQL Server 2005 142

Posted by samzenpus from the learn-it dept.
khorner writes "I joined a local XP User Group in May of this year. As the IT Manager of Application Development for a 90+ year old agricultural cooperative, I'm introducing the concepts of agile development and need the support. Right off the bat, we've acquired some review copies of books and I volunteered for the O'Reilly book: Learning SQL on SQL Server 2005. I have been working with various versions of Microsoft SQL Server since 1999, so I figured I could give it a go." Read the rest of Kevin's review.
Learning SQL on SQL Server 2005
author Sikha Saha Bagui & Richard Walsh Earp
pages 325
publisher O'Reilly
rating 4
reviewer Kevin Horner
ISBN 0596102151
summary The organization and inconsistencies take away from the value of the book as a whole


Historically, I've found the O'Reilly books to be great references for professional programmers. I began with David Flanagan's Javascript: The Definitive Guide -- I think it was the 3rd edition. I enjoyed them for their reference value as well as business-oriented examples. Learning SQL on SQL Server 2005 does not, in my opinion, follow the mold I have become accustomed to from O'Reilly.

Learning SQL on SQL Server 2005 covers many of the topics necessary to introduce relational databases to the beginner. It is based on the authors' university course curriculum and it is evident with the review questions including with each chapter.

The authors cover important topics at an adequate depth for its target audience; however the organization needs some work. The first six chapters flip-flop across what I consider to be logical boundaries in a discussion on database development: schema versus data. Tools are a platform dependent subject necessary to discuss implementation.

The database provided could use some refactoring to get to a more cohesive and production level design. Not to be nitpicking, but as an example, equivalent domain level attributes for example, student number, are represented across tables as different column names. This is the attention to detail that drives me nuts on the professional level.

Chapter 1 sets the tone by touching multiple concepts and incorporates a smothering of screenshots. Over the first 25 pages (half being images and query result tables) we load the demo database, modify it, select from it, and cover to the Management Studio's syntax color coding and customization. Quite a lot to start off with for a novice, all with the assumption MS SQL 2005 is installed and ready to go.

Chapter 2 jumps into simple data selection of a single table and briefly hits the new MS SQL 2005 concept of synonyms.

Chapter 3 tries to focus on the schema oriented topic of table creation but falls short when jumping over to data topics like INSERT, UPDATE and DELETE. There is good coverage of data types, but we don't cover any design concepts of why we create tables and considerations for doing so. To the authors' defense, they state this is not a book on theory, but I think some level of theory is an important aspect to learn SQL.

Chapter 4 introduces the data selection concept of table joins and to do so, introduces the schema concept of keys.

Chapter 5 provides good coverage on internal functions for strings and dates and sets the foundation for more advanced queries.

Chapter 6 takes the reader through a logical process of developing a complex query. This is a good example process of taking a simple query and developing it further to satisfy a business need. Unfortunately, we experience some more inconsistency when we develop a join query using the WHERE clause - an inefficient and undesirable method the authors' discussed in chapter 4. Again, we jump from data concepts to schemas when we hit views and temp tables.

Chapter 7 through 10 present set operations, sub queries, and aggregate functions in a progressively logical manner. It would have been nice to have this progression prior to Chapter 6 and incorporate the concepts in the query development.

Chapter 11 throws in a thin coat of an introduction to table indexes and constraints: the final jump across topics.

Overall, the book provides an introduction to SQL topics. In my opinion, the organization and inconsistencies take away from the value of the book as a whole. If SQL is your profession (or you want it to be), with a list price of $44.99, Celko's SQL for Smarties is the better investment.

You can purchase Learning SQL on SQL Server 2005 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Learning SQL on SQL Server 2005 More

Learning SQL on SQL Server 2005

Comments Filter:

  • You poor soul. (Score:5, Funny)

    by Anonymous Coward on Monday July 24, 2006 @04:12PM (#15772053)
    I joined a local XP User Group in May of this year.

    Desperation leads some people to do strange things.

    • Umm, he could mean Extreme Programming... we could only hope.
      • Hmm, I don't know which is worse: Windows XP or the stupid buzzword-inspired fad known as Extreme Programming (with an X for the acronym to make it sound cooler and eXtremer!). Thank god I've never worked somewhere that forces people to use this abomination.
        • It depends on how seriously you take XP. At its core, XP is mostly good advice, and you'd be surprised how many companies need their relatively simple advice. However, there are a lot of small minds who make it into a religion in place of thinking for themselves.

          I went to an interview a few months ago and the place told me, "We tried XP but we like scrumm better because XP's cycle times are too short." A statement I found incredible because they clearly had missed the entire point of a methodology in t

      • Indeed, he meant Extreme Programming. I know, because I'm the one who receives and distributes the books for the group (and if anyone is in the Columbia, MO area, the mailing list is here [yahoo.com]).

        And for the poster who thinks XP is just a buzzword - I'm at Agile 2006 [agile2006.com] right now with over 1100 people from companies ranging from Microsoft, Mozilla and Progressive Insurance to Shure (the microphone people), Seagate and lots of overseas companies. XP [xprogramming.org] is alive and well (if arguably poorly named) and in a lot more plac

    • I think he's in desperate need of this:

      SQL on Rails [sqlonrails.org]

      • Nice of you promoting something requiring MySQL in a Microsoft SQL Server 2005 related article.

        Do you see me going around MySQL & PHP related threads promoting ASP.NET & MSSQL? No? There is a reason for it, you know. Its because it would be unwanted and unuseful zealotry.

        So... Why isn't parent mod'ed off-topic yet?

        • Wait...

          Did you think this was a *real* product? Yes? There's obviously a reason for that, too -- ignorance.

          This site is a spoof, making light-hearted fun of Ruby on Rails, Web 2.0, et cetera. The part of the joke is that you shouldn't need any specific database in a real agile environment. Then again, jokes that are over-explained wind up being less funny.

          I'm more of a Postgres guy, anyway, and I think PHP is the spawn of the devil. If you're interested in understanding, do a quick comparison of the

    • That elitist attitude does not look good on you. I do have to be honest though, I did cringe a little inside when I read that :( Does that make me an elitist bastard too?
      • It's a reaction similar to the one that happens when you think that one program/environment "stole" another's feature. Yes, it's a cheap shot to ridicule MS because some of its users reach the same conclusion (and even cast it in the same image) that Unix and original PC users reached decades ago. Oh well...

    • that's what I thought (Score:4, Insightful)

      by garyrich ( 30652 ) on Monday July 24, 2006 @04:51PM (#15772301) Homepage Journal
      when he said this:

      " have been working with various versions of Microsoft SQL Server since 1999"

      Man... talk about Microsoft winning the marketing war even when the tech is 3rd rate.

      Also also question the need for a book on leaning sql that is specific to that bastard version of Sybase that Microsoft sells (the real answer is that PHBs typically sign off on book buys). Sql is sql, stuff that you have to code specific to any particuloar RDBMS is not sql, or at least not standard sql. Why not teach people standard sql before giving them the nonstandard exceptions for "Microsoft SQL Server" or Oracle for that matter? Or just title the book "How to write queries for MS SQL Server 2005"?

      The answer probably is that you can't fill a book with "Learning SQL", there just isn't that much to it.
      • Your comment is way off. All of the database varieties I've worked with have differences in their SQL syntax. I actually have an O'Reilly book that details commands for Oracle, MS SQL, and mySql. Pretty much every command has differences depending on which database version you're using. It's kind of like CSS... in a perfect world every browser would follow the standard exactly, but not a single one actually does in real life.

        The thing is, if someone learns one variety of SQL, they're going to be able to
        • They all have "enhancements" to standard sql. Some good, some bad like all things. IF you write basic ansi89 sql it will work on all 3 of the databases you mention - admittedly not optimally and once in a great while not at all. When I did this for a living I typically used the Perl DBI, wrote simple sql queries and used perl to do things that are a pain in the ass to do in in proprietary sql variants - or worse - Oracle PL/SQL (if I say PL/SQL sucks that make me not a pure MS hater?).

          If you learn one dia

    • I joined a local XP User Group in May of this year.

      Desperation leads some people to do strange things.

      I read that more along the lines of a meth users group. The kind where you have to stand up at the first meeting and admit in front of everyone, "my name is Kevin, and I'm a Windows XP user."
    • Wait a minute ... the quote as I know it:
      Greed makes people do strange things ... - Lucy
      Reinier (know thy classics)
    • Given the bizarre additions; arbitrary constructs; and the non-ANSI (e.g. "illegal") prefetch semantics, well, whatever you end up learning it won't do you a wet-slapp of good if you eventually run up against an actual SQL environment.

      [And, yes, this is a little bit of a troll. But having been given the task of trying to "port" a database designed in SQL Server and having discovered just how non-portable it was, I am a tad jaded... 8-)]

  • SQL apis suck. (Score:2, Interesting)

    by aersixb9 ( 267695 )
    Why does the API for the databases suck so much? I've been using ADO.net with C# .NET 2.0 on SQL 2005, and why must I use the arcane and shitty SQL language to save my web objects in a datafile? Isn't there an option somewhere between writing 25 lines of SQL code for each action for each object (either in code or in a SPROC), and managing the files myself on the local HD, which most webhosts won't allow? How about a nice simple DBObject that my other objects can inherit from, that provides a nice 'SaveAllIn
    • have you looked at Strongly Typed Datasets?

      personally I don't generally like prepacked stuff at that level, since most complex systems aren't just simple CRUD operations.

      But if that's all you need it's pretty much out of the box.


      • I just want to save my customer's orders and messages, then load them. Why must this be so complicated??? In the old days, before we had these fancy 'shared webhosts', I could simply create an 'order' object, with fields such as price, shipping address, billing info, etc (floats and strings), then...uh...I guess in the old days I had to streamwriter(price);streamwriter(shipping);stream w riter(billing), etc, for each object, which kind of sucked when I made changes to the object's variables...the same is tru

        • Re:SQL apis suck. (Score:5, Informative)

          by CastrTroy ( 595695 ) on Monday July 24, 2006 @04:42PM (#15772249)
          It's called a database abstraction layer. You have to build your own objects that support saving themselves to the database. It's not as much work as it sounds like, and will actually save you a lot of trouble in the long run.
          • I'll second that. Take a look at the best practices/etc. examples that MS puts on the web. They usually have a database access and a business logic layer. If you have a single source of data and a number of application that depend on it (like a visualization, bookkeeping and a numerical numerical analysis app like we had), it is certainly the way to go. Just be careful when you are using vendor specific features or syntax in your stored procedures, or be prepared to code the differences into your DB layer
        • Look into Hibernate [hibernate.org]. It's an open source OR-mapping tool. I've never used it with .NET, but I've used it with Java and it does a great job of abstracting out all of those SQL queries and lets you just save an object to the database. I think the .NET version is called NHibernate.
          • Also take a look at db4o [db4o.com], which gives you dead-simple object persistence without the rdbms underneath. Makes perfect sense when you're not actually using relational data, just storing objects (like 99% of rails-type apps do). As a bonus, it can replicate to Hibernate, which is perfect for reporting and data mining (personally I'd just cut the middleman and use Hibernate on both ends, but their replication is designed more for lots of small cache clients pushing changes into a bigger db).
        • Trust me, strongly typed datasets sound exactly like what you want. It's mostly auto-generated stuff, so you don't have to write all that stuff yourself. Still, they're not perfect. My company wrote this great layer over top strongly typed datasets, and when I want to save or load an object, I basically don't have to write any additional code. Simple templates exist for creating new types... just point at the database table, push a button, and boom, all the properties are generated and written for me.
        • What you want is an Object Relational Mapping Layer and generator.
          For the .NET framework or MONO try dOOdads with MyGeneration. It is free. Don't let the names fool you. That is some enterprise quality software.
          You get support for 12 databases and get to write code like this without having to write config files or xml definitions.

          // Load and Save
          Employees emps = new Employees();
          if(emps.LoadByPrimaryKey(42))
          {
          emps.LastName = "Just Got Married";
          emps.Save();
          }

          // Add a new record
          Employees em
      • This is what I hate about database programming. You have to look at STDs and operate with CRUD all day.

    • Re:SQL apis suck. (Score:1, Informative)

      by Anonymous Coward
      Check out object relational mappers. nHibernate (.NET version of Java's Hibernate) comes to mind.

    • Re:SQL apis suck. (Score:3, Informative)

      by Kunta Kinte ( 323399 )

      ...why must I use the arcane and shitty SQL language to save my web objects in a datafile?

      Because you are retrieving the data from an SQL Database?

      As others have pointed out, there are many ways to do this. Another method that may work for you, depending on your situation, is the server's XML capabilities, eg. "SELECT ... FOR XML ..." will convert your dataset to XML that you can easily serialize.

      • Re:SQL apis suck. (Score:5, Funny)

        by computational super ( 740265 ) on Monday July 24, 2006 @05:25PM (#15772529)
        the server's XML capabilities, eg. "SELECT ... FOR XML ..." will convert your dataset to XML

        Ah, good. I've been waiting for a long time for somebody to relieve me from the mind-boggling complexity of inner joins, subselects, triggers, referential integrity rules and stored procedures by adding DOM, XSLT, XPath, DTD and XmlSchema on top of inner joins, subselects, triggers, referential integrity rules and stored procedures.

    • Re:SQL apis suck. (Score:3, Informative)

      by killjoe ( 766577 )
      Microsoft is philosophically opposed to ORM layers. That's why they have never provided one with ODBC, ADO, DMO, .NET or whatever TLA they ever came out with. MS believes that you should use stored procs for pretty much everything. For example when they re-did petshop they loaded the entire thing with stored procs because it provided faster performance.

      • Actually MS is getting ready to introduce something very much like an ORM layer called LINQ/DLINQ. You can find out more here: http://msdn.microsoft.com/data/ref/linq/ [microsoft.com]
        • Wow that's amazing. Here it is the year 2006 and they are finally getting ready to introduce "something that's very much like an ORM layer". Where were they for the last decade?

          From looking at the descriptions it seems like a typical MS project. Too complicated for it's own good, trying to produce a tool that will solve every problem known to mankind.

          BTW if you know anybody on this team could you please urge them write real error messages? I work with SQL server every day and I curse the team every time I g
          • Comment removed based on user account deletion
          • Interesting... Oracle does the same thing. I guess when you have gotten fat charging obscene prices for cookie-cutter software you tend to lose focus on the little things, like helpful error messages. This is one of the main reasons I hate PL/SQL and T-SQL - debugging them is painful.
          • Amen brother. I just had another one of those today. It took hours for me to track down the problem, when it could have and should have not only told me what column (or even row) it was having problems with, and what constrataint it was having problems with. The error message reached a great new level of vagueness (paraphrasing here, but something like "a row or rows has a column that violates a uniqueness or not-null constrant or foreign key constraint"... I mean COME ON, you can't tell me which exactly
      • > Microsoft is philosophically opposed to ORM layers

        They are? And what exactly are the strongly type dataset with TableAdapers in ADO.NET 2.0? Smells like ORM stuff to me.
      • That may be changing. Check out their recent webcast on the upcoming "ADO Entity Objects Framework," [msdn.com] which looks like it's shaping up to be a formal ORM product.
    • Hmmmm...
      Go check out OPENXML in the BOL. SQL Server allows you to send an XML string, shred it, store it in temp tables and in the end process it into the database without having to write multiple insert statements. You can move up and down the XML tree storing multiple transactions and additional datapoints as needed for instance an order and all its associated items as one XML string sent to SQL Server which then processes it. Since I do not come from the programming side of the tracks (DBA / SQL programm

      • To be honest, I don't think using any of SQL Servers XML-features will make anyone's life any simpler, at least not in 99% of the cases.

        T-SQL is a language designed for set-based operations, not fine detail-level data-shredding. Yes, it can be done. No, it doesn't look pretty.

    • It is a full-featured and low-overhead ORM. Go to http://www.hibernate.org [hibernate.org] and check out the NHibernate link.

      Plus, there are several books avilable from, e.g., O'Reilly [oreilly.com], Manning [manning.com].
    • I think the main problem for you is that SQL and relational databases were designed to store relational database data, not be a persistant store for objects. Indeed if you use a database as it was designed to be used, SQL is highly appropriate as a query language.

      I think Microsoft is correct, as stated in another post, that ORM is inherently flawed. It may be the best thing we have, but shoe-horning database data into classes and vice versa is problematic. The time it takes to mess with Java's XML mappin

    • Re:SQL apis suck. (Score:2, Interesting)

      by eggsovereasy ( 573119 )
      How about you write a stored procedure to update your "Order" object (or whatever), then put a method in your Order class that calls said stored procedure then you just.. Order.X = X; Order.Y = Y; Order.Z = Z; Order.Update(); And its done. You write one stored procedure and the one method in Order and you can update everywhere easily.

    • Isn't there an option somewhere between writing 25 lines of SQL code for each action for each object (either in code or in a SPROC), and managing the files myself on the local HD, which most webhosts won't allow? How about a nice simple DBObject that my other objects can inherit from, that provides a nice 'SaveAllInTable(String table)' method, that replaces the INSERT INTO VALUE for each )*(&%# variable in my object?

      That what ORM classes do.... ActiveRecord works great in RoR.

    • The problem with your concept is that the application has no concept of the format of the table(s); if it did, it would have no idea what you want to do with it. Most SQL databases are not object-relational databases (Postgres is), and thus have no way to hold advanced concepts on their own. As such, you are required to break your relations down into normalised forms on your own, and write the appropriate INSERT or UPDATE statements for each.

      The 'obvious' solution is to write this code once for your object
    • If there's a single example of Microsoft innovation to point out it'd be LINQ.

      Check it out: http://msdn.microsoft.com/data/ref/linq/ [microsoft.com]

      The cool thing is that the query language can be adapted to ANYTHING, even Reflection.

    • Re:SQL apis suck. (Score:5, Interesting)

      by Jerf ( 17166 ) on Monday July 24, 2006 @05:13PM (#15772438) Journal
      Why does the API for the databases suck so much?
      SQL is now my canonical example of a "Good Enough" technology, which holds back any sort of improvement because there's no fast and easy way to make something immediately obviously better, even though it'd probably be really easy to make something that would be better over the medium or long term. Unfortunately, new technology needs that snappy I couldn't do that before! demo to really take off. (Most recent example: Ruby on Rails. And I say that as someone who isn't really a Ruby fan.)

      The beginnings of SQL date back to the 1970s, and even in modern times it shows. People hadn't yet figured out how to deal with "NULL"s in any reasonable manner, and SQL has the dumbest NULL in any language I know of that is still in common use. People still thought empty lists were something exceptional, so "SomethingID IN ()" is an error, at least in the DBs I use, instead of a clause so obviously false the optimizer ought to positively jump for joy when it sees it. The syntax is fruity and unforgiving by modern standards, and the actual relational stuff that is supposed to underlie it all continues to be masked by the performance limitations in place in the 1970s; performance hacks now enshrined as the One Right Way to do things.

      SQL sucks, because so much effort has been invested into it that no possible fix to it could ever get traction, and SQL is so wrong that trying to bend your new system to be backwards compatible with it will probably break your new system. The only hope we have is a brand new paradigm, and frankly those haven't been faring too well either, so far. But hope springs eternal.

      Someday this mess will be resolved, but your guess is as good as mine as to which direction it's going to come from. SQL-the-language sucks, but it still manages to set the bar pretty high for any sort of technology to replace it, even just as a language-switchout on an existing DB server. (I mean something actually not SQL, not SQL adapted to Yet Another Procedure Language or SQL adapted with Yet Another Proprietary Extension.)
      • Since the 1970's there have been 1000's of PhD's in "databases", and 1000's of academic careers, syposiums, journals editions, etc.. in "databases", and I'm sure that most of these haven't been to do with SQL, yet SQL is still the industry standard.

        As you say...SQL is now my canonical example of a "Good Enough" technology, which holds back any sort of improvement because there's no fast and easy way to make something immediately obviously better,
      • Bravo,Here Here, I wish I hd said it as succinctly as you, I never get past I Hate SQL simply because it is an abomination.
    • In PHP, I've taken to using a database purely as a persistent store. A few hundred lines of reflective code to ascertain the data model and generate the SQL for it has now saved me weeks of work across many applications.

      The trouble with it is generic code of that nature doesn't scale especially well. To make it scale, you lose the reflection, which pushed you right back to 25-lines of SQL to a model.

      Personally, I'd rather save that time during initial development and then re-visit it later in the production

    • Re:SQL apis suck. (Score:2, Interesting)

      by dividius ( 693179 )
      "why must I use the arcane and shitty SQL language to save my web objects in a datafile"

      - You musn't, get one of the half-dozen ORM's people have built for you. Some are even *gasp* open source. *Shhhhhh, don't tell anyone.

      "the datatable and datagrid isn't useful for anything more than displaying a raw table, something that a webapp usually shouldn't do, anyways"

      - Um... a brochure-ware web site doesn't usually, but a web app??!? I'm thinking... a table showing shopping cart items, a table showi
    • It's not the API. It's the programmer ...
    • Unless there's a good C# SQL wrapper that I don't know about

      The Entity Framework in ADO.Net 3.0 combined with Language INtegrated query (Linq) C# language extensions is going to change how you write data based applications. Dispite my obvious bias this is one of the coolest things I've seen in quite a while.

      LINQ and ADO.NET Entities: Video Podcast
      http://channel9.msdn.com/Showpost.aspx?postid=202 1 38 [msdn.com]
      Whitepaper:
      http://msdn.microsoft.com/vstudio/default.aspx?pul l=/library/en-us/dnvs05/html/nxtgenda [microsoft.com]

    • Well, almighty you, you may have identified a need there. So, tell you what, instead of getting on your bitch-wagon, sit down, write a new access layer, and make it easier for folks.

      I've noted that 2005 contains a number of solutions that 3rd party's developed to ease the way on 2000.

      VS2005 contains a lot of ideas that 3rd party's came up with, and were paid handsomely for. An aquaintence made a bundle when MS bought him off. He's a self-employed consultant now.

      ...I'm sorry, did that sound good? Or, was

    • Comment removed based on user account deletion

    • How about a nice simple DBObject that my other objects can inherit from

      In SQL Server 2005 you can use .NET classes as datatypes in the DB, and then just pump your objects directly into the DB. Not that I would ever recommend it though. But it can be done.

      Or you could, as others have suggested, use strongly typed datasets. If you are writing lots of manual queries in C# when using ADO.NET, you are probably doing something wrong.

  • What vendor? (Score:2, Funny)

    by GigsVT ( 208848 )
    Many different vendors make DBMS services that speak SQL.... What product is this talking about?

  • Wow (Score:1, Troll)

    by FrostedWheat ( 172733 )
    There are local XP user groups?
    • When they use the word "groups" they really mean small gatherings of one person or less. This avoids any embarrassment.

  • First in a series (Score:5, Funny)

    by DysenteryInTheRanks ( 902824 ) on Monday July 24, 2006 @04:51PM (#15772306) Homepage
    Also coming soon from O'Reilly:

    • Learning HTML from Microsoft Word,
    • Learning CSS from IE
    • Learning Anger Management from Steve Ballmer
    • Fact Checking 101 from the Operators of Slashdot.org
    • Data Integrity for Dummies With MySQL 1.0
    • XBox Manager on How to Make a Profi ...
    ... aghhhhh, forget it, the sport has gone completely out of it ... wake me up when these completely counterintuitive books/articles stop appearing ...

    (lapses into never-ending coma)

    • wake me up when these completely counterintuitive books/articles stop appearing

      Ahhhhhhh, you seem a perfect candidate for our Mission to Alpha Centauri Project.

      Allow me to show you the technical details of our MTSOTBD (Monkeys Throwing Shit Out The Back Drive).

      KFG
    • Your CSS from IE and HTML from Word certainly raise a smile and is worth a mod point or two, but there is nothing wrong with the MS implementation of SQL, and SQL Server generally is a rock solid, highly complient, database.

      MS may be fairly knocked for much, nae most, of their offerings, but SQL Server is a gem. I know it must have been tempting to do the standard MS knocking, but frankly in this case all you do is show yourself up as an utter eejit.
      • SQL Server is a gem?

        Maybe you should ask the russians [prometeus.nsc.ru] about that.
    • The first two I thought were real books ( I think I have seen those in local bookstore), but the Anger Management was too much to bulieve.
    • .. aghhhhh, forget it, the sport has gone completely out of it ... wake me up when these completely counterintuitive books/articles stop appearing ...

      You're too humble. And this is too funny.

      My contributions:

      • Shell Programming using CMD.EXE
      • Systems Administration with vbscript
      • Hacking The Start Menu
      • Vista Performance Tuning
      • The Registry is Your Friend

  • SQL server 2005 tools much improved (Score:3, Interesting)

    by hguorbray ( 967940 ) on Monday July 24, 2006 @05:42PM (#15772625)
    While still behind Oracle in many other ways, SQL server 2005 does boast a nicely remade user tools in Management Studio.

    I took MS-SQL classes back to back earlier this year with the first one using SQL server 2003 and the 2nd one using 2005 express and the difference was night and day in ease of use.

    In 2003 you had to have 2 or 3 different applications up in order to create a table, populate it with data and then view the table data. I was constantly trying to do things in the window which didn't allow that action....Plus transact SQL was like an (even more) retarded version of SQL+

    With Management Express it can all be done from the main window -I just wonder why it took them 10 years to figure this out.

    there are still some funky aspects of MS-SQL language itself (the GO directive for instance), but this is a great new tool.

    Of course now that TOAD works on MS-SQL this may not matter much to database diehards, but I do see signs of Microsoft improving GUIs, simplifying designs and improving usability both here and in VisualStudio.

    Too bad they won't be able to do the same for Vista.....

    What's the speed of dark?

    • Re:SQL server 2005 tools much improved (Score:1, Informative)

      by Anonymous Coward
      "Of course now that TOAD works on MS-SQL this may not matter much to database diehards, but I do see signs of Microsoft improving GUIs, simplifying designs and improving usability both here and in VisualStudio"

      I've tried TOAD, and honestly it is not worth nearly the amount they charge ($470 per seat or $3445 for their server suite).

    • First of all - there was no SQL Server 2003.
      Perhaps you're talking about Visual Studio.NET 2003?

      "In 2003 you had to have 2 or 3 different applications up in order to create a table, populate it with data and then view the table data."

      With the MS SQL Server Enterprise Manager (comes with MS SQL Server 2000 - it's part of the client tools on the install CD), you can perform almost any action on the server - from creating databases, tables, views, users, through to all the scheduling, full-text index setup, et
      • "The biggest advantage for SQL Server is that they ship Enterprise Manager in the box.
        It makes help and maintaining a db (to a point) fairly painless, and helps to flatten the learning curve"

        Couldn't agree more. Any non-moron programmer or IT person can do even "complex" tasks with almost no learning curve thanks to enterprise manager. It is the one thing that that makes sql server better than another of it's competitors. They got enterprise manager "right" from the start and is probably a BIG reason for
    • FYI: the "GO" command isn't part of the T-SQL language. it's a special pseudo-command used by the tools & APIs to separate batches of T-SQL statements.

    • Re:SQL server 2005 tools much improved (Score:4, Insightful)

      by dcam ( 615646 ) <david AT uberconcept DOT com> on Tuesday July 25, 2006 @01:04AM (#15774008) Homepage
      I took MS-SQL classes back to back earlier this year with the first one using SQL server 2003...

      There is no SQL Server 2003. There is SQL Server 2000.

      In 2003 you had to have 2 or 3 different applications up in order to create a table, populate it with data and then view the table data.

      Learn SQL and use Query Analyzer (QA). Seriously, most SQL Server admin and management should be done in QA.

      I was constantly trying to do things in the window which didn't allow that action....Plus transact SQL was like an (even more) retarded version of SQL+

      s/retarded/standards compliant/

  • not a review (Score:3, Funny)

    by glwtta ( 532858 ) on Monday July 24, 2006 @06:11PM (#15772757) Homepage
    Reviews provide information about the content of the book beyond the sequence of chapters. The above is called a Table of Contents.

Slashdot Top Deals

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Close