CrazyEngineers
CrazyEngineers

  • What are Advantages / Disadvantages of Storing Data as JSON in Database?

    Kaustubh Katdare

    Administrator

    Updated: Oct 26, 2024
    Views: 1.3K

    I'm currently experimenting with storing the data as JSON in the database. I found out that latest versions of database engines allow storing of data JSON or JSON by data type. I'm wondering what exactly are the advantages and disadvantages of storing data as JSON vs. storing it as a regular text-string?

    I did try finding information about it - but could not find anything that directly answers the question I have. 

    PS: My dilemma is about retrieving the data as JSON vs. retrieving it as plain text string. Ultimately, JSON itself looks like a plain text string to my eyes. 

    Tagging: #-Link-Snipped-# , #-Link-Snipped-# (add a photo, buddy!) for responses. 

    0
    Replies
Howdy guest!
Dear guest, you must be logged-in to participate on CrazyEngineers. We would love to have you as a member of our community. Consider creating an account or login.
Replies

  • Prasad Ajinkya

    Member • Mar 3, 2019

    JSON is good for storing objects/documents in the DB when you are not sure of the structure of the object. The beauty of this is that you can store your data hierarchically.

    JSON can be a plain string, but if you parse the string (json_decode() in PHP, JSON.parse() in JS, etc), then you get an object which can be manipulated. This is catching on because these JSON objects can match directly with controllers and views.

    Hope this helps.

    Are you sure? This action cannot be undone.
    Cancel

  • Kaustubh Katdare

    Administrator • Mar 4, 2019

    #-Link-Snipped-# - right. So far, the only advantage I've realized is that the data obtained from the database can be directly employed as an object. So that works. Was wondering if there are any specific cases where data needs to be stored as JSON. Thank you for the reply. 

    Are you sure? This action cannot be undone.
    Cancel

  • Prasad Ajinkya

    Member • Mar 4, 2019

    1. Where your object schema is unknown during design time and becomes relevant in run-time. 
    2. Where your object schema changes over a period of time (progressive profiling, document completion, multi-layer form fills)
    3. Where each document/tupple is standalone and doesnt have to rely on multiple joins.

    Let's say that we create a Pay Per Use REST API (The API Economy) .. and for sake of compliance and billing have to store each Request/Response objects. So a simple case could be store both the request and response objects as JSON documents within a single document, and keep a collection of those. 

    The thing about specifications is that if you keep specifying these, then the very reason why you would require this is eliminated. Since with those sharper specifications, you could always design an optimised RDBMS.

    Are you sure? This action cannot be undone.
    Cancel
Home Channels Search Login Register