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

save my JSON

Expand Messages
  • Mark Ireland
    Is storing a JSON string in a database: A: a crap idea. period. B: a crap idea under most common circumstances C: pure genius Thanks. You ve been helpful.
    Message 1 of 6 , Apr 14, 2008
    • 0 Attachment
      Is storing a JSON string in a database:

      A: a crap idea. period.
      B: a crap idea under most common circumstances
      C: pure genius

      Thanks. You've been helpful.

      _________________________________________________________________
      It's simple! Sell your car for just $30 at CarPoint.com.au
      http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT

      [Non-text portions of this message have been removed]
    • Tatu Saloranta
      ... (d) None of above. You are welcome, -+ Tatu +-
      Message 2 of 6 , Apr 14, 2008
      • 0 Attachment
        On Mon, Apr 14, 2008 at 9:44 PM, Mark Ireland <markincuba@...> wrote:
        >
        > Is storing a JSON string in a database:
        >
        > A: a crap idea. period.
        > B: a crap idea under most common circumstances
        > C: pure genius
        >
        > Thanks. You've been helpful.

        (d) None of above.

        You are welcome,

        -+ Tatu +-
      • kriszyp
        The major problem with storing raw JSON strings in a database is that you lose any structural meaning of the JSON data, you can t do relevant queries that
        Message 3 of 6 , Apr 14, 2008
        • 0 Attachment
          The major problem with storing raw JSON strings in a database is that
          you lose any structural meaning of the JSON data, you can't do
          relevant queries that involve looking at properties of the JSON
          objects and structures. Forgive me for plugging my stuff, but... If
          you are interested in storing JSON data in a database, you should take
          a look at my project, Persevere
          (http://code.google.com/p/persevere-framework/). It works with a
          RESTful JSON interface. Persevere stores the data in actually real
          tables, but all the interaction takes place through JSON. This means
          you still can do real queries (using JSONPath).

          On a less boastful note, you could also look at CouchDB, it uses
          almost an identical interface for storing and accessing data (RESTful
          JSON). I would contend that Persevere has a lot more capabilities, but
          CouchDB is certainly quite popular and is a great project.

          Thanks,
          Kris
        • Michael Schøler
          ... Hi Mark, In a major project I m currently involved in we had to consider how to store client side data and process it server side. JSON was one of the
          Message 4 of 6 , Apr 14, 2008
          • 0 Attachment
            --- In json@yahoogroups.com, Mark Ireland <markincuba@...> wrote:
            > Is storing a JSON string in a database:
            >
            > A: a crap idea. period.
            > B: a crap idea under most common circumstances
            > C: pure genius
            >
            > Thanks. You've been helpful.

            Hi Mark,

            In a major project I'm currently involved in we had to consider how
            to store client side data and process it server side. JSON was one of
            the first suggestions. However, the database team (MS SQL 2005) did
            not like it one bit, because they could not do queries or perform any
            other programatic access to it "easily". Of course we all know that
            is not true but remember that JSON is more or less the scariest thing
            around to anyone other than us web folks.

            We ended up with a good alternate solution. All client side JSON is
            transformed to XML before storing it in the database. Now the db-team
            were able to use XPath/XQuery to drill the data, and they were quite
            happy. When the data is retrieved it is transformed back into the
            original JSON structure, leaving the web guys quite happy. Happy
            faces all around - done deal!

            See http://michael.hinnerup.net/blog/2008/01/26/converting-json-to-
            xml-and-xml-to-json/ for the implementation we use for the JSON<->XML
            transformation.

            Best regards,

            Michael Schøler
            Hinnerup Net ApS

            Mob: (+45) 29 72 55 34
            E-mail: michael@...
            Web: www.hinnerup.net
          • Tatu Saloranta
            ... Fundamentally there are 2 very distinct major classes of use cases: those where data is mostly or completely access as a single entity (one row, xml/json
            Message 5 of 6 , Apr 15, 2008
            • 0 Attachment
              On Mon, Apr 14, 2008 at 11:41 PM, Michael Schøler <michael@...> wrote:
              >
              > --- In json@yahoogroups.com, Mark Ireland <markincuba@...> wrote:
              > > Is storing a JSON string in a database:
              > >
              > > A: a crap idea. period.
              > > B: a crap idea under most common circumstances
              > > C: pure genius
              > >
              > > Thanks. You've been helpful.
              >
              > Hi Mark,
              >
              > In a major project I'm currently involved in we had to consider how
              > to store client side data and process it server side. JSON was one of
              > the first suggestions. However, the database team (MS SQL 2005) did
              > not like it one bit, because they could not do queries or perform any
              > other programatic access to it "easily". Of course we all know that
              > is not true but remember that JSON is more or less the scariest thing
              > around to anyone other than us web folks.

              Fundamentally there are 2 very distinct major classes of use cases:
              those where data is mostly or completely access as a single entity
              (one row, xml/json blob), and those where one need to deal with sets.
              While RDBMSs aren't even optimal for the first use case, they are
              often used for them too.
              DBAs frown upon "store xml as BLOB" approach, yet that's generally the
              most sensible way to do it: it's much much more flexible, doesn't need
              complicated slice 'n dice logics to fit possibly complicated
              structured data into simple relational model ("square peg through
              round hole"), and inevitable structural changes do not result in
              schema changes. For second case RDBMSs make sense, and it's more of a
              question of how to bind data; json can at most be used as interchange
              formats between data tier and processing (task which it can do better
              than xml although both work ok).

              In the second case, where queryability is needed, native xml databases
              or object DBs would often be more optimal choices, but sometimes one
              just has to work with whatever exists. And chances are that
              corporations just have Oracle instances, independent of whether they
              are good choice for various storage needs or not.

              Personally, more often than not I like yet another combination:
              storing json or xml docs in Amazon S3. But this is due to our use
              cases (storing configuration data in versionable sets) and YMMV.

              Anyway, one final note: the biggest thing IMO that is still mising
              from json world are data binding tools: for Java, equivalents of JAXB
              and Hibernate (binding between json and objects/relational model,
              respectively).
              Once those exist, interoperability will be much easier to deal with
              for most common cases.

              -+ Tatu +-
            • Michael Schøler
              ... I ve just read a nice article regarding RESTful web services I would like to share: RESTful Web Services vs. ``Big Web Services: Making the Right
              Message 6 of 6 , Apr 29, 2008
              • 0 Attachment
                --- In json@yahoogroups.com, "kriszyp" <kriszyp@...> wrote:
                > ...
                > If you are interested in storing JSON data in a database, you should
                > take a look at my project, Persevere
                > (http://code.google.com/p/persevere-framework/). It works with a
                > RESTful JSON interface.
                > ...

                I've just read a nice article regarding RESTful web services I would
                like to share:

                RESTful Web Services vs. ``Big'' Web Services: Making the Right
                Architectural Decision
                (http://www.www2008.org/papers/fp179.html)

                Best regards
                Michael Schøler
              Your message has been successfully submitted and would be delivered to recipients shortly.