Serialization vs. Materialization

Question

Can someone pin-point the differences (if there are) and when the use of each term is appropriate?

For example, when dealing with Object/Relational Mappers (ORM), the object creation involves Materialization, whereas objects creation using Json/Xml formats is considered as Deserialization.

I can think of some core differences, but i'm curious to see whether there is more formal definition of the terms as i was unable to find one.

Answer 1

"Deserialization" is used almost exclusively in pair with "Serialization". These terms describe a "workflow" when your objects or graph of objects is fully transformed into a "stream of data" to be stored i.e. as a file or a single database record. usually single. Then, at some point of time it is retrieved and "deserialized", so "unpacked" back into object or graph of objects. They are used in pairs. If you ever said that your XYZ object got serialized, then, later it will get deserialized. Strive to not use the 'deserialize' word when your object is stored in a way that cannot be called 'serialized'.

The keyword here is "serial". De'serial'ization. Serial form data, a data stream. A file (txt, bin, xml, whatever: file), a BLOB in DB, etc.

"Materialization" describes an abstract "process" that translates "query description" and "raw data" in whatever shape into some "usable data" that matches the query. It is more general than 'de/serialization'. The latter almost always expicitely mean that the object(s) are meant to be "unpacked" from some stream-like data, where as "materialization" means that the objects are reconstructed from any suitable/available description.

The keyword here is, well.. materialization. At one point you have 'abstract idea' which gets 'materialized' into concrete form at some point of time.

"Materialization" is used in scope of querying-and-analyzing the data. When you build a query, you can define some source, filters, aggregations, projections etc. But, very often you cannot "just build the query" as a whole at one time or place in code. So, your query will get built in parts. But, some parts of the query may be already well formatted and executable and just passed to be extended. It remains a "definition", abstract thing, not "materialized" yet. Later, at some point of time your query will be executed and the results fetched. The results will be now 'materialized' and readable, in opposite to earlier state when you just had a 'query' that was still only 'prepared'. Now connect it to ORMs and their custom ways of defining mappings between classes and tables, and custom ways of expressing filters, etc..

Ironically, I do not happen to see a term "dematerialization", which should mean an abstract way to break the object(s) apart and store them somewhow. Probably it sounds too odd like it were to be deleted. People tend to use the word 'serialize' a bit improperly or just "save/store/write" instead, which sometimes can add some confusion. So, you may hear sometimes that people use ORM and "serialize the object" to the DB into fifteen columns over three tables, but well.. I think that's not strictly a serialization.