Consider an application where you can create and edit a SVG file (e.g. draw.io).

How should the SVG be stored in the database?

With SVG (image/svg+xml)

Thus no further processing is required before the data is stored. But after the data is retrieved the SVG needs to be parsed so the application can set up event handlers and integrate the SVG with the functionality of the application.

With JSON (application/json)

The SVG data will have to be converted to a JSON object what will be stored in and retrieved from the database. When retrieving the JSON data from the database. The data must be converted back to SVG and while doing that the functionality of the application may be applied to the SVG.


Storing and retrieving the data isn't probably the part to be concerned about because it will take about the same amount of time and space to store or retrieve a SVG or JSON (depending on the differences in attribute/key length). Thus I guess the real performance issues occur at parsing the data. I know parsing JSON is easier and faster then XML, however when storing as SVG parsing of the data happens only once with JSON twice.

An other software engineer in my team told me to use JSON but couldn't substantiate why? Perhaps someone can substantiate why JSON should be chosen?

  • 1
  • Who is going to look at the SVG? If it is the client, then just let the browser parse the SVG text, and then traverse the DOM to install event handlers. – Erik Eidt Oct 11 at 13:54
  • 1
    @ErikEidt You can even gzip them and let the browser decompress them too. – JimmyJames Oct 11 at 14:07

An other software engineer in my team told me to use JSON but couldn't substantiate why?

Maybe it was a joke? I can't think of any benefit to storing SVG inside JSON. None.

I would store SVG files...in SVG format. Storing them in a file or blob storage system would be preferable to a database IMHO, but a database isn't a terrible option if the file sizes are small.

  • I don't think it was a joke, the reason why the other engineer said that should be JSON is probably because JSON is commonly used in the application and works well with the language and framework (ReactJS) what is used. Working with the XML in the SVG will probably require a specific library to be imported for that kind of tasks. – Fleuv Oct 11 at 14:08
  • @Fleuv it depends. SVG libraries are convenient but you can parse and modify SVG with pure JavaScript (depending on browser support). – Dan Wilson Oct 11 at 14:22

Neither.

You should store the model the application uses to generate the svg. ie for a network diagram the various nodes and joins.

That way when you change the svg generation code the old models will generate the new graphics. Rather than have the old graphics load.

Essentially the svg is the view and you want to save the model.

  • I guess that would decrease the flexibility in what may be designed in the "SVG-editor" and/or increase the complexity of the model and rules attached to it? – Fleuv Oct 11 at 14:13
  • on the contrary. it will increase the flexibility and decrease the complexity – Ewan Oct 11 at 14:47
  • This is surely a good approach for applications like draw.io, where SVG is just one export format of many. It might be be a suboptimal suggestions for an application like Inkscape, where SVG is actually the most natural data format for the processed subject. (+1 from me) – Doc Brown Oct 11 at 16:44
  • @db yes, im assuming that since you want to link events and controls to the svg there is some document structure behind it. If its a v basic editor you might go direct ti the svg – Ewan Oct 11 at 17:49
  • @Ewan: just a remark - I found your reply only by chance, since if one writes just "db", I don't get anything in my inbox. – Doc Brown Oct 11 at 19:22

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.