json encode and append to current form submission request

@SilenceBringer thanks for reply. I made this in model:

   protected $casts = [
        'fields' => 'array',
    ];

but i still get same result on dd($request->all());

  "field_855" => "Sunt et quaerat esse"
  "field_856" => "Dolorem excepteur of"
  "fields" => array:2 [▼
    "field_857" => array:6 [▶]
    "field_858" => array:6 [▶]

This controller was previously written by someone which saves data if the response has field_suffix followed by id, for example field_855 and field_856 are saved in db since they are in field_id format. so I want to make similar format for fields array

  "field_855" => "Sunt et quaerat esse"
  "field_856" => "Dolorem excepteur of"
filed_857=>[{store as json}],
field_858=>[{store as json}]

@martinbean I agree.

Json columns are in my opinion a bad practice and should be used sparingly. You might think you save a bit of typing in your migration but you will type way more in your controllers and models. Definately not worth the hassle.

@jlrdw I agree. I would use it only temporarily if you get lots of data from an api and then to save time process it with a job and then store it in a regular table. This is a pretty good way to keep track of what has been received and for debugging purposes.

@david001 You are obviously not listening to us at all.

It a table you have field names

• id
• last_name
• first_name
• country
• city
• state

and so on.

When the request is submitted from you form you have names on those form inputs

<form action="/users" method="post">
  <input type="text" name="first_name">
  <input type="text" name="last_name">
<!-- and so on -->	
</form>

So in your controller you just validate preferably using a form request class

It could look something like this

class UserFormRequest extends FormRequest
{
    public function rules()
    {
        $rules = [
            'last_name' => 'required',
            'first_name' => 'required',
			'country' => 'required'
			//and so on
        ];

        return $rules;
    }
}

The your store method would look something like

public function store(UserFormRequest $request)
    {
       $user =  User::create($request->validated());
        return redirect(route('users.index'))->withStatus($user->name . ' successfully added.');
    }

All form fields in the html and all the fields in the table should have proper names not just field_20. If you store the date of birth of the user it should be named date_of_birth or maybe dob since it's a pretty standard acronym.

If you think that you have too many fields then you can alway break some of the fields into another table.

While using json might appear as a quick solution now, it surely will not be quick in the long run.

It will also affect the performance of the database since you can't really index a json column.

Let just say that you want to get a list of all the users that have their birthday between two dates.

This is pretty easy to do with a regular field and if you have thousands of users it will slow down and to speed it back up again you add an index one the date of birth field.

To do something similar for a json column you need to use stored generated columns which I don't think is supported by laravel's migration.

https://stackoverflow.com/questions/38389075/how-to-create-index-on-json-column-in-mysql

So basically you still need to create every single field anyway in your migration or at least the ones you need to index.

This is my last attempt to make you understand that json columns might seem like a simple and good solution but it's generally not a good one or a simple one. There are no shortcuts to a good database design and that a bad decision now will affect your application in for a long time. It's much better to make a good design now that scales well and can be made more performant in more ways than just throwing money at the problem. You also need to think a bit about the future. I a year new demands or needs has been requested from the users and you need to extract/add/remove/modify some part of the application.

Let's just say that the fields 857 and 858 are getting so big that your json field your application gets so slow when you try to do any type of crud and you need to extract it to it's own table for performance. Then you have your work cut out for you and you will curse yourself for not listening when several of the people on this forum cautioned you from using json.

I also suggest the you read the best answer on this stackoverflow thread

https://stackoverflow.com/questions/33437940/json-column-or-traditional-columns

@Tray2 thanks for clear explanation!

so how do i know uk is country, Newcastle is city and 3030 is postcode

@david001 As someone who lives in Newcastle, UK, I can tell you with confidence that “3033” is not a postcode. It’s not a postcode for anywhere in the UK 🙂