언제 JSON 또는 XML 데이터를 SQL 테이블에 저장할 수 있습니까?

programing

언제 JSON 또는 XML 데이터를 SQL 테이블에 저장할 수 있습니까?

golfzon 2023. 3. 15. 20:08

언제 JSON 또는 XML 데이터를 SQL 테이블에 저장할 수 있습니까?

「」를 사용하고 SQL ★★★★★★★★★★★★★★★★★」MySQL(또는 관련 DB) - 데이터를 일반 열에 저장하는 것이 인덱싱 및 기타 용도로 더 좋다는 것을 알고 있습니다.

을 싣는 하는 것이다.JSON데이터가 훨씬 더 단순해질 수 있으며, 개발도 더 쉬워집니다.

를 구하기 위한 ' 룰'이요?JSONDB?

그렇게 하는 것이 절대적으로 나쁜 관행인가?

주요 질문은

이 데이터로 무엇을 할 예정입니까?그리고.
이 데이터를 어떻게 필터링/정렬/가입/관리하고 있습니까?

JSON(XML과 같은)은 데이터 교환, 소규모 스토리지 및 범용적으로 정의된 구조에 매우 적합합니다.그러나 RDBMS 내에서 실행하는 일반적인 작업에는 참여할 수 없습니다.대부분의 경우 JSON 데이터를 일반 테이블로 전송하여 필요할 때 JSON을 다시 생성하는 것이 좋습니다.

XML / JSON 및 1NF

정규화의 첫 번째 규칙은 두 개 이상의 정보를 한 열에 저장하지 않도록 지시합니다."Mickey Mouse"와 같은 값이 포함된 "Person Name" 열이 표시됩니다.당신은 이것을 가리키며 울부짖습니다: 즉시 그것을 바꾸세요!

XML 또는 JSON은 어떻습니까?이 타입들은 1을 깨는 건가요?NF요? 음, 네, 아니요...

실제로 하나의 정보라면 완전한 구조를 하나의 정보로 저장해도 무방합니다.SOAP 응답을 받고 나중에 참조할 때 필요할 수 있기 때문에 저장하려고 합니다(그러나 이 데이터를 프로세스에 사용하지 않을 예정입니까).그대로 보관하세요!

이제 개인을 나타내는 복잡한 구조(XML 또는 JSON)를 상상해 보십시오(주소, 상세 정보 등).이제 이것을 하나의 컬럼에 넣습니다.이것이 틀렸습니까?XML/JSON 대신 외부 키 참조를 사용하여 적절하게 설계된 관련 테이블에 저장해야 하지 않을까요?특히 같은 사람이 여러 행에서 발생할 수 있는 경우 XML/JSON 접근 방식을 사용하는 것은 분명히 잘못된 것입니다.

그러나 이제 과거 데이터를 저장할 필요성을 상상해 보십시오.특정 시간 동안 사용자의 데이터를 유지하려고 합니다.며칠 후에 그 사람이 당신에게 새 주소를 알려주나요?문제없어!필요한 경우 이전 주소는 XML/JSON에 있습니다.

결론:데이터를 보관하기 위해서만 저장해 두면 괜찮습니다.이 데이터가 유일한 부분이라면 괜찮습니다.
하지만 내부 부품이 정기적으로 필요하거나 중복 스토리지가 필요한 경우에는 문제가 없습니다.

물리 스토리지

다음은 SQL Server용이며 다른 RDBM에서는 다를 수 있습니다.

XML은 표시되는 텍스트가 아니라 계층 트리로 저장됩니다.이 질문에 대한 답변은 놀라울 정도로 훌륭합니다!이 구조는 문자열 수준에서 구문 분석되지 않습니다!
SQL Server(2016+)의 JSON은 문자열에 존재하므로 구문 분석해야 합니다.실제 네이티브 JSON 타입은 없습니다(네이티브 XML 타입이 있는 것처럼).나중에 발생할 수 있지만 현재로서는 JSON의 성능이 SQL Server의 XML만큼 높지 않을 것으로 예상됩니다(섹션 UPDATE 2 참조).JSON에서 값을 읽어야 할 경우 숨겨진 문자열 메서드 호출이 많이 필요합니다.

