Fun with JSON I

  • Comments posted to this topic are about the item Fun with JSON I

  • Out of curiosity, I gave this question to Anthropic's Claude.

    I have been using Claude Code quite a bit for development for the last 6 months and it has dramatically increased my productivity in that area and for the developers who work for me. On the other hand, I haven't been able to gain the same productivity increases on the SQL side and usage of Claude by my data team is minimal. I see Claude changing what I look for in a developer. I  have always thought that a developer who understands the business they are developing for will produce a better product. Now, with Claude writing the code, a developer cannot just be a good coder; a valuable developer now MUST understand the business because the developer needs to be able to describe it all to Claude to get the correct output.  Additionally, the developer must be able to develop a strong set of test cases to validate the solution. I have had people tell me, that's why you have a business analyst and they are correct for yesterday, partially correct for today, and wrong for tomorrow. Tomorrow, with the quality of code Claude can write, the BA doesn't need the developer any longer. The BA has the knowledge and understanding to direct Claude to write the code. While Claude has not achieved the same level of competency in the SQL realm as it has in the development realm, that day is coming. There are sound uses for Claude today though. For example, Claude can analyze an entire development solution and accurately generate the scripts for all the required tables, views, stored procedures, etc. You want a small or large set of test data, tell Claude what you need and Claude will load the data for you.

    Claude's response:

    That query returns 4 rows.

    FOR JSON PATH serializes the table into a JSON array, and OPENJSON without an explicit schema returns one row per element in that array. Each row comes back with the default columns: key (the zero-based index), value (the JSON object as a string), and type (the JSON type indicator).

    So you'd get something like:

    key  value  type

    0  {"id":1,"name":"Olivia","birth_date":"2025-01-05"}  5

    1  {"id":2,"name":"Emma","birth_date":"2025-03-02"}  5

    2  {"id":3,"name":"Liam","birth_date":"2025-11-15"}  5

    3  {"id":4,"name":"Noah","birth_date":"2025-12-22"}  5

    (type = 5 indicates a JSON object.)

    The reality is, this question is not a very good test for Claude because the 'solution' is already known. A more real world scenario would be to describe the data structure to Claude and make a request like, "I need a sql statement that will convert the rows of the table into json, one json object for each row." For the same table, here is Claude's response to that request.

    SELECT t.id, (SELECT t.* FOR JSON PATH, WITHOUT_ARRAY_WRAPPER) AS json_object FROM #test_data AS t;

    ewm2

Viewing 2 posts - 1 through 2 (of 2 total)

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