Eric, in a previous thread about big data, mentioned an additional question. Does deploying a physical schema onto NoSQL make sense? Any thoughts here?
This depends on what you mean by "deploying" and what NoSQL database you are using.
If you have no physical *datamodel*, how are programmers supposed to use the database, and what to expect in it?
OTOH, there is no need to "deploy" the database FIRST, before the code that matches that database can execute. In SQL databases, there must be a prior specification of the physical structure in a data description language, which must then be "deployed" and then a new version of the code that goes agaist that version of the physical database. This model does not fit most NoSQL databases. Instead, the database structure is usually defined in the code itself, such as the creation of collections in Mongo. And further, when data element needs change, the code can insert documents in a collection that differ in whatever ways are necessary from the other documents in the collection. Additional code might then go back and revise the structure of some or all of the documents already in the collection. So, there is no *separate* deployment of the database and the code, and for object oriented languages, no impedence mismatch between the database and the code in a document oriented database.
This is the sensible meaning of "Schemaless", that the schema can change. As the very best practice, we can use any NoSQL database, say key-value, document, or graph, to model a domain and have a domain driven design, just a design that is not cast in stone. Next down the practice chain, NoSQL physical models might be organized just to optimize certain queries. But anyone who attempts to have no design for the structure of documents and their relationships to collections, but just code as it occurs, will need to be working only with a toy database.
Thank you. I hear you say that there needs to be a model of what is outputted by the NoSQL database. The schema that is inputted is the entire program, or database itself, because the schema can change upon reading the data. Practically you can model the domain in the no-SQL database but the design can change. I will think about this a bit more. I appreciate it.
Exactly, Michelle. In addition, not only may the schema for a given type of data 'record', such as a document, change, analogous to an individual Relational row changing its columns, thus creating alternative schemas for a given type of information, and not only can changes to the schema in previously added records be modified by the application software itself, in some NoSQL dbms, but also the *groupings* of records into types of things, such as Mongo "Collections" analogous to tables, can be changed and new ones added by the program, and even databases themselves may be created at run time by a program.
To my mind, this makes the responsibility to manage the data model even more necessary, for chaos can result, since one does not literally 'need' to have an explicit datamodel. It also makes the job more demading, since a "DBA" can't separately control the data model.
The good news, to me: "data architects" and programmers can't live in silos that are often at odds any more, or even neessarily be different people.