The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Anything that is unrelated to elephants is irrelephant Anonymous - The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944 - Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
well, Im just beginning to play with it for an upcoming series on Go(lang), mainly because I wish to use JSON 'documents', and I think for non SQL work it is quite popular - on looking at the examples Im putting together, it is certainly 'easier' to change the structure of a document, rather than redefine a SQL relation table
As with sooo many things, one chooses the right tool for the job - some tools can be used as a hammer to achieve a task, that doesn't necessarily mean that it is correct to do so
A recent company I worked for were inclined to store large XML blobs in relational tables with other information - their life would have been much easier not to have done so, but evolution is rarely logical
Anyway, I've used MongoDB in the past and it's very easy to just write some code and store it in the database.
Except that when you add a property you always need to think about whether that property is backwards compatible.
You have to do that with SQL too, of course, but there you are more forced to think about it.
It's VERY easy to just add a new property of type int, but when a MongoDB document doesn't have that property you're going to have a runtime mapping exception so you'll have to make it int? instead, etc.
Also, forget normalization.
If you have a highly normalized data structure, MongoDB is going to make life harder.
So really think about what data you can store with redundancy and what data you can't.
Also, I found querying a MongoDB a lot harder, but that's probably only because I'm not used to the syntax
I'm not used to seeing you use popular technology by the way, unless you're going to use this for your LALR X-PARSE B-TREE REGEX EXPRESSION COMPILER +5
This is a nice write-up and has some valuable points.
I would also add that yes, MongoDB is quite popular based on the fact that it had an IPO and you can buy stock in the company: MongoDB current stock price[^]
That may sound a bit ridiculous but I mean it does show a bit of consumer and investor confidence and that the company itself seems to be solid.
Yeah, it's not a problem if you use NodeJS, but I'm assuming honey is using C#
Of course you still can't just add number2 after some weeks of production (and always set it for new records) and then somewhere do number1 + number2, assuming they both have a value.
Even if number1 always has a value, number2 only gets a value at some point in time, unless you do a collection update like you'd do in a SQL database.
When I worked with MongoDB we used to do that because updating the entire collection is easier than updating the entire software
For the record, I didn't think we needed MongoDB, SQL would've been fine, especially when you want schema integrity anyway, but it was the decision of our architect.
At least it gave me a chance to work with MongoDB in a production environment.
CouchDB is another alternative, but MongoDB is the one I hear mentioned most often.
Having said that, a lot of those mentions are on infosec news, when someone's left their MongoDB store up, unprotected, on Amazon S3 and the data in it has been compromised... That's not MongoDB's fault, of course
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
I may be thinking of another incident where researchers just tried the default MongoDB port on thousands of servers and found that for many of those servers the port was open and the database was exposed.
Because 1.x existed prior to generics we have issues of legacy object models not implementing IList<T> and instead simply exposing hard typed indexer properties.
Normally, you'd just get the generic parameters of the generic IEnumerable<T> interface, but because some object trees were created prior to 2.0 - like the CodeDOM they don't have them.
This makes determining the element type of a typed list extremely difficult. The problem is that your alternative is the indexer property which isn't a member of a hard interface, so you have to select the appropriate indexer property from the properties on that type. There might be this[string name] in there too, for example. There is no contract however, so there are no guarantees. This isn't especially robust.
Which means, the obvious solution is to first try to get it using the generic interfaces, and if they aren't available, then we fall back to the less robust method above.
This is not ideal, and it requires maybe a page of code to handle all the scenarios.
Microsoft didn't put generics into 1.x I think because of time constraints, and if so they should have waited, IMO.