4 ms·

Schema-less also means that you can afford to have deviations in your schemas not hinder your development needs. I agree with you, but I'd venture to say that a

by nevi-me 13y ago

Schema-less also means that you can afford to have deviations in your schemas not hinder your development needs. I agree with you, but I'd venture to say that a schema-less database means what it does, but that a collection of data always has schemas.

zAy0LfpBZLC8mAC 13y ago
No, the schema is always a property of the system as a whole, data alone doesn't have an implicit schema. The schema is the set of type constraints that data has to conform to so that it can be processed by the system. Thus, a DB being "schema-less" simply means that it won't check/enforce those constraints - the schema still is there, of course, simply because a given piece of software that does anything meaningful will not sensibly process any random piece of garbage you feed it.
- nevi-me 13y ago
  So no schema means no validation of data for conformance? I thought these "NoSQL", or rather the ones that explicitly state to be schema-less don't do such. People who take the lack of schema as the licence to throw data into a black hole are somehow misleading themselves. The purpose of a database is to store data for later retrieval and modification. Schema-less, as we both understand it, means there is little or no validation by the database. In light of what you corrected me on data, am I correct in saying that useful data at the very least has to conform to some uniformity, from which a DBA would derive a schema, even if not enforced by the database?
  - zAy0LfpBZLC8mAC 13y ago
    Yeah, that's what I meant by "the schema is still there" - "useful data" is data that has meaning according to how the system (software processing the data) interprets it. But my point is that the uniformity can not be derived from the data, but only from the interpretation rules of the software. I mean, you can, of course, derive some "rules of uniformity" from the data, but that most likely would be completely useless, as you might just find patterns in the data that emerged by chance rather than because they distinguish meaningful data from nonsense, and you might easily miss important constraints that are required to keep nonsense out of the database. Of course, sometimes you can infer from data heuristically what sensible constraints might look like (because field names have some meaning to you, for example), but that really is just a heuristic shortcut for finding out how the system interprets the data.

by nevi-me 13y ago

zAy0LfpBZLC8mAC 13y ago

No, the schema is always a property of the system as a whole, data alone doesn't have an implicit schema. The schema is the set of type constraints that data has to conform to so that it can be processed by the system. Thus, a DB being "schema-less" simply means that it won't check/enforce those constraints - the schema still is there, of course, simply because a given piece of software that does anything meaningful will not sensibly process any random piece of garbage you feed it.

nevi-me 13y ago
So no schema means no validation of data for conformance? I thought these "NoSQL", or rather the ones that explicitly state to be schema-less don't do such. People who take the lack of schema as the licence to throw data into a black hole are somehow misleading themselves. The purpose of a database is to store data for later retrieval and modification. Schema-less, as we both understand it, means there is little or no validation by the database. In light of what you corrected me on data, am I correct in saying that useful data at the very least has to conform to some uniformity, from which a DBA would derive a schema, even if not enforced by the database?
- zAy0LfpBZLC8mAC 13y ago
  Yeah, that's what I meant by "the schema is still there" - "useful data" is data that has meaning according to how the system (software processing the data) interprets it. But my point is that the uniformity can not be derived from the data, but only from the interpretation rules of the software. I mean, you can, of course, derive some "rules of uniformity" from the data, but that most likely would be completely useless, as you might just find patterns in the data that emerged by chance rather than because they distinguish meaningful data from nonsense, and you might easily miss important constraints that are required to keep nonsense out of the database. Of course, sometimes you can infer from data heuristically what sensible constraints might look like (because field names have some meaning to you, for example), but that really is just a heuristic shortcut for finding out how the system interprets the data.