Loading ...
Sorry, an error occurred while loading the content.

RE: [agileDatabases] No Sql movement impact

Expand Messages
  • Scott Ross
    I don t think we are talking about the same thing. My point was, that in general, its much easier to find personnel that have experience in RDBMS (Oracle, SQL
    Message 1 of 11 , Feb 28, 2010
    • 0 Attachment
      I don't think we are talking about the same thing.

      My point was, that in general, its much easier to find personnel that have experience in RDBMS (Oracle, SQL Server, Postgresql, mysql, take your pick) then any of the nosql resources. For the business point of view for an enterprise application, it is very important not to tie yourself to one group of individuals. Hence, that was my point with that comment.

      -Sr
      ________________________________________
      From: agileDatabases@yahoogroups.com [agileDatabases@yahoogroups.com] On Behalf Of Curt Sampson [cjs@...]
      Sent: Sunday, February 28, 2010 1:48 AM
      To: agileDatabases@yahoogroups.com
      Subject: Re: [agileDatabases] No Sql movement impact

      On 2010-02-27 12:30 -0500 (Sat), Scott Ross wrote:

      > I don't see how you can ignore the most obvious issue: Support.

      Support doesn't necessarily need tools from others. My best-supported
      RDBMS is in fact one I wrote myself.

      Basically, if you can fix it yourself or know where to go to find someone
      to fix it, you generally don't have a support problem.

      Otherwise you do have a support problem, and it won't go away by paying
      someone else for some software or a support contract. There's no
      guarantee that they can fix your problem, either.

      This is part of the reason for the popularity of open source in some
      areas: if you have the ability to fix a broken piece of software
      yourself, going with a closed-source vendor may give you worse support
      because they may reduce or remove that ability.

      As one example, an obscure bit of profiling-related functionality in the
      runtime system of a compiler I use was broken when it was introduced.
      Because it's open source, I managed to fix the problem in a day or two
      and carry on with my work. Had I not done this, I'd still be waiting for
      the next release, and there's no certainty that even then it would have
      the fix. The latter sort of situation can play havoc with your business
      plans.

      cjs
      --
      Curt Sampson <cjs@...<mailto:cjs%40cynic.net>> +81 90 7737 2974
      http://www.starling-software.com
      The power of accurate observation is commonly called cynicism
      by those who have not got it. --George Bernard Shaw
    • Curt Sampson
      ... Ah, we weren t. However, I d disagree with your point even there: having more people available who know Oracle well won t help you very much if your
      Message 2 of 11 , Mar 1, 2010
      • 0 Attachment
        On 2010-02-28 18:55 -0500 (Sun), Scott Ross wrote:

        > I don't think we are talking about the same thing.
        >
        > My point was, that in general, its much easier to find personnel that
        > have experience in RDBMS....

        Ah, we weren't.

        However, I'd disagree with your point even there: having more people
        available who know Oracle well won't help you very much if your massive
        application collapsing because Oracle just isn't the right tool for that
        sort of load.

        Keep in mind, many of these tools were developed because the application
        someone was building just wasn't well suited to Oracle (or whatever).
        I've designed and built a few custom DBMS systems myself for just that
        reason.

        Also, keep in mind that when you have someone who's not had a huge
        amount of experience with a particular product, but has excellent
        general knowledge of the product area (such as DBMSs), you still have
        a lot of experience to draw on. Sure, he won't know that for version 7
        under certain types of load you must never set the frozzstat to a value
        between 3.5 and 4.5 because it triggers a bug in the software, but after
        very little study he'll certainly understand the general I/O properties
        of the system, how to design a good configuration of disks and disk
        arrays to support that, and that sort of thing.

        You're better off with someone with excellent general knowledge but
        little product-specific knowledge than you are the other way around.

        > For the business point of view for an enterprise application, it is
        > very important not to tie yourself to one group of individuals.

        That, I thoroughly agree with, which is why I tend to prefer open-source
        products when they're available and can do the job. I'm surprised I have
        any hair left, with the amount that vendors have made me tear out.

        cjs
        --
        Curt Sampson <cjs@...> +81 90 7737 2974
        http://www.starling-software.com
        The power of accurate observation is commonly called cynicism
        by those who have not got it. --George Bernard Shaw
      • Willem Bogaerts
        ... If I look at the definitions found on the net, NoSQL seems to be defined as non-relational. I migrated from MS-Access 97 (don t laugh) to SQL databases.
        Message 3 of 11 , Mar 1, 2010
        • 0 Attachment
          > Has anyone moved their database from an RDBMS to a NoSQL data store
          > (MongoDB, CouchDB, Neo4J etc)?
          > if you are doing agile development with these databases what experiences do
          > you have?

          If I look at the definitions found on the net, "NoSQL" seems to be
          defined as non-relational. I migrated from MS-Access 97 (don't laugh) to
          SQL databases. So, in a way, I migrated the other way around.

          Yes, MS-Access 97 to SQL databases. I am fully aware that you can drive
          MS-Access with SQL as well, but we did not do that, and for a good reason.

          MS-Access (better said, the Jet Engine which does the work) had some
          fairly low-level interfaces that allow you to program almost the
          filesystem itself in a nice object-oriented way. Just open a recordset,
          state which index you want and which value and you get a record. You can
          then optionally edit it and issue the "store" method. It is super-fast,
          as no SQL needs to be parsed, no server to be emulated and even for
          database files on the network, fast file operations are used under the hood.

          For object-oriented programming, I always loved this programming style
          (which is also called ISAM style). It is by way clearer than writing a
          program at runtime in SQL and handing it to a database. It still feel
          like I have to drive the database in a foreign language and still miss
          the good old object-oriented interface. Even though I use libraries that
          encapsulate the whole SQL thing.

          Off course, the result that I got with with the ISAM style way of
          programming was exactly the same as I could have got with SQL:
          relational, organized in tables and records. So I do not know if the
          ISAM-style of programming counts as "NoSQL". It does not use SQL, but it
          is still relational.

          Best regards,
          Willem Bogaerts.
        • Curt Sampson
          ... Well, I m not sure it would be defined as that if a few gaping holes in the products out there were filled. I have a system optimized for logging large
          Message 4 of 11 , Mar 1, 2010
          • 0 Attachment
            On 2010-03-01 13:12 +0100 (Mon), Willem Bogaerts wrote:

            > If I look at the definitions found on the net, "NoSQL" seems to be
            > defined as non-relational.

            Well, I'm not sure it would be defined as that if a few gaping holes
            in the products out there were filled. I have a system optimized for
            logging large amounts of information--tuples and their metadata are
            written to the disk in linear order, with no attempt made (at the time
            of writing) to index them in any way. Essentially, it's just writing
            a straight transaction log. There's also no SQL involved. This would
            probably fall under the "NoSQL" umbrella, despite the fact that it is
            relational, in many ways.

            I think that what NoSQL reall means is, "a DBMS that's not designed in
            the same general style as Oracle, Sybase, MS SQL Server, Postgres, and
            so on."

            I suspect it's becoming popular amongst a certain crowd because they're
            realizing that MySQL was entirely the wrong tool for what they wanted to
            do.

            (Most likely they picked it originally not because they had any idea
            what they were doing, but because "that's what everybody used." In other
            words, it was all cargo-cult IT.

            (Consider the typical usage pattern. You take an IASM engine, put a
            layer over top of it to make it look sort of relational, and then put
            a query optimizer and SQL parser on top of that. This gives you MySQL.
            You then access it with an "O-R layer" that converts this, essentially,
            back into the IASM system that was underneath all of that anyway. What a
            tremendous waste of effort and computing cycles!)

            cjs
            --
            Curt Sampson <cjs@...> +81 90 7737 2974
            http://www.starling-software.com
            The power of accurate observation is commonly called cynicism
            by those who have not got it. --George Bernard Shaw
          • Scott Ross
            I agree that you should apply the best tool for the job, and I absolutely understand that most shops blindly choose their data store based on the current
            Message 5 of 11 , Mar 1, 2010
            • 0 Attachment
              I agree that you should apply the best tool for the job, and I absolutely understand that most shops blindly choose their data store based on the current infrastructure (if they are a sql shop, everything goes in sql. If they are an oracle shop, everything in oracle). It's a shame that most shops make decisions not at a project/product level, but at a higher level with blind assumption that everything is the same. This leads to many applications that's just don't fit.

              My only other comment is that when choosing any tool (dbms in this case), you need to not only evaluate if it fits the current project, but future maintainability including the personnel (community) available to support it.

              To that end, I think we are essentially saying the same thing - just with a varying degree of difference.

              Great discussion though.

              --
              Scott Ross
              Programmer Analyst


              From: agileDatabases@yahoogroups.com [mailto:agileDatabases@yahoogroups.com] On Behalf Of Curt Sampson
              Sent: Monday, March 01, 2010 3:46 AM
              To: agileDatabases@yahoogroups.com
              Subject: Re: [agileDatabases] No Sql movement impact



              On 2010-02-28 18:55 -0500 (Sun), Scott Ross wrote:

              > I don't think we are talking about the same thing.
              >
              > My point was, that in general, its much easier to find personnel that
              > have experience in RDBMS....

              Ah, we weren't.

              However, I'd disagree with your point even there: having more people
              available who know Oracle well won't help you very much if your massive
              application collapsing because Oracle just isn't the right tool for that
              sort of load.

              Keep in mind, many of these tools were developed because the application
              someone was building just wasn't well suited to Oracle (or whatever).
              I've designed and built a few custom DBMS systems myself for just that
              reason.

              Also, keep in mind that when you have someone who's not had a huge
              amount of experience with a particular product, but has excellent
              general knowledge of the product area (such as DBMSs), you still have
              a lot of experience to draw on. Sure, he won't know that for version 7
              under certain types of load you must never set the frozzstat to a value
              between 3.5 and 4.5 because it triggers a bug in the software, but after
              very little study he'll certainly understand the general I/O properties
              of the system, how to design a good configuration of disks and disk
              arrays to support that, and that sort of thing.

              You're better off with someone with excellent general knowledge but
              little product-specific knowledge than you are the other way around.

              > For the business point of view for an enterprise application, it is
              > very important not to tie yourself to one group of individuals.

              That, I thoroughly agree with, which is why I tend to prefer open-source
              products when they're available and can do the job. I'm surprised I have
              any hair left, with the amount that vendors have made me tear out.

              cjs
              --
              Curt Sampson <cjs@...<mailto:cjs%40cynic.net>> +81 90 7737 2974
              http://www.starling-software.com
              The power of accurate observation is commonly called cynicism
              by those who have not got it. --George Bernard Shaw



              [Non-text portions of this message have been removed]
            Your message has been successfully submitted and would be delivered to recipients shortly.