Reading and Writing your Database's Documentation using JSON

  • Comments posted to this topic are about the item Reading and Writing your Database's Documentation using JSON

    Best wishes,
    Phil Factor

  • I guess I don't understand two things...

    1. Why you would ever want the documentation to be separate from the database.
    2. Why on Earth you would want the result to be in JSON.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • Jeff Moden wrote:

    I guess I don't understand two things...

    1. Why you would ever want the documentation to be separate from the database.
    2. Why on Earth you would want the result to be in JSON.

     

    1.  Well I might want to look at the documentation without having to open up SSMS or what not particularly if it's being shared with a non tech person.
    2. Yeah raw json is not the way to do that....
  • ZZartin wrote:

    Jeff Moden wrote:

    I guess I don't understand two things...

    1. Why you would ever want the documentation to be separate from the database.
    2. Why on Earth you would want the result to be in JSON.

    1.  Well I might want to look at the documentation without having to open up SSMS or what not particularly if it's being shared with a non tech person.
    2. Yeah raw json is not the way to do that....

    What I meant by question 1 was why would you want to maintain it separately?  It should all be contained in the database where you can generate the documentation at the drop of a hat... any hat.  Maintaining the documentation separately is a sure fire way to have things go "out of sync" or even be skipped entirely.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • This was removed by the editor as SPAM

  • This was removed by the editor as SPAM

  • hi Phil

    Could you explain what this means?

    "We are in Marcel Proust territory already."

    What issue is this describing?

  • james.of.rivendell wrote:

    hi Phil

    Could you explain what this means?

    "We are in Marcel Proust territory already."

    What issue is this describing?

    If you do a search in the article for the first reference, you'll find where Phil states "Remember that, like Marcel Proust's 'À la recherche du temps perdu', everyone will think it wonderful, but nobody will read it."

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • 'If you do a search in the article for the first reference, you'll find where Phil states "Remember that, like Marcel Proust's 'À la recherche du temps perdu', everyone will think it wonderful, but nobody will read it."'

    Thanks Jeff. Absolutely right.

    In the question of using JSON, I don't use it because I think it is wonderful, but just because it can be read by almost anything.  It is like speaking English. It is not that it is pretty, just that it gets understood. I discovered that it was a good way of documentiung databases entirely by accident. I was doing a series of articles on Flyway. It is a product that intrigues me, but a migrations approach isn't a good way of approaching database documentation.  Where do you find it? It isn't with the build script because there isn't one.  it could be anywhere in any migration. I was forced to do it but then found it was quick and painless and it was easier to stash in source control.

    • This reply was modified 1 year, 4 months ago by  Phil Factor.

    Best wishes,
    Phil Factor

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply