31–40 of 171 posts
Earlier quoted context omitted.
Except it doesn't. It just has a JSON data type. As does many other databases e.g. Oracle, Teradata. People are switching to MongoDB because the developer and deployment experience is so good.
>because the developer and deployment experience is so good. That was ironic, right? http://php.net/manual/en/mongo.sqltomongo.php
Earlier quoted context omitted.
Except it doesn't. It just has a JSON data type. As does many other databases e.g. Oracle, Teradata. People are switching to MongoDB because the developer and deployment experience is so good.
>because the developer and deployment experience is so good. That was ironic, right? http://php.net/manual/en/mongo.sqltomongo.php
Only problem I have with JSON on Postgres is you can't update a property of a JSON object like so: update table set jsonCol->propertyA = 42; You need to write an extension for that. Easiest to do so using Python but sadly Heroku doesn't support python on postgres since its unsafe.
Only problem I have with JSON on Postgres is you can't update a property of a JSON object like so: update table set jsonCol->propertyA = 42; You need to write an extension for that. Easiest to do so using Python but sadly Heroku doesn't support python on postgres since its unsafe.
Earlier quoted context omitted.
Except it doesn't. It just has a JSON data type. As does many other databases e.g. Oracle, Teradata. People are switching to MongoDB because the developer and deployment experience is so good.
Hate to say so, but many are switching to MongoDB because it's the current new kid on the block. I found that many companies have incredibly bad, not use-case driven reasons to pick their DB. Not that MongoDB is a bad database, but it has it's fair share of issues. Granted, this is the case for every database, but if you pick any database without being aware of those, you end up in a world of pain. (Context: I consul…
As in "Our lead dev always wanted to try X, because he likes the name".
Given that, I really need to build an app using project-he-who-may-not-be-named.
Only problem I have with JSON on Postgres is you can't update a property of a JSON object like so: update table set jsonCol->propertyA = 42; You need to write an extension for that. Easiest to do so using Python but sadly Heroku doesn't support python on postgres since its unsafe.
create table foo (d hstore);
insert into foo (d) values(hstore(ARRAY['key', 'key2'],
ARRAY['value', 'value2']));
-- "key"=>"value", "key2"=>"value2"
update foo set d = d || hstore('key', UPPER(d->'key'));
-- "key"=>"VALUE", "key2"=>"value2"
Since when MongoDB is considered as a database comparable with PostgreSQL?)
Since NoSQL movement started comparing their database options with SQL based ones.
In old times you could suddenly switch off power of a running Informix server and it will correctly restore the state on that very moment after reboot, dropping all partially (unfinished) transactions, keeping all the committed ones, so it was possible to have a clean state of the system.
How does it work? Append-only so-called "physical logs" on an direct-access, unbuffered by an OS and hard drives storage, proper partitioning on separate physical drives (for real parallelism), etc.
Again, real databases are all about data-storage (architecture, data-structures, algorithms, design decisions, proper implementation) not some "user-friendly" APIs and "well-written" docs to quickly gain popularity among ignorant.
Database back-ends are among the hardest problems in programming and the amount of research which has been done in 80s and 90s in this field is quite remarkable. I doubt that a bunch of punks with professional marketing and sales techniques could adequately replace implementation of a high-performance and fail-safe storage back-end, which is called a database.
Earlier quoted context omitted.
>because the developer and deployment experience is so good. That was ironic, right? http://php.net/manual/en/mongo.sqltomongo.php
Strangely,there is no JOIN example ...
The general issue that I often see is that people don't choose their databases by "is this a good fit or a bad fit for our use case" but rather by "that looks cool" or "we need that to attract talent" or "we did that project with X, so X is also fine for that new, totally different thing". And then they also try and stick with it at all costs, instead of acknowledging that the choice was a bad fit. And then they call you and say "we have an X database in flames, can you come in and rescue our data? Best would be yesterday?"
This is not restricted to document databases. I've seen apps run on mysql on a cluster with 10 Sun XFires where after a man-month of index-optimization 3 would have been sufficient. That was like shooting dead fish in a dry barrel. A lot of developers don't want to bother with stuff like "how does that complicated piece of machinery actually behave if I push it."
But then again, plenty of shops still use MySQL (and one of my clients uses DB2...).