Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

Eluknow's avatar

API with Laravel and different types of datas

Hi, I'm working on a project's brief and I see I need different kind of datas. For instance, i need common datas such as users, messages... But i also manipulate datas that looks like that :

{
    "name":"name",
    "lines":[
        {"order":0,"type":"line-content","bgcolor":"rgb(247,247,247)","content":"<b>Contactez-nous<\/b> pour organiser vos \u00e9v\u00e8nements les plus fous !"},
        {"order":1,"type":"line-media","bgcolor":"rgb(255,0,55)","content":"Et une ligne en plus ! Cliquez pour modifier","title":"Titre (clic pour modifier)","position":2,"imageSrc":".\/images\/defaultright.png","link":".\/images\/defaultright.png","plus":"test.html"}
    ],
    "address":"6 Boulevard du G\u00e9n\u00e9ral Leclerc<br\/>B\u00e2timent C - 92110 Clichy","logo":".\/images\/Logo.png"
}

You see, I manipulate json arrays with sub-arrays (in the example above, "lines" is a sub-array). I will develop an API to work, but i don't manage to know how i can store these datas. Because I can't store "lines" in a table's column, but also, i don't need to create another table for "lines" because they only own to one json array ; it would create many requests for something useless.

Therefore, I had thought about doing a common database and storing these type of json arrays in files .json. But my question is, if I do that, first : is it well ? second : how will I switch between storage in db and storage in files in my models ?

Thanks a lot for reading, hope it was understandable

0 likes
6 replies
lostdreamer_nl's avatar

if the lines have a specific format :

  • line-content always has a background and a content field
  • line-media has both + title / position / imageSrc / link / plus etc.

You could still put this in the DB:

  • LineModel -> morphsTo -> LineContentModel & LineMediaModel which have their own set of fields.

Even if the fields dont have a specific format, you could use a Line model, with a json field, where you simply save the object in json format into that single field.

If you really want to go into the route of filesystem, I would take the model where these 'Lines' relate to, and put 2 methods in it, 1 to write it's lines to a bunch of files (or a single file, depending on the usecase) and 1 method to get all of its related lines.

To give a better answer I would definately need more info about the data you are trying to gather / manipulate / respond to the user and it's internal relations.

Eluknow's avatar

Thanks for your answer.

If i use "LineModel->morphsTo->...", it means that i have to create a table for each LineContent & LineMedia, didn't it ? I really believe it's not a good idea to multiply the number of tables (and so, the number of sql requests) in my case.

In fact, i will have a huge app with a lot of models including users, users_preferences, societies, estimates, bills, newsletters... Each user will be able to generate estimates, bills or newsletters. He will have a design and he will be able to modify contents, color, type of contents... And finally you receive json arrays presented above (it's the result of a generated newsletter).

I hope it will help.

lostdreamer_nl's avatar

i've made quite a number of projects where the number of rows in the db are measured in millions (and a few projects where the user count goes into those numbers) and I'd rather have any (non binary) data in the DB than on the filesystem.

The DB is basically just a layer on top of your filesystem, made for in memory relocation of data and good search capabilities. Besides that it is also made to scale easily beyond 1 physical server.

If you're only sticking with the filesystem, you're going to get into Disk IO problems a lot faster, and when the time comes to scale up to multiple servers, you're going to have to externalize that storage space as well, which is always slower than any DB.

If you don't have to query for the fields inside of those lines, I'd probably go with adding 1 model:

Line
- id (int)
- lineable_type (varchar)
- lineable_id (int)
- content (json or text)

With that single table you could add still any type of object (in json format) onto any Bill / Estimate / Invoice etc.

1 like
D9705996's avatar

@ELUKNOW - In my experience it is best if you avoid worrying about perfomance until it actually becomes an issue. I'm not advocating being sloppy but if you ensure you avoid N+1 issues (use laravel telescope for this), minimisd memory usage, index you data base correctly (use mysqltuner for diagnostics) and ensure you have enough hardware (if your server millions of records off 1 CPU and 1gb memory it's probably going to be slow).

Only once you have exhausted the easy best practice fixes start looking at caching, load balancing, etc.

You will be surprised at how much you can do with a basic setup configured correctly.

Jonathon reinink did a good laravel talk on this (I urge you to watch all the Laracon videos... they are amazing)

https://github.com/reinink/laracon2018

1 like
Eluknow's avatar

Thanks a lot guys, I now see I had some misunderstandings.

Actually I now know how to store my datas, and I also learnt more about Laravel Telescope. Plus, i watched more about Reinink. This was very helpful.

Just a last question, linked with all we said before : in order to store my datas in DB, which DBMS (hope it's the good translation for SGBD in French) do you advice me to use ? A basic mysql (MariaDB) is good, or rather a nosql like MongoDB ?

lostdreamer_nl's avatar

If you're not too experienced with MongoDB / ElasticSearch I'd suggest going with Maria / MySQL and JSON fields.

MongoDB has the nasty habit of taking every last byte on your HD if you dont watch it.

Elasticsearch is a very good match for this stuff, but You'll need to watch your schema's or the first few entries into a new Document type as it will create a schema for you based on your first data.

Both are really good at their own specifics, so I would suggest reading into them and testing them with some small side projects.

Please or to participate in this conversation.