Will storing XML data in sql table be an architecture error?

I have an SQL table that I use to store product data. Some products have other data attached to them (be it: books have a number of pages, cover type, films have a duration, etc.).

I could use a separate table in SQL to save it by storing (name, value) pairs.

I can also just store XML-wrapped data in one field in a table. This is not a normalized approach, but to me it seems more natural.

+3
source share
4 answers

I did a similar thing in the shopping cart app. We needed to bind metadata to products without creating too much schema that would limit the format of metadata in the future. We saved the metadata as XML.

The only reason I will not do this is because you are going to perform data queries. Just make sure you don’t have any stupid person wanting to receive Publisher metadata reports or something (what happened to me) and you should be fine.

+3
source

If you intended to use XML as a way to incorrectly define database tables that really would be an architectural solution. I'm not sure about your scenario, it seems dangerously close to that. But key value pairs are probably worse.

XML- , . RageZ, Oracle, XMLType, ( 9i). XMLType . , - XML. , XML-, . , XML. , Oracle XDB XML, XPath.

+1

!

, "" , XML - . [ SQL Server, XML-.]

0

I do not consider this an architectural fallacy. Just make sure that you do not want to use this data in the request, because it will be complicated.

Plus, the recent RDBM has an XML processing function (MSSQL, Postgres, Mysql), so you can still use this data.

0
source

Source: https://habr.com/ru/post/1717907/


All Articles