You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Patterns JSON SQL Interface.md
+170Lines changed: 170 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -5,3 +5,173 @@ nav_order: 4
5
5
parent: Design Patterns
6
6
permalink: /patterns/json-sql
7
7
---
8
+
9
+
The JSON is a popular and robust format for passing structured information in text form. JSON libraries are broadly available in various environments, including RDBMS engines. The JSON format can serve as a kind of SQL interface for parameterized queries. When an application needs to pass a 1D vector of arbitrary length to the script, it is impossible to have a fixed parameterized script with dedicated query parameters assigned to individual values. Instead, the application packs the data into the JSON format and passes these data in a single string query parameter. The SQL script, in turn, incorporates the code for unpacking the JSON format before further processing.
10
+
11
+
JSON encoding of the passed data has several benefits. It permits having a fixed SQL script accepting an array of arbitrary length as a query parameter. Also, it establishes a relatively simple, robust, and well-defined SQL interface based on a broadly supported format. Finally, because each query parameter may cost an additional API call, this approach may also improve the overall performance of the database call. For the same reasons, using JSON for encoding the returned data may be more efficient than using a record set. While SQLite API calls are usually fast, each returned value still costs several API calls in SQLite. (Under certain circumstances, however, there might be a high SQLite-independent overhead for each API call.) An important consideration to bear in mind related to the JSON containers is the potential side effects of data conversion between numeric and textual formats.
12
+
13
+
Consider a table *fs_objects(bin_id, prefix, name)* containing a list of file system objects, uniquely identified by their absolute paths (*prefix* || *path_sep* || *name*) and a unique *bin_id*. Suppose an application needs to pass a set of new objects for insertion into this table. Such a set is a 1D vector of arbitrary size, which may contain:
14
+
15
+
1.**a scalar value for a single column** (e.g., absolute path).
16
+
2.**a pair of scalar values for two columns** (e.g., id and absolute path)
17
+
3.**a 1D array of attribute-value pairs for multiple columns** (e.g., bin_id, prefix, name)
18
+
19
+
For each of the three formats, we need a parameterized query accepting an arbitrary length 1D vector as input (query code and the number of query parameters must not depend on the input length). This task is perfectly suitable for the JSON format.
0 commit comments