이것은 당신에게 어떤 의미입니까?

당신의 사랑스러운 DB 아티스트:-D는 JSON을 그대로 저장하는 것이 RDBM의 일반적인 원칙에 어긋난다는 것을 알고 있습니다.

JSON이 1을 파괴하고 있을 가능성이 높다고 생각합니다.NF
JSON이 시간에 따라 변경될 수 있습니다(같은 열, 다른 내용).
JSON은 읽기 어렵고 필터링, 검색, 결합 또는 정렬이 매우 어렵습니다.
이러한 조작으로 인해 부하가 작고 불량한 DB 서버로 이동하게 됩니다.

(사용하는 RDBMS에 따라) 몇 가지 회피책이 있습니다만, 대부분의 회피책은 원하는 대로 동작하지 않습니다.

요컨대 당신의 질문에 대한 답변은

네.

고비용 작업(필터/조인/소트)을 위해 JSON에 저장된 데이터를 사용하지 않는 경우.
다른 모든 항목이 컨텐츠만 존재하는 것처럼 이 항목을 저장할 수 있습니다.많은 사진을 BLOB로 저장하고 있습니다만, 꽃으로 모든 이미지를 필터링 하려고는 하지 않습니다.
내용물을 전혀 신경 쓰지 않으면 (저장하고 하나의 정보로 읽기만 하면 됩니다)
구조가 가변적일 경우 물리적 테이블을 작성하기가 더 어려워집니다. 그러면 JSON 데이터로 작업합니다.
구조가 깊이 중첩되어 있는 경우 물리적 테이블의 스토리지 오버헤드가 커집니다.

아니요.

관계형 테이블의 데이터(필터, 인덱스, 조인...)를 사용하는 것처럼 내부 데이터를 사용하려면
중복 저장(용장성 생성)
일반적으로:퍼포먼스 문제에 직면했을 경우(많은 일반적인 시나리오에서 반드시 직면할 것입니다).

문자열 열 내의 JSON 또는 BLOB로 시작하여 필요할 때 물리적 테이블로 변경할 수 있습니다.내 마법의 크리스탈 볼은 이것이 내일일지도 모른다고 말한다:-D

갱신하다

퍼포먼스와 디스크 용량에 관한 아이디어는, https://stackoverflow.com/a/47408528/5089204 를 참조해 주세요.

업데이트 2: 퍼포먼스 상세...

다음은 SQL-Server 2016에서의 JSON 및 XML 지원에 대해 설명합니다.

사용자 @mike123은 실험에서 JSON을 쿼리하는 것이 SQL-Server에서 XML을 쿼리하는 것보다 10배 빠르다는 것을 증명하는 것처럼 보이는 공식 Microsoft 블로그의 기사를 지적했습니다.

이에 대한 몇 가지 의견:

"실험"과 교차 점검:

XML 대 JSON의 퍼포먼스는 측정하지 않지만 "실험"은 많은 것을 측정합니다.동일한(변경되지 않은) 문자열을 반복적으로 실행하는 것은 현실적인 시나리오가 아닙니다.
테스트한 예는 일반적인 설명으로는 매우 간단합니다.
읽혀진 값은 항상 동일하며 사용되지도 않습니다.옵티마이저가 이걸 보게 될 거야
강자에 대해 한마디도 하지 마XQuery은 에 JSON을 사용하여 .WHERE와 동시에 , 「」를 참조해 주세요.XML됩니다.XQuery predicate 대해서는 말아 주세요FLWOR
시스템상의 「실험」코드가 기동하고 있습니다.JSON이 3배 빠른 것 같습니다(10배는 아닙니다).
를 추가하면 이 값이 2배 미만으로 줄어듭니다.관련 기사 사용자 "Mister Magoo"가 이미 지적했지만, 클릭베이트 타이틀은 바뀌지 않았습니다...
빠른 은 "SYSON"을 조합한 입니다.SUBSTRING ★★★★★★★★★★★★★★★★★」CHARINDEX:-D

