What does being schema-less mean for a NoSQL Database?
Schemaless is a term that is currently floating around in the NoSql world.
- What does this mean ?
- I have a document with 3 properties today and I move to production with it, then what happens to my data when I need to add 2 more properties to my document?
- Is this purely a migrations problem where I need to manage my data migration or can a NoSql database create as much friction as a RDBMS or make it easier in someway ?
nosql schema
asked Mar 23 '13 at 16:33
ashutosh rainaashutosh raina
4,66793478
add a comment |
Schemaless is a term that is currently floating around in the NoSql world.
- What does this mean ?
- I have a document with 3 properties today and I move to production with it, then what happens to my data when I need to add 2 more properties to my document?
- Is this purely a migrations problem where I need to manage my data migration or can a NoSql database create as much friction as a RDBMS or make it easier in someway ?
nosql schema
asked Mar 23 '13 at 16:33
ashutosh rainaashutosh raina
4,66793478
"schemaless" is a marketing slang for saying that there is no specific helper to altering the schema. There is no 'ALTER' function per se.
– amirouche
Jun 26 '18 at 21:13
add a comment |
Schemaless is a term that is currently floating around in the NoSql world.
- What does this mean ?
- I have a document with 3 properties today and I move to production with it, then what happens to my data when I need to add 2 more properties to my document?
- Is this purely a migrations problem where I need to manage my data migration or can a NoSql database create as much friction as a RDBMS or make it easier in someway ?
nosql schema
asked Mar 23 '13 at 16:33
ashutosh rainaashutosh raina
4,66793478
Schemaless is a term that is currently floating around in the NoSql world.
- What does this mean ?
- I have a document with 3 properties today and I move to production with it, then what happens to my data when I need to add 2 more properties to my document?
- Is this purely a migrations problem where I need to manage my data migration or can a NoSql database create as much friction as a RDBMS or make it easier in someway ?
nosql schema
nosql schema
asked Mar 23 '13 at 16:33
ashutosh rainaashutosh raina
4,66793478
asked Mar 23 '13 at 16:33
ashutosh rainaashutosh raina
4,66793478
asked Mar 23 '13 at 16:33
ashutosh rainaashutosh raina
4,66793478
asked Mar 23 '13 at 16:33
ashutosh rainaashutosh raina
4,66793478
asked Mar 23 '13 at 16:33
ashutosh rainaashutosh raina
4,66793478
4,66793478
"schemaless" is a marketing slang for saying that there is no specific helper to altering the schema. There is no 'ALTER' function per se.
– amirouche
Jun 26 '18 at 21:13
add a comment |
"schemaless" is a marketing slang for saying that there is no specific helper to altering the schema. There is no 'ALTER' function per se.
– amirouche
Jun 26 '18 at 21:13
"schemaless" is a marketing slang for saying that there is no specific helper to altering the schema. There is no 'ALTER' function per se.
– amirouche
Jun 26 '18 at 21:13
"schemaless" is a marketing slang for saying that there is no specific helper to altering the schema. There is no 'ALTER' function per se.
– amirouche
Jun 26 '18 at 21:13
add a comment |
2 Answers
2
active
oldest
votes
Schema-less is a bit of a misnomer, it's better to think of it as:
- SQL = Schema enforced by a RDBMS on Write
- NoSQL = Partial Schema enforced by the DBMS on Write, PLUS schema fully enforced by the Application on Read (Externalised
schema)
So while a supposed Schema-less NoSQL data-store will in theory allow you to store any data you like (typically key value pairs, in a document) without prior knowledge of the keys, or data types, it will be pointless unless you have some mechanism to retrieve and use the data. So essentially the schema is partially moved from the RDBMS into the application code. I say partially as you'll have added Indexes to document collections and or partitioned the data for performance, so the NoSQL DBMS will have a partial schema defined locally, and possibly enforced via Unique constraints.
As to adding additional attributes to a document/object in the store. Depending on how much padding is around the document (un-used space), in it's physical data block, adding a few more key value pairs to the documents may result in the document having to be physically moved to a larger contiguous block of storage, and the associated indexes re-built. If you plan to use the new keys in a frequently utilised query then you'll be wanting to also add a suitable new index, which will obviously require some physical storage, take a while to initially build and possibly lead you to ask the sysadmin to allocate more memory to the DBMS, to allow the new index(s) to be cached.
answered Mar 23 '13 at 16:58
arober11arober11
1,5741225
Good point about space allocation. But specifically for point 2 & 3 , how do I manage the data w.r.t to data migration ? Is a NoSQl product smart enough to detect changes which are incremental and non-breaking v/s breaking ?
– ashutosh raina
Mar 23 '13 at 17:49
2
Depends on the product, but generally if you want to add additional attributes/keys to a document all you need to do is change your application code to store / utilise the new key value pairs. The DBMS dosen't care about what's stored in a document if it isn't to be indexed, and assuming there's enough space allocated for each document, such that the DBMS dosen't have to restructure it's back end.
– arober11
Mar 23 '13 at 18:36
So we need to account for possible increase in document size before hand ?
– ashutosh raina
Mar 23 '13 at 19:06
If you know it's going to grow then it may be worth increasing the padding, but this obviously depends on the size of the collection, rate of growth, how critical response times are,...... As most NoSQL DBMS systems will happily move data and re-index on update, but that does have an overhead, so if you allow a bit of free space in each document there will be less moving / re-indexing. Then again if the database is small the DBMS will have shuffled everything before anyone starts to moan about laggy updates.
– arober11
Mar 23 '13 at 19:57
@arober11 thanks for such an awesome answer. I have really understood the confusion that's around mongodb being schemaless
– hershey92
Aug 2 '13 at 16:22
|
show 2 more comments
A bit late in the day but while searching on the topic again I found this article
http://tech.pro/tutorial/1189/basics-of-ravendb-nosql
Refer to section 3 in the article, I will quote it again for ease.
Adding and changing data models to RavenDB couldn't be simpler. Since
it is a NoSQL database, it can handle additions and deletions to your
models very simply. If a property is added to your class, it will be
set to the default value of that type. If a property is deleted, then
upon deserialization that value will be ignored. No more futzing with
SQL Scripts.
This seems to be the logical answer for RavenDB.
answered Apr 4 '13 at 18:49
ashutosh rainaashutosh raina
4,66793478
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f15589184%2fwhat-does-being-schema-less-mean-for-a-nosql-database%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Schema-less is a bit of a misnomer, it's better to think of it as:
- SQL = Schema enforced by a RDBMS on Write
- NoSQL = Partial Schema enforced by the DBMS on Write, PLUS schema fully enforced by the Application on Read (Externalised
schema)
So while a supposed Schema-less NoSQL data-store will in theory allow you to store any data you like (typically key value pairs, in a document) without prior knowledge of the keys, or data types, it will be pointless unless you have some mechanism to retrieve and use the data. So essentially the schema is partially moved from the RDBMS into the application code. I say partially as you'll have added Indexes to document collections and or partitioned the data for performance, so the NoSQL DBMS will have a partial schema defined locally, and possibly enforced via Unique constraints.
As to adding additional attributes to a document/object in the store. Depending on how much padding is around the document (un-used space), in it's physical data block, adding a few more key value pairs to the documents may result in the document having to be physically moved to a larger contiguous block of storage, and the associated indexes re-built. If you plan to use the new keys in a frequently utilised query then you'll be wanting to also add a suitable new index, which will obviously require some physical storage, take a while to initially build and possibly lead you to ask the sysadmin to allocate more memory to the DBMS, to allow the new index(s) to be cached.
answered Mar 23 '13 at 16:58
arober11arober11
1,5741225
Good point about space allocation. But specifically for point 2 & 3 , how do I manage the data w.r.t to data migration ? Is a NoSQl product smart enough to detect changes which are incremental and non-breaking v/s breaking ?
– ashutosh raina
Mar 23 '13 at 17:49
2
Depends on the product, but generally if you want to add additional attributes/keys to a document all you need to do is change your application code to store / utilise the new key value pairs. The DBMS dosen't care about what's stored in a document if it isn't to be indexed, and assuming there's enough space allocated for each document, such that the DBMS dosen't have to restructure it's back end.
– arober11
Mar 23 '13 at 18:36
So we need to account for possible increase in document size before hand ?
– ashutosh raina
Mar 23 '13 at 19:06
If you know it's going to grow then it may be worth increasing the padding, but this obviously depends on the size of the collection, rate of growth, how critical response times are,...... As most NoSQL DBMS systems will happily move data and re-index on update, but that does have an overhead, so if you allow a bit of free space in each document there will be less moving / re-indexing. Then again if the database is small the DBMS will have shuffled everything before anyone starts to moan about laggy updates.
– arober11
Mar 23 '13 at 19:57
@arober11 thanks for such an awesome answer. I have really understood the confusion that's around mongodb being schemaless
– hershey92
Aug 2 '13 at 16:22
|
show 2 more comments
Schema-less is a bit of a misnomer, it's better to think of it as:
- SQL = Schema enforced by a RDBMS on Write
- NoSQL = Partial Schema enforced by the DBMS on Write, PLUS schema fully enforced by the Application on Read (Externalised
schema)
So while a supposed Schema-less NoSQL data-store will in theory allow you to store any data you like (typically key value pairs, in a document) without prior knowledge of the keys, or data types, it will be pointless unless you have some mechanism to retrieve and use the data. So essentially the schema is partially moved from the RDBMS into the application code. I say partially as you'll have added Indexes to document collections and or partitioned the data for performance, so the NoSQL DBMS will have a partial schema defined locally, and possibly enforced via Unique constraints.
As to adding additional attributes to a document/object in the store. Depending on how much padding is around the document (un-used space), in it's physical data block, adding a few more key value pairs to the documents may result in the document having to be physically moved to a larger contiguous block of storage, and the associated indexes re-built. If you plan to use the new keys in a frequently utilised query then you'll be wanting to also add a suitable new index, which will obviously require some physical storage, take a while to initially build and possibly lead you to ask the sysadmin to allocate more memory to the DBMS, to allow the new index(s) to be cached.
answered Mar 23 '13 at 16:58
arober11arober11
1,5741225
Good point about space allocation. But specifically for point 2 & 3 , how do I manage the data w.r.t to data migration ? Is a NoSQl product smart enough to detect changes which are incremental and non-breaking v/s breaking ?
– ashutosh raina
Mar 23 '13 at 17:49
2
Depends on the product, but generally if you want to add additional attributes/keys to a document all you need to do is change your application code to store / utilise the new key value pairs. The DBMS dosen't care about what's stored in a document if it isn't to be indexed, and assuming there's enough space allocated for each document, such that the DBMS dosen't have to restructure it's back end.
– arober11
Mar 23 '13 at 18:36
So we need to account for possible increase in document size before hand ?
– ashutosh raina
Mar 23 '13 at 19:06
If you know it's going to grow then it may be worth increasing the padding, but this obviously depends on the size of the collection, rate of growth, how critical response times are,...... As most NoSQL DBMS systems will happily move data and re-index on update, but that does have an overhead, so if you allow a bit of free space in each document there will be less moving / re-indexing. Then again if the database is small the DBMS will have shuffled everything before anyone starts to moan about laggy updates.
– arober11
Mar 23 '13 at 19:57
@arober11 thanks for such an awesome answer. I have really understood the confusion that's around mongodb being schemaless
– hershey92
Aug 2 '13 at 16:22
|
show 2 more comments
Schema-less is a bit of a misnomer, it's better to think of it as:
- SQL = Schema enforced by a RDBMS on Write
- NoSQL = Partial Schema enforced by the DBMS on Write, PLUS schema fully enforced by the Application on Read (Externalised
schema)
So while a supposed Schema-less NoSQL data-store will in theory allow you to store any data you like (typically key value pairs, in a document) without prior knowledge of the keys, or data types, it will be pointless unless you have some mechanism to retrieve and use the data. So essentially the schema is partially moved from the RDBMS into the application code. I say partially as you'll have added Indexes to document collections and or partitioned the data for performance, so the NoSQL DBMS will have a partial schema defined locally, and possibly enforced via Unique constraints.
As to adding additional attributes to a document/object in the store. Depending on how much padding is around the document (un-used space), in it's physical data block, adding a few more key value pairs to the documents may result in the document having to be physically moved to a larger contiguous block of storage, and the associated indexes re-built. If you plan to use the new keys in a frequently utilised query then you'll be wanting to also add a suitable new index, which will obviously require some physical storage, take a while to initially build and possibly lead you to ask the sysadmin to allocate more memory to the DBMS, to allow the new index(s) to be cached.
answered Mar 23 '13 at 16:58
arober11arober11
1,5741225
Schema-less is a bit of a misnomer, it's better to think of it as:
- SQL = Schema enforced by a RDBMS on Write
- NoSQL = Partial Schema enforced by the DBMS on Write, PLUS schema fully enforced by the Application on Read (Externalised
schema)
So while a supposed Schema-less NoSQL data-store will in theory allow you to store any data you like (typically key value pairs, in a document) without prior knowledge of the keys, or data types, it will be pointless unless you have some mechanism to retrieve and use the data. So essentially the schema is partially moved from the RDBMS into the application code. I say partially as you'll have added Indexes to document collections and or partitioned the data for performance, so the NoSQL DBMS will have a partial schema defined locally, and possibly enforced via Unique constraints.
As to adding additional attributes to a document/object in the store. Depending on how much padding is around the document (un-used space), in it's physical data block, adding a few more key value pairs to the documents may result in the document having to be physically moved to a larger contiguous block of storage, and the associated indexes re-built. If you plan to use the new keys in a frequently utilised query then you'll be wanting to also add a suitable new index, which will obviously require some physical storage, take a while to initially build and possibly lead you to ask the sysadmin to allocate more memory to the DBMS, to allow the new index(s) to be cached.
answered Mar 23 '13 at 16:58
arober11arober11
1,5741225
edited Mar 23 '13 at 18:35
answered Mar 23 '13 at 16:58
arober11arober11
1,5741225
answered Mar 23 '13 at 16:58
arober11arober11
1,5741225
answered Mar 23 '13 at 16:58
arober11arober11
1,5741225
1,5741225
Good point about space allocation. But specifically for point 2 & 3 , how do I manage the data w.r.t to data migration ? Is a NoSQl product smart enough to detect changes which are incremental and non-breaking v/s breaking ?
– ashutosh raina
Mar 23 '13 at 17:49
2
Depends on the product, but generally if you want to add additional attributes/keys to a document all you need to do is change your application code to store / utilise the new key value pairs. The DBMS dosen't care about what's stored in a document if it isn't to be indexed, and assuming there's enough space allocated for each document, such that the DBMS dosen't have to restructure it's back end.
– arober11
Mar 23 '13 at 18:36
So we need to account for possible increase in document size before hand ?
– ashutosh raina
Mar 23 '13 at 19:06
If you know it's going to grow then it may be worth increasing the padding, but this obviously depends on the size of the collection, rate of growth, how critical response times are,...... As most NoSQL DBMS systems will happily move data and re-index on update, but that does have an overhead, so if you allow a bit of free space in each document there will be less moving / re-indexing. Then again if the database is small the DBMS will have shuffled everything before anyone starts to moan about laggy updates.
– arober11
Mar 23 '13 at 19:57
@arober11 thanks for such an awesome answer. I have really understood the confusion that's around mongodb being schemaless
– hershey92
Aug 2 '13 at 16:22
|
show 2 more comments
Good point about space allocation. But specifically for point 2 & 3 , how do I manage the data w.r.t to data migration ? Is a NoSQl product smart enough to detect changes which are incremental and non-breaking v/s breaking ?
– ashutosh raina
Mar 23 '13 at 17:49
2
Depends on the product, but generally if you want to add additional attributes/keys to a document all you need to do is change your application code to store / utilise the new key value pairs. The DBMS dosen't care about what's stored in a document if it isn't to be indexed, and assuming there's enough space allocated for each document, such that the DBMS dosen't have to restructure it's back end.
– arober11
Mar 23 '13 at 18:36
So we need to account for possible increase in document size before hand ?
– ashutosh raina
Mar 23 '13 at 19:06
If you know it's going to grow then it may be worth increasing the padding, but this obviously depends on the size of the collection, rate of growth, how critical response times are,...... As most NoSQL DBMS systems will happily move data and re-index on update, but that does have an overhead, so if you allow a bit of free space in each document there will be less moving / re-indexing. Then again if the database is small the DBMS will have shuffled everything before anyone starts to moan about laggy updates.
– arober11
Mar 23 '13 at 19:57
@arober11 thanks for such an awesome answer. I have really understood the confusion that's around mongodb being schemaless
– hershey92
Aug 2 '13 at 16:22
Good point about space allocation. But specifically for point 2 & 3 , how do I manage the data w.r.t to data migration ? Is a NoSQl product smart enough to detect changes which are incremental and non-breaking v/s breaking ?
– ashutosh raina
Mar 23 '13 at 17:49
Good point about space allocation. But specifically for point 2 & 3 , how do I manage the data w.r.t to data migration ? Is a NoSQl product smart enough to detect changes which are incremental and non-breaking v/s breaking ?
– ashutosh raina
Mar 23 '13 at 17:49
2
2
Depends on the product, but generally if you want to add additional attributes/keys to a document all you need to do is change your application code to store / utilise the new key value pairs. The DBMS dosen't care about what's stored in a document if it isn't to be indexed, and assuming there's enough space allocated for each document, such that the DBMS dosen't have to restructure it's back end.
– arober11
Mar 23 '13 at 18:36
Depends on the product, but generally if you want to add additional attributes/keys to a document all you need to do is change your application code to store / utilise the new key value pairs. The DBMS dosen't care about what's stored in a document if it isn't to be indexed, and assuming there's enough space allocated for each document, such that the DBMS dosen't have to restructure it's back end.
– arober11
Mar 23 '13 at 18:36
So we need to account for possible increase in document size before hand ?
– ashutosh raina
Mar 23 '13 at 19:06
So we need to account for possible increase in document size before hand ?
– ashutosh raina
Mar 23 '13 at 19:06
If you know it's going to grow then it may be worth increasing the padding, but this obviously depends on the size of the collection, rate of growth, how critical response times are,...... As most NoSQL DBMS systems will happily move data and re-index on update, but that does have an overhead, so if you allow a bit of free space in each document there will be less moving / re-indexing. Then again if the database is small the DBMS will have shuffled everything before anyone starts to moan about laggy updates.
– arober11
Mar 23 '13 at 19:57
If you know it's going to grow then it may be worth increasing the padding, but this obviously depends on the size of the collection, rate of growth, how critical response times are,...... As most NoSQL DBMS systems will happily move data and re-index on update, but that does have an overhead, so if you allow a bit of free space in each document there will be less moving / re-indexing. Then again if the database is small the DBMS will have shuffled everything before anyone starts to moan about laggy updates.
– arober11
Mar 23 '13 at 19:57
@arober11 thanks for such an awesome answer. I have really understood the confusion that's around mongodb being schemaless
– hershey92
Aug 2 '13 at 16:22
@arober11 thanks for such an awesome answer. I have really understood the confusion that's around mongodb being schemaless
– hershey92
Aug 2 '13 at 16:22
|
show 2 more comments
A bit late in the day but while searching on the topic again I found this article
http://tech.pro/tutorial/1189/basics-of-ravendb-nosql
Refer to section 3 in the article, I will quote it again for ease.
Adding and changing data models to RavenDB couldn't be simpler. Since
it is a NoSQL database, it can handle additions and deletions to your
models very simply. If a property is added to your class, it will be
set to the default value of that type. If a property is deleted, then
upon deserialization that value will be ignored. No more futzing with
SQL Scripts.
This seems to be the logical answer for RavenDB.
answered Apr 4 '13 at 18:49
ashutosh rainaashutosh raina
4,66793478
add a comment |
A bit late in the day but while searching on the topic again I found this article
http://tech.pro/tutorial/1189/basics-of-ravendb-nosql
Refer to section 3 in the article, I will quote it again for ease.
Adding and changing data models to RavenDB couldn't be simpler. Since
it is a NoSQL database, it can handle additions and deletions to your
models very simply. If a property is added to your class, it will be
set to the default value of that type. If a property is deleted, then
upon deserialization that value will be ignored. No more futzing with
SQL Scripts.
This seems to be the logical answer for RavenDB.
answered Apr 4 '13 at 18:49
ashutosh rainaashutosh raina
4,66793478
add a comment |
A bit late in the day but while searching on the topic again I found this article
http://tech.pro/tutorial/1189/basics-of-ravendb-nosql
Refer to section 3 in the article, I will quote it again for ease.
Adding and changing data models to RavenDB couldn't be simpler. Since
it is a NoSQL database, it can handle additions and deletions to your
models very simply. If a property is added to your class, it will be
set to the default value of that type. If a property is deleted, then
upon deserialization that value will be ignored. No more futzing with
SQL Scripts.
This seems to be the logical answer for RavenDB.
answered Apr 4 '13 at 18:49
ashutosh rainaashutosh raina
4,66793478
A bit late in the day but while searching on the topic again I found this article
http://tech.pro/tutorial/1189/basics-of-ravendb-nosql
Refer to section 3 in the article, I will quote it again for ease.
Adding and changing data models to RavenDB couldn't be simpler. Since
it is a NoSQL database, it can handle additions and deletions to your
models very simply. If a property is added to your class, it will be
set to the default value of that type. If a property is deleted, then
upon deserialization that value will be ignored. No more futzing with
SQL Scripts.
This seems to be the logical answer for RavenDB.
answered Apr 4 '13 at 18:49
ashutosh rainaashutosh raina
4,66793478
answered Apr 4 '13 at 18:49
ashutosh rainaashutosh raina
4,66793478
answered Apr 4 '13 at 18:49
ashutosh rainaashutosh raina
4,66793478
answered Apr 4 '13 at 18:49
ashutosh rainaashutosh raina
4,66793478
4,66793478
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f15589184%2fwhat-does-being-schema-less-mean-for-a-nosql-database%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
"schemaless" is a marketing slang for saying that there is no specific helper to altering the schema. There is no 'ALTER' function per se.
– amirouche
Jun 26 '18 at 21:13