MongoDB document or model planning, best
-
I'll admit I'm terrible at database planning or design, architecture. I finally got my Angular 6 working, folders and files set, navbars and footers and I'm on seeding MongoDB. In EF DAL, I was never able to figure out how to make relationships. Another topic later in the future. But in MongoDB it looks pretty easy. Past I would create a table called Countries and another table called states, and use a join to link them. In MongoDB, I can add a field called states. Should I proceed in the using country model and add the states to that. Or populate the states separately, and use the country ID's to link them? I'm looking for best practice here, and perhaps NoSQL is different than SQL in terms of planning and design. I'm not sure what the future holds for me here, in terms of actually using Countries and States in drop downs.
public class WEBSITE_COUNTRIES
{
[BsonId]
[BsonRepresentation(BsonType.ObjectId)]
public ObjectId InternalId { get; set; }public string Id { get; set; } public string LongName { get; set; } public string ShortName { get; set; } public bool Enabled { get; set; } public WEBSITE\_STATES States { get; set; }}
public class WEBSITE_STATES
{
[BsonId]
[BsonRepresentation(BsonType.ObjectId)]
public ObjectId InternalId { get; set; }
public string StateId { get; set; }
public string CountryCodee { get; set; }
public string LongName { get; set; }
public string ShortName { get; set; }
public bool Enabled { get; set; }}
If it ain't broke don't fix it Discover my world at jkirkerx.com
-
I'll admit I'm terrible at database planning or design, architecture. I finally got my Angular 6 working, folders and files set, navbars and footers and I'm on seeding MongoDB. In EF DAL, I was never able to figure out how to make relationships. Another topic later in the future. But in MongoDB it looks pretty easy. Past I would create a table called Countries and another table called states, and use a join to link them. In MongoDB, I can add a field called states. Should I proceed in the using country model and add the states to that. Or populate the states separately, and use the country ID's to link them? I'm looking for best practice here, and perhaps NoSQL is different than SQL in terms of planning and design. I'm not sure what the future holds for me here, in terms of actually using Countries and States in drop downs.
public class WEBSITE_COUNTRIES
{
[BsonId]
[BsonRepresentation(BsonType.ObjectId)]
public ObjectId InternalId { get; set; }public string Id { get; set; } public string LongName { get; set; } public string ShortName { get; set; } public bool Enabled { get; set; } public WEBSITE\_STATES States { get; set; }}
public class WEBSITE_STATES
{
[BsonId]
[BsonRepresentation(BsonType.ObjectId)]
public ObjectId InternalId { get; set; }
public string StateId { get; set; }
public string CountryCodee { get; set; }
public string LongName { get; set; }
public string ShortName { get; set; }
public bool Enabled { get; set; }}
If it ain't broke don't fix it Discover my world at jkirkerx.com
States should have a reference to country. I would suggest that you reverse the meaning of 'InternalId' and 'Id'. Most tables will have an 'Id' (what you are calling 'InternalId') but will not have the other. You should call your current 'Id' something like 'DisplayId'.
-
I'll admit I'm terrible at database planning or design, architecture. I finally got my Angular 6 working, folders and files set, navbars and footers and I'm on seeding MongoDB. In EF DAL, I was never able to figure out how to make relationships. Another topic later in the future. But in MongoDB it looks pretty easy. Past I would create a table called Countries and another table called states, and use a join to link them. In MongoDB, I can add a field called states. Should I proceed in the using country model and add the states to that. Or populate the states separately, and use the country ID's to link them? I'm looking for best practice here, and perhaps NoSQL is different than SQL in terms of planning and design. I'm not sure what the future holds for me here, in terms of actually using Countries and States in drop downs.
public class WEBSITE_COUNTRIES
{
[BsonId]
[BsonRepresentation(BsonType.ObjectId)]
public ObjectId InternalId { get; set; }public string Id { get; set; } public string LongName { get; set; } public string ShortName { get; set; } public bool Enabled { get; set; } public WEBSITE\_STATES States { get; set; }}
public class WEBSITE_STATES
{
[BsonId]
[BsonRepresentation(BsonType.ObjectId)]
public ObjectId InternalId { get; set; }
public string StateId { get; set; }
public string CountryCodee { get; set; }
public string LongName { get; set; }
public string ShortName { get; set; }
public bool Enabled { get; set; }}
If it ain't broke don't fix it Discover my world at jkirkerx.com
Disclaimer: I have only played around with MongoDB for fun. No real application experience yet. One of the things I had read about a document based DB is to identify the aggregate. An aggregate will be a complete record. In your case, country on its own is not complete as it needs states as well. So, I would have a single document with something like this:
{
"_id": "DB generated Id",
"Name": "Country Name",
"States": [{
"Name": "State 1"
}, {
"Name": "State 2"
}]
}Now, if states on themselves are a complete record, then another document to hold state list can be used. This will lead to duplication which is absolutely fine AFAIK in NoSQL World.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[^]
-
I'll admit I'm terrible at database planning or design, architecture. I finally got my Angular 6 working, folders and files set, navbars and footers and I'm on seeding MongoDB. In EF DAL, I was never able to figure out how to make relationships. Another topic later in the future. But in MongoDB it looks pretty easy. Past I would create a table called Countries and another table called states, and use a join to link them. In MongoDB, I can add a field called states. Should I proceed in the using country model and add the states to that. Or populate the states separately, and use the country ID's to link them? I'm looking for best practice here, and perhaps NoSQL is different than SQL in terms of planning and design. I'm not sure what the future holds for me here, in terms of actually using Countries and States in drop downs.
public class WEBSITE_COUNTRIES
{
[BsonId]
[BsonRepresentation(BsonType.ObjectId)]
public ObjectId InternalId { get; set; }public string Id { get; set; } public string LongName { get; set; } public string ShortName { get; set; } public bool Enabled { get; set; } public WEBSITE\_STATES States { get; set; }}
public class WEBSITE_STATES
{
[BsonId]
[BsonRepresentation(BsonType.ObjectId)]
public ObjectId InternalId { get; set; }
public string StateId { get; set; }
public string CountryCodee { get; set; }
public string LongName { get; set; }
public string ShortName { get; set; }
public bool Enabled { get; set; }}
If it ain't broke don't fix it Discover my world at jkirkerx.com
Disclaimer: this approach is rooted in Domain Driven Design, which is a common approach to NoSQL structuring. This is a super-rough look at entities vs value types in DDD. I'm generally in agreement with @lw@zi, but it depends on your use case of states. If a data structure needs to be a domain-level entity, or is going to be directly referenced by multiple domain models, then it should have it's own store; otherwise it should be nested in a parent; it really has nothing to do with how much data is being tracked by an individual data structure. If you will only ever present states in conjunction with countries, such as form fields and address resolution, without additional selection vectors then there is no reason to make it a reference and give it its own table. If states are important on their own in the domain model or if multiple vectors might be used to access the data, such as if you have references to specific state agencies (NY DMV vs NC DMV, etc.), then you should make it a reference.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
-
States should have a reference to country. I would suggest that you reverse the meaning of 'InternalId' and 'Id'. Most tables will have an 'Id' (what you are calling 'InternalId') but will not have the other. You should call your current 'Id' something like 'DisplayId'.
I'll fly with this first and give it a try
public class WEBSITE_COUNTRIES
{
[BsonId]
[BsonRepresentation(BsonType.ObjectId)]
public ObjectId Id { get; set; }public string DisplayId { get; set; } public string LongName { get; set; } public string ShortName { get; set; } public bool Enabled { get; set; } public WEBSITE\_STATES States { get; set; }}
public class WEBSITE_STATES
{
[BsonId]
[BsonRepresentation(BsonType.ObjectId)]
public ObjectId DisplayId { get; set; }
public string CountryId { get; set; }
public string CountryCode { get; set; }
public string LongName { get; set; }
public string ShortName { get; set; }
public bool Enabled { get; set; }}
If it ain't broke don't fix it Discover my world at jkirkerx.com
-
Disclaimer: I have only played around with MongoDB for fun. No real application experience yet. One of the things I had read about a document based DB is to identify the aggregate. An aggregate will be a complete record. In your case, country on its own is not complete as it needs states as well. So, I would have a single document with something like this:
{
"_id": "DB generated Id",
"Name": "Country Name",
"States": [{
"Name": "State 1"
}, {
"Name": "State 2"
}]
}Now, if states on themselves are a complete record, then another document to hold state list can be used. This will lead to duplication which is absolutely fine AFAIK in NoSQL World.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[^]
OK. I'll see what happens after I seed the data and start consuming it. Will let you know.
If it ain't broke don't fix it Discover my world at jkirkerx.com
-
Disclaimer: this approach is rooted in Domain Driven Design, which is a common approach to NoSQL structuring. This is a super-rough look at entities vs value types in DDD. I'm generally in agreement with @lw@zi, but it depends on your use case of states. If a data structure needs to be a domain-level entity, or is going to be directly referenced by multiple domain models, then it should have it's own store; otherwise it should be nested in a parent; it really has nothing to do with how much data is being tracked by an individual data structure. If you will only ever present states in conjunction with countries, such as form fields and address resolution, without additional selection vectors then there is no reason to make it a reference and give it its own table. If states are important on their own in the domain model or if multiple vectors might be used to access the data, such as if you have references to specific state agencies (NY DMV vs NC DMV, etc.), then you should make it a reference.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
For now, it's just a Country and state dropdown. Change the country and their states / provinces load in the states dropdown. But I get what your saying. I'll have to study Domain Driven Design / Domain Level Entity.
If it ain't broke don't fix it Discover my world at jkirkerx.com
-
For now, it's just a Country and state dropdown. Change the country and their states / provinces load in the states dropdown. But I get what your saying. I'll have to study Domain Driven Design / Domain Level Entity.
If it ain't broke don't fix it Discover my world at jkirkerx.com
I'm learning here, had to change the model again because I haven't wrote the states yet in the country document, and scratching my head on how to write the states. This is really different.
public class WEBSITE_COUNTRIES
{
[BsonId]
[BsonRepresentation(BsonType.ObjectId)]
public ObjectId Id { get; set; }public string DisplayId { get; set; } public string LongName { get; set; } public string ShortName { get; set; } public bool Enabled { get; set; } \[BsonIgnoreIfNull\] public IEnumerable<WEBSITE\_STATES> States { get; set; }}
{
"_id" : ObjectId("5b80576d4989bc2bfcf8ffc9"),
"DisplayId" : "5b80576d4989bc2bfcf8ffc9",
"LongName" : "Canada",
"ShortName" : "CA",
"Enabled" : true
}If it ain't broke don't fix it Discover my world at jkirkerx.com
-
I'm learning here, had to change the model again because I haven't wrote the states yet in the country document, and scratching my head on how to write the states. This is really different.
public class WEBSITE_COUNTRIES
{
[BsonId]
[BsonRepresentation(BsonType.ObjectId)]
public ObjectId Id { get; set; }public string DisplayId { get; set; } public string LongName { get; set; } public string ShortName { get; set; } public bool Enabled { get; set; } \[BsonIgnoreIfNull\] public IEnumerable<WEBSITE\_STATES> States { get; set; }}
{
"_id" : ObjectId("5b80576d4989bc2bfcf8ffc9"),
"DisplayId" : "5b80576d4989bc2bfcf8ffc9",
"LongName" : "Canada",
"ShortName" : "CA",
"Enabled" : true
}If it ain't broke don't fix it Discover my world at jkirkerx.com
Don't get wrapped around the axle; just treat it as you would a normal object with a collection property. In that vein, the "BsonIgnoreIfNull" attribute isn't really necessary, it'll just serialize as "States": [] if there's no entries, and won't introduce any unexpected behaviors. Given your use case, and that you're just starting out with this, KISS will make life much easier.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
-
Don't get wrapped around the axle; just treat it as you would a normal object with a collection property. In that vein, the "BsonIgnoreIfNull" attribute isn't really necessary, it'll just serialize as "States": [] if there's no entries, and won't introduce any unexpected behaviors. Given your use case, and that you're just starting out with this, KISS will make life much easier.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
OK
If it ain't broke don't fix it Discover my world at jkirkerx.com
-
I'll fly with this first and give it a try
public class WEBSITE_COUNTRIES
{
[BsonId]
[BsonRepresentation(BsonType.ObjectId)]
public ObjectId Id { get; set; }public string DisplayId { get; set; } public string LongName { get; set; } public string ShortName { get; set; } public bool Enabled { get; set; } public WEBSITE\_STATES States { get; set; }}
public class WEBSITE_STATES
{
[BsonId]
[BsonRepresentation(BsonType.ObjectId)]
public ObjectId DisplayId { get; set; }
public string CountryId { get; set; }
public string CountryCode { get; set; }
public string LongName { get; set; }
public string ShortName { get; set; }
public bool Enabled { get; set; }}
If it ain't broke don't fix it Discover my world at jkirkerx.com
-
Disclaimer: I have only played around with MongoDB for fun. No real application experience yet. One of the things I had read about a document based DB is to identify the aggregate. An aggregate will be a complete record. In your case, country on its own is not complete as it needs states as well. So, I would have a single document with something like this:
{
"_id": "DB generated Id",
"Name": "Country Name",
"States": [{
"Name": "State 1"
}, {
"Name": "State 2"
}]
}Now, if states on themselves are a complete record, then another document to hold state list can be used. This will lead to duplication which is absolutely fine AFAIK in NoSQL World.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[^]
lw@zi wrote:
country on its own is not complete as it needs states as well.
Rather certain that when I do a drop down for country it doesn't need states. Something like an address page of course needs both country and state but it probably needs other things as well.
lw@zi wrote:
Now, if states on themselves are a complete record, then another document to hold state list can be used. This will lead to duplication which is absolutely fin
Doesn't sound like a good idea to me. Mongo already supports references. So if one wants a reference in country they can do that without hacking it themselves.
-
For now, it's just a Country and state dropdown. Change the country and their states / provinces load in the states dropdown. But I get what your saying. I'll have to study Domain Driven Design / Domain Level Entity.
If it ain't broke don't fix it Discover my world at jkirkerx.com
What is with the "enabled" then? Also if I was designing that per your requirements I wouldn't put in in the database at all. I would have a file system document that provided the lists. Then a class to load it. That way if this is a real business, and this is just the first pass, then I already have an API (the class that loads it) to replace with a real external 3rd party source of address data.
-
What is with the "enabled" then? Also if I was designing that per your requirements I wouldn't put in in the database at all. I would have a file system document that provided the lists. Then a class to load it. That way if this is a real business, and this is just the first pass, then I already have an API (the class that loads it) to replace with a real external 3rd party source of address data.
That's a good idea, that data will rarely change. I'll do that instead. The enabled is just legacy thought from the past. I've had customers tell me to remove eg. Hawaii from the list because of the high theft rate. And maybe I should consider just putting it all in a console app like Richard mentioned.
If it ain't broke don't fix it Discover my world at jkirkerx.com
-
That's a good idea, that data will rarely change. I'll do that instead. The enabled is just legacy thought from the past. I've had customers tell me to remove eg. Hawaii from the list because of the high theft rate. And maybe I should consider just putting it all in a console app like Richard mentioned.
If it ain't broke don't fix it Discover my world at jkirkerx.com