다음 코드는 보다 현실적인 실험을 보여줍니다.

및 JSON을 Product 노드 (JSON 어레이와 형제 노드)
JSON과 XML은 약간 변경(10000의 실행 번호)되어 테이블에 삽입됩니다.
첫 번째 콜 바이어스를 피하기 위해 두 테이블 모두에 첫 번째 콜이 있습니다.
10000 엔트리가 모두 읽혀지고 취득된 값이 다른 테이블에 삽입됩니다.
「」를 사용합니다.GO 10이 블록을 10회 통과하여 첫 번째 콜을 회피합니다.

최종 결과는 JSON이 XML보다 느리다는 것을 명확하게 보여줍니다(단순한 예에서는 그다지 많지 않습니다).

최종 설명:

지나치게 단순화된 예제를 사용하면 JSON이 XML보다 빠를 수 있습니다.
JSON의 처리는 순수 문자열 액션이지만 XML은 구문 분석 및 변환됩니다.이것은 첫 번째 액션에서는 다소 비용이 많이 들지만, 이 작업이 완료되면 모든 것이 빨라집니다.
JSON은 1회성 액션에 적합할 수 있습니다(XML의 내부 계층 표현 작성에 따른 오버헤드가 없습니다).
매우 심플하지만 보다 사실적인 예제를 사용하면 XML을 쉽게 읽을 수 있습니다.
어레이에서 특정 요소를 읽어낼 필요가 있는 경우 항상 특정 제품의 모든 엔트리를 필터링합니다.ID가 어레이에 포함되어 있거나 경로를 위아래로 이동하기 위해 JSON이 유지할 수 없습니다.스트링에서 완전히 파싱해야 합니다.파싱할 때마다...

테스트 코드

USE master;
GO
--create a clean database
CREATE DATABASE TestJsonXml;
GO
USE TestJsonXml;
GO
--create tables
CREATE TABLE TestTbl1(ID INT IDENTITY,SomeXml XML);
CREATE TABLE TestTbl2(ID INT IDENTITY,SomeJson NVARCHAR(MAX));
CREATE TABLE Target1(SomeString NVARCHAR(MAX));
CREATE TABLE Target2(SomeString NVARCHAR(MAX));
CREATE TABLE Times(Test VARCHAR(10),Diff INT)
GO
--insert 10000 XMLs into TestTbl1
WITH Tally AS(SELECT TOP 10000 ROW_NUMBER() OVER(ORDER BY (SELECT NULL))*2 AS Nmbr FROM master..spt_values AS v1 CROSS APPLY master..spt_values AS v2)
INSERT INTO TestTbl1(SomeXml)
SELECT 
N'<Root>
    <Products>
    <ProductDescription>
        <Features>
            <Maintenance>' + CAST(Nmbr AS NVARCHAR(10)) + ' year parts and labor extended maintenance is available</Maintenance>
            <Warranty>1 year parts and labor</Warranty>
        </Features>
        <ProductID>' + CAST(Nmbr AS NVARCHAR(10)) + '</ProductID>
        <ProductName>Road Bike</ProductName>
    </ProductDescription>
    <ProductDescription>
        <Features>
            <Maintenance>' + CAST(Nmbr + 1 AS NVARCHAR(10)) + ' blah</Maintenance>
            <Warranty>1 year parts and labor</Warranty>
        </Features>
        <ProductID>' + CAST(Nmbr + 1 AS NVARCHAR(10)) + '</ProductID>
        <ProductName>Cross Bike</ProductName>
    </ProductDescription>
    </Products>
</Root>'
FROM Tally;

