While I am wishing to eventually change to a more recent, lighter, and/or faster DBMS (like the appropriately-named lightweight SQLite or even the document-based Mongo- the second which wouldn't present this problem), I'm presently adhering towards the standard MySQL system. Though I recognize that any response to this might be among opinion, I am wondering how you might store serialized data for example an assortment or hash-map in one column of the MySQL [or else relational-based] database. Most data access could be performed via PHP, but I must store data inside a standard format (i.e. JSON or binary hash-map- ideally the second) as opposed to the plain-text from the left PHP array. The reason behind this really is which i may carry out some data queries from Python, a put together C/C++ application, or even the command line.

Thanks.

Admonishment: this really is my estimation only.

If you're planning to question the information from means apart from the main one storing it (e.g. store from PHP, query from C/C++ as well as command line), I'd strongly discourage you against storing the whole data structure in a single column. Rather, I recommend creating your computer data model to higher support your queries (e.g. store a hashmap as some title/value pairs planned towards the id from the hashmap). Then produce a model layer within the code to cope with conversion between your code layer and also the database layer.

When you really need to keep the information in to the database, out of your PHP code, simply call corresponding techniques/functions inside your model layer, passing the hashmap. When you really need to load the information in the DB, call the related techniques/functions within the model layer passing ID from the hashmap (or regardless of the relevant identifier is) - and obtain the hashmap back.

By doing this, besides which makes it much-much simpler to question the information later, if/whenever you alter the database engine, all you will have to do would be to update a couple of techniques/functions inside your model layer.

If you wish to store JSON inside your MySQL, you may think about using some document store like MongoDB, due to the fact individuals database engines can make queries with the documents.

For instance, should you store your JSON in format and need to get all documents where B='realvalueB', you would need to get all rows, convert these to php objects with json_decode making evaluations...however, if you are using MongoDb, you'd create a query: db.myobjects.find() also it would return only matched up documents. It was only a simple illustration of why it is best. You'll find here and here you skill with mongodb queries.

So, in case your json documents contain some helpful information and you will filter with that info, it might be better to choose document store.

Should you opt for MySQL (since it is elderly, you're more acquainted with it etc.) it is good to choose "real" relational model, but you could put some stuff within the blob in case your use cases permit you to achieve this.

I would not store it whatsoever.
Rather than doing this type of strange and apparently useless factor I'd try to create a relational model from the data. It had been done many occasions before noSQL era but can be achieved once more.

Also, I see no reason in beginning with MySQL (or SQLite the same in each and every way beside reliability) if you're planning to maneuver to document-based Mongo.
In my experience, there's not single [sensible] reason to begin a task with inappropriate storage, put some efforts inside it, and finally rewrite from scratch.