--insert 10000 JSONs into TestTbl2
WITH Tally AS(SELECT TOP 10000 ROW_NUMBER() OVER(ORDER BY (SELECT NULL)) AS Nmbr FROM master..spt_values AS v1 CROSS APPLY master..spt_values AS v2)
INSERT INTO TestTbl2(SomeJson)
SELECT 
N'{
    "Root": {
        "Products": {
            "ProductDescription": [
                {
                    "Features": {
                        "Maintenance": "' + CAST(Nmbr AS NVARCHAR(10)) + ' year parts and labor extended maintenance is available",
                        "Warranty": "1 year parts and labor"
                    },
                    "ProductID": "' + CAST(Nmbr AS NVARCHAR(10)) + '",
                    "ProductName": "Road Bike"
                },
                {
                    "Features": {
                        "Maintenance": "' + CAST(Nmbr + 1 AS NVARCHAR(10)) + ' blah",
                        "Warranty": "1 year parts and labor"
                    },
                    "ProductID": "' + CAST(Nmbr + 1 AS NVARCHAR(10)) + '",
                    "ProductName": "Cross Bike"
                }
            ]
        }
    }
}'
FROM Tally;
GO

--Do some initial action to avoid first-call-bias
INSERT INTO Target1(SomeString)
SELECT SomeXml.value('(/Root/Products/ProductDescription/Features/Maintenance/text())[1]', 'nvarchar(4000)')
FROM TestTbl1;
INSERT INTO Target2(SomeString)
SELECT JSON_VALUE(SomeJson, N'$.Root.Products.ProductDescription[0].Features.Maintenance')
FROM TestTbl2;
GO

--Start the test
DECLARE @StartDt DATETIME2(7), @EndXml DATETIME2(7), @EndJson DATETIME2(7);

--Read all ProductNames of the second product and insert them to Target1
SET @StartDt = SYSDATETIME();
INSERT INTO Target1(SomeString)
SELECT SomeXml.value('(/Root/Products/ProductDescription/ProductName/text())[2]', 'nvarchar(4000)')
FROM TestTbl1
ORDER BY NEWID();
--remember the time spent
INSERT INTO Times(Test,Diff)
SELECT 'xml',DATEDIFF(millisecond,@StartDt,SYSDATETIME());

--Same with JSON into Target2
SET @StartDt = SYSDATETIME();
INSERT INTO Target2(SomeString)
SELECT JSON_VALUE(SomeJson, N'$.Root.Products.ProductDescription[1].ProductName')
FROM TestTbl2
ORDER BY NEWID();
--remember the time spent
INSERT INTO Times(Test,Diff)
SELECT 'json',DATEDIFF(millisecond,@StartDt,SYSDATETIME());

GO 10 --do the block above 10 times

--Show the result
SELECT Test,SUM(Diff) AS SumTime, COUNT(Diff) AS CountTime
FROM Times
GROUP BY Test;
GO
--clean up
USE master;
GO
DROP DATABASE TestJsonXml;
GO

그 결과 (Acer Aspire v17 Nitro Intel i7, 8GB RAM 상의 SQL Server 2016 Express)

Test    SumTime 
------------------
json    2706    
xml     1604

마술 지팡이를 흔들겠습니다.펑! JSON 사용에 대한 황금 규칙:

MySQL이 JSON의 내부를 볼 필요가 없고 어플리케이션이 단순히 자료를 모아야 한다면 JSON은 문제없고, 어쩌면 더 좋을지도 모릅니다.
MariaDB 10.0.1 또는 MySQL 5.7(JSON 데이터 유형 및 함수 포함)을 사용하는 경우 JSON이 실용적일 수 있습니다.MariaDB 5.3의 "Dynamic" 열은 이에 대한 변형입니다.
엔티티 속성 가치 같은 것을 하고 있다면 JSON은 좋지 않지만 몇 가지 폐해 중 가장 적은 것입니다.http://mysql.rjweb.org/doc.php/eav
인덱스 컬럼에 의한 검색의 경우 값이 JSON 내에 포함되어 있지 않은 것이 큰 장점입니다.
""" 의 FULLTEXT 또는 「」를 참조해 주세요.SPATIAL할 수 없습니다JSON은 사용할 수 없습니다.
★★★의 WHERE a=1 AND b=2의 '고 ''자'INDEX(a,b)son과과jjjjj과j과jjjjsonsonsonson.JSON
JSON은 "희소" 데이터에서는 잘 동작합니다.인덱싱은 이러한 데이터에서는 잘 동작하지만 그렇지 않습니다.(대부분의 행에서 '누락' 또는 NULL 값을 말합니다.)
JSON은 추가 테이블에 의존하지 않고 "arrays"와 "tree"를 제공할 수 있습니다.그러나 이러한 어레이/트리는 SQL이 아닌 앱에서만 살펴보십시오.
JSON은 XML보다 훨씬 낫습니다.(내 의견)
의 JSON 하고 않은 (의) JSON 에 을 추천합니다BLOB해 보세요안 써요.jpg라고 생각하면 됩니다.- 안에 물건이 있는데 SQL은 신경 안 써요.

지원서를 제출해 주십시오.좀 더 자세히 설명해 드릴 수 있을 것 같습니다.

" 잘못된" 경우 .완전히 잘못된" 경우 대부분의 데이터베이스는 이를 지원하지 않습니다. 대부분의 는 콤마를 하고 있습니다.FROM 지원은 그러나 JSON에 대한 지원은 새로운 개발이지 하위 호환성이 있는 "기능"이 아닙니다.

JSON 구조가 단순히 애플리케이션에 반환되는 BLOB인 경우가 한 가지 분명한 예입니다.JSON 저장에 대한 오버헤드를 제외하면 논쟁은 없습니다.JSON 저장에 대한 오버헤드는 모든 레코드에 공통 필드가 있는 구조화된 데이터에 대해 불필요하게 상세하게 설명됩니다.

또 다른 케이스는 "희박" 컬럼 케이스입니다.사용 가능한 열이 여러 개 있지만 행마다 다릅니다.

또 다른 경우는 레코드에 "내스트된" 레코드를 저장하려는 경우입니다.JSON은 힘이 세요.

JSON에 조회하는 레코드에 공통 필드가 있는 경우 일반적으로 이러한 필드를 적절한 데이터베이스 열에 넣는 것이 좋습니다.그러나 데이터는 복잡하며 JSON과 같은 형식을 사용해야 합니다.

New SQL Server는 JSON 텍스트를 처리하는 기능을 제공합니다.JSON으로 포맷된 정보는 표준 SQL Server 열에 텍스트로 저장할 수 있으며 SQL Server는 이러한 JSON 개체에서 값을 검색할 수 있는 기능을 제공합니다.

    DROP TABLE IF EXISTS Person

 CREATE TABLE Person 
 ( _id int identity constraint PK_JSON_ID primary key,
 value nvarchar(max)
 CONSTRAINT [Content should be formatted as JSON]
 CHECK ( ISJSON(value)>0 )
 )

이 단순한 구조는 NoSQL 데이터베이스에 작성할 수 있는 표준 NoSQL 컬렉션과 유사합니다(예: Azure Document).DB 또는 MongoDB)에서는 JSON을 나타내는 ID 및 값을 나타내는 키만 사용할 수 있습니다.

NVARCHAR는 단순한 텍스트가 아닙니다.SQL Server에는 디스크에 저장된 데이터를 투명하게 압축할 수 있는 텍스트 압축 메커니즘이 내장되어 있습니다.압축은 언어에 따라 다르며 데이터에 따라 최대 50%까지 할 수 있습니다(UNICODE 압축 참조).

SQL Server와 다른 일반 NoSQL 데이터베이스의 주요 차이점은 SQL Server를 사용하면 하이브리드 데이터 모델을 사용하여 여러 JSON 개체를 동일한 "컬렉션"에 저장하고 일반 관계 열과 결합할 수 있다는 것입니다.

예를 들어 컬렉션 내의 모든 사용자가 FirstName과 LastName을 가지고 있으며 사용자에 대한 일반적인 정보를 하나의 JSON 개체로 저장하고 전화번호나 이메일주소를 개별 개체로 저장할 수 있다고 가정합니다.SQL Server 2016에서는 추가 구문 없이 이 구조를 쉽게 만들 수 있습니다.

DROP TABLE IF EXISTS Person

CREATE TABLE Person (

 PersonID int IDENTITY PRIMARY KEY,

 FirstName nvarchar(100) NOT NULL,

 LastName nvarchar(100) NOT NULL,

 AdditionalInfo nvarchar(max) NULL,

 PhoneNumbers nvarchar(max) NULL,

 EmailAddresses nvarchar(max) NULL
 CONSTRAINT [Email addresses must be formatted as JSON array]
 CHECK ( ISJSON(EmailAddresses)>0 )

 )

단일 JSON 개체 대신 이 "수집"에서 데이터를 구성할 수 있습니다.각 JSON 열의 구조를 명시적으로 체크하지 않으면 각 열에 JSON 체크 제약 조건을 추가할 필요가 없습니다(이 예에서는 EmailAddresses 열에만 CHECK 제약 조건을 추가했습니다).

이 구조를 표준 NoSQL 컬렉션과 비교하면 강력한 유형의 데이터(FirstName 및 LastName)에 보다 빠르게 액세스할 수 있습니다.따라서 이 솔루션은 모든 개체에 걸쳐 반복되는 일부 정보를 식별하고 다른 변수 정보를 JSON으로 저장할 수 있는 하이브리드 모델에 적합합니다.이를 통해 유연성과 성능을 결합할 수 있습니다.

이 구조를 개인 테이블 AdventureWorks 데이터베이스의 스키마와 비교하면 관련 테이블이 많이 삭제되어 있는 것을 알 수 있습니다.

스키마가 단순할 뿐만 아니라 데이터 액세스 조작도 복잡한 관계 구조에 비해 간단해집니다.이제 여러 테이블을 결합하는 대신 단일 테이블을 읽을 수 있습니다.관련 정보(이메일 주소, 전화번호)를 가진 새로운 사용자를 삽입해야 할 경우 AdventureWorks Person 테이블에 레코드를 삽입하지 않고 하나의 테이블에 하나의 레코드를 삽입할 수 있습니다.ID 열을 사용하여 전화기, 이메일 주소 등에 사용되는 외부 키를 찾을 수 있습니다.또한 이 모델에서는 외부 키 관계를 사용하여 계단식 삭제 없이 단일 사용자 행을 쉽게 삭제할 수 있습니다.

NoSQL 데이터베이스는 단순, 읽기, 삽입 및 삭제 작업에 최적화되어 있습니다. SQL Server 2016을 사용하면 관계형 데이터베이스에 동일한 논리를 적용할 수 있습니다.

JSON 제약사항 이전 예에서는 열에 저장된 텍스트의 형식이 올바른지 확인하는 간단한 제약조건을 추가하는 방법을 살펴보았습니다.JSON에는 강력한 스키마가 없지만 JSON에서 값을 읽는 함수와 표준 T-SQL 함수를 결합하여 복잡한 제약 조건을 추가할 수도 있습니다.

ALTER TABLE Person
 ADD CONSTRAINT [Age should be number]
 CHECK ( ISNUMERIC(JSON_VALUE(value, '$.age'))>0 )

 ALTER TABLE Person
 ADD CONSTRAINT [Person should have skills]
 CHECK ( JSON_QUERY(value, '$.skills') IS NOT NULL)
First constraint will take the value of $.age property and check is this numeric value. Second constraint will try to find JSON object in $.skills property and verify that it exists. The following INSERT statements will fail due to the violation of constraints:



INSERT INTO Person(value)
 VALUES ('{"age": "not a number", "skills":[]}')

 INSERT INTO Person(value)
 VALUES ('{"age": 35}')

CHECK 제약조건은 삽입/갱신 프로세스의 속도를 늦출 수 있으므로 보다 빠른 쓰기 성능이 필요한 경우 이를 피할 수 있습니다.

압축된 JSON 저장소 큰 JSON 텍스트가 있는 경우 내장된 COMPRESS 기능을 사용하여 JSON 텍스트를 명시적으로 압축할 수 있습니다.다음 예제에서는 압축된 JSON 내용이 이진 데이터로 저장되며 DECOMPRESS 함수를 사용하여 원본 텍스트로 압축 해제되는 열을 계산했습니다.

CREATE TABLE Person

 ( _id int identity constraint PK_JSON_ID primary key,

 data varbinary(max),

 value AS CAST(DECOMPRESS(data) AS nvarchar(max))

 )



 INSERT INTO Person(data)

 VALUES (COMPRESS(@json))

COMPRESS 및 DECOMPRESS 기능은 표준 GZip 압축을 사용합니다.클라이언트가 GZIP 압축(예를 들어 gzip 콘텐츠를 인식하는 브라우저)을 처리할 수 있는 경우 압축된 콘텐츠를 직접 반환할 수 있습니다.이것은 퍼포먼스/스토리지의 트레이드오프입니다.압축된 데이터를 자주 쿼리하는 경우 매번 텍스트의 압축을 풀어야 하므로 마이그레이션 성능이 느려집니다.

참고: JSON 기능은 SQL Server 2016+ 및 Azure SQL Database에서만 사용할 수 있습니다.

자세한 것은, 이 기사의 출처를 참조해 주세요.

https://blogs.msdn.microsoft.com/sqlserverstorageengine/2015/11/23/storing-json-in-sql-server/

제가 사용하는 '골든 룰'은 JSON의 raw 포맷이 필요한 경우 저장할 수 있다는 것입니다.굳이 해석해야 한다면 그렇지 않겠죠

예를 들어 raw JSON을 송신하는 API를 작성하고 있으며 어떤 이유로 이 값이 변경되지 않을 경우 raw JSON으로 저장해도 괜찮습니다.해석, 변경, 갱신 등이 필요한 경우...많이는 안 되겠네요

질문할 사항은 다음과 같습니다.

이 데이터베이스만 사용해야 하나요?

하다

다른 데이터베이스를 사용하여 JSON을 저장할 수 있는 경우 CouchDB, DynamoDB 또는 MongoDB와 같은 문서 스토리지 솔루션을 사용하십시오.
이러한 문서 저장소 DB의 기능을 사용하여 계층 데이터를 색인화하고 검색합니다.
관계형 데이터에 관계형 데이터베이스를 사용합니다.
보고, 데이터 웨어하우징 및 데이터 마이닝에 관계형 데이터베이스를 사용합니다.

하지 마

가능한 경우 JSON을 문자열로 저장합니다.
JSON 데이터의 최대 길이를 생각해 보십시오.
varchar를 사용하여 JSON을 저장합니다(필요한 경우 text/blob 사용).
저장된 JSON에서 값을 검색해 보십시오.
문자열로 저장하기 위해 JSON을 이스케이프하는 것에 대해 걱정합니다.

Json's는 관계 dbs에 적합하지 않습니다.json을 열로 펼쳐 db에 저장하면 좋지만 json을 blob으로 저장하면 데이터 아카이브 시스템으로 사용할 수 있습니다.

json을 전개하지 않고 단일 열에 저장하는 데는 여러 가지 이유가 있을 수 있지만, json 필드의 값이 쿼리에 사용되지 않기 때문에(또는 값이 이미 열로 전개되어 있기 때문에) 결정이 내려집니다.

또한 필드가 모두 쿼리된 경우 대부분의 json 처리는 sql이 json 처리를 위한 것이 아니기 때문에 sql 환경 밖에 있습니다.여기서 진짜 질문은 이 json을 어디에 저장해야 하는지, 플랫 파일처럼 그대로 두고 필요할 때 다른 시스템(spark/hive 등)을 통해 쿼리해야 하는지입니다.

DB 아티스트의 의견에 동의합니다. 아카이브에 RDBMS를 사용하지 마십시오.더 저렴한 옵션도 있습니다.또한 json blob이 커지면 시간이 지남에 따라 DB Disk 공간이 부족해질 수 있습니다.

에는 Postgre가 .SQL ★★★★json ★★★★★★★★★★★★★★★★★」jsonb 유형 데이터 표시

다음은 몇 가지 예입니다.

CREATE TABLE orders (
 ID serial NOT NULL PRIMARY KEY,
 info json NOT NULL
);

INSERT INTO orders (info)
VALUES
 (
 '{ "customer": "Lily Bush", "items": {"product": "Diaper","qty": 24}}'
 ),
 (
 '{ "customer": "Josh William", "items": {"product": "Toy Car","qty": 1}}'
 ),
 (
 '{ "customer": "Mary Clark", "items": {"product": "Toy Train","qty": 2}}'
 );

오퍼레이터 Postgre를 합니다.SQL 2는 SQL 2로 되어 있습니다.-> ★★★★★★★★★★★★★★★★★」->>JSON 데이터를 조회합니다.

「」->JSON을 사용하다

「」->>JSON을 사용하다

SELECT
 info -> 'customer' AS customer
FROM
 orders;

SELECT
 info ->> 'customer' AS customer
FROM
 orders
WHERE
 info -> 'items' ->> 'product' = 'Diaper'

언급URL : https://stackoverflow.com/questions/43494824/when-can-i-save-json-or-xml-data-in-an-sql-table

'programing' 카테고리의 다른 글

워드프레스 기능과 함수의 current_user_can().php (0)	2023.03.15
동일한 데이터베이스에서 서로 다른 테마를 사용하는 두 개의 워드프레스 사이트 (0)	2023.03.15
jest: 테스트 스위트를 실행하지 못했습니다. SyntaxError:예기치 않은 토큰 Import (0)	2023.03.15
오류: 구현되지 않음: window.scrollTo.Jest 테스트에서 이 오류를 제거하려면 어떻게 해야 합니까? (0)	2023.03.15
MUI에서의 응답 타이포그래피? (0)	2023.03.15

현재글언제 JSON 또는 XML 데이터를 SQL 테이블에 저장할 수 있습니까?

각종 프로그래밍 정보를 다루는 블로그입니다.

Angular, Xcode, spring-boot, git, sql-server, Wordpress, reactjs, Excel, ajax, json, WPF, angularJS, windows, ios, mongodb, bash, TypeScript, Eclipse, Oracle, Spring,

Today :
Yesterday :

golfzon

언제 JSON 또는 XML 데이터를 SQL 테이블에 저장할 수 있습니까?

언제 JSON 또는 XML 데이터를 SQL 테이블에 저장할 수 있습니까?

XML / JSON 및 1NF

물리 스토리지

이것은 당신에게 어떤 의미입니까?

요컨대 당신의 질문에 대한 답변은

갱신하다

업데이트 2: 퍼포먼스 상세...

'programing' 카테고리의 다른 글

'programing'의 다른글

티스토리툴바

« 2026/04 »
일	월	화	수	목	금	토
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30

언제 JSON 또는 XML 데이터를 SQL 테이블에 저장할 수 있습니까?

언제 JSON 또는 XML 데이터를 SQL 테이블에 저장할 수 있습니까?

XML / JSON 및 1NF

물리 스토리지

이것은 당신에게 어떤 의미입니까?

요컨대 당신의 질문에 대한 답변은

갱신하다

업데이트 2: 퍼포먼스 상세...

'programing' 카테고리의 다른 글

'programing'의 다른글

관련글

티스토리툴바