+1

billmurrin

I would like to see a video series using Elastic Search as the back-end.

+1

@jlrdw

NoSQL is yet just another shortcut language like eloquent. The shortcuts are converted to regular SQL at runtime.

Please elaborate ???

https://docs.mongodb.org/manual/core/read-operations-introduction/

@jlrdw I can assure you that MongoDB does not accept or understand a SQL statement. If does not have joins or any type of direct key relations. There is no relationship to ActiveRecord.

@jlrdw I am not able to understand the point, as to why you see NoSQL database as just another shortcut language like eloquent ?? There are differences between databases and ORM.

jlrdw:

https://docs.mongodb.org/manual/core/read-operations-introduction/

Did you even read that? did you notice that its COMPARING SQL to NoSQL? they are completely different technologies. Mysql is to MongoDB (a NoSql Database) as Eloquent is to Mongoose (a Mongo Orm).

Here's an informative video that explains why Mongo is web scale: https://www.youtube.com/watch?v=b2F-DItXtZs

+1 !

+1

@alenn

The best thing about MongoDB (in my opinion) is that I don't have to create migrations to add new fields in database, I just put $user->new_field = "something" and it's there

Actually, you do have to create. Making indexes for collections in migrations is good thing. You should also drop your indexes when you roll back your migration.

+1 and I would even suggest the series to use Orchestrate.io DBaaS, so the lessons are more focused on Laravel + NoSQL than entering database specifics.

+1

+1

+1

+1

I hesitate to +1 this.

If all you want to do is build a relational database out of Mongo or whatever, what is the point? (think references in Mongo)

Having said that, I do have a use case.

I am building a recipe database. We have a requirement to keep multiple versions, keep a historical archive of versions, and be able to promote any version to master, be able to a/b test versions, view nutritional data side by side on versions. I think in this case a nosql db would be just about perfect. You could be sure that the version you are looking at is exactly the way it was when you created it. No worries if an ingredient is changed, the version would have it's own copy of the ingredient.

Anyways I am gonna check out jenssegers/laravel-mongodb.

+1 (for Graph DB's like Neo4j)

@jlrdw you are completely wrong here if I understood nosql correctly. In Sql rdbms all objects of a table have the same properties. In NoSql they do not necessarily have the same properties. Also I do not get your comparison to active record? Where do you even get them together? Could it be you mistake nosql with orm or so?

+1

@jlrdw The main issue for me to keep in mind about MongoDB (and other NoSQL providers) is the server resources required for HUGE databases. Facebook and many other large organizations do not use SQL derivatives for all their data storage needs, rather they turn to NoSQL options.

Please take time to investigate and research the differences in server performance between *SQL (MySQL, MariaDB, MS SQL, Postgres, et al) and NoSQL (MongoDB, CouchDB, Cassandra, et al). I apologize I don't recall the exact link to the articles providing benchmarks for the DRAMATIC performance differences.

Please consider a scenario; If you have a database that contains millions of records (or even a few hundred thousand) that is constantly changing how do you scale it to support thousands of unique hits and queries? Lets also take into consideration wait times. How many people wait for their facebook post(s) to load before moving onto the next post? About 3 seconds. My point is if your SQL Server is so overloaded processing updates to data that you cannot serve your forward facing demands your users will go elsewhere. That is the situation I deal with. (Over 300 databases of unique data (over 30K active rows) that changes by the second during peak viewing times and must be kept up to date). Processing the updates too fast overloads server resources, too slow and clients complain. Thus move to a NoSQL that updates the files on high speed SSD drives, etc. AND I can implement on demand sharding a heck of a lot easier than I can replicate with MySQL (or any other). SQL databases you must have a master (or mirrored masters) that are constantly updating replicas. Just how big of a server are you going to buy to support this? Rather, why not choose a NoSQL option that stores the data in files that could be shared on a NAS/SAN and served up by replicas that can be turned up at will by a load balancer? I realize I may not have all the exact answers and perfect terminology in place here but hopefully you can begin to understand the advantage(s) of a NoSQL option, at least for me.

I do hope this is of some help. While I will not argue your comments of how ORM and such issue their queries, I ask you to consider the scale-ability and performance differences.

There is an easy way to store JSON objects in a table field using Laravel?

Hey @harryg we started using MongoDB at work several months back, I was not excited at all when we started using it, but now that I have used it and seen the true POWER of the dark side ;) I have a hard time finding a use case for MySQL over MongoDB. I personally believe that developers who try and argue the point may not have ever used MongoDB in a live project before.

Like you pointed out there are some packages out there to help, we use jenssegers/laravel-mongodb, I wish that MongoDB was baked into Laravel out of the box, once you take the red MongoDB pill there is no going back :)

For anyone on the fence, you should give it a try, it's awesome!

@Presto I have a hard time finding a use case for MySQL over MongoDB. I personally believe that developers who try and argue the point may not have ever used MongoDB in a live project before.

I just really like data integrity,consistency most of the times, so please don't preach for mongodb out of the box. It certainly has its (very) specific usecases but I think you are overstating its purpose a bit with this statement.

@DirkZz, I can see where you are coming from, I too was making that argument with my teammates a few months back, but now that I have been using it for a few months on a live project I personally have a hard time seeing why you, (or really I) would want to use MySQL.

@DirkZz and everyone else, I'm not trying to come off as "preachy", all I'm saying is more and more users are starting to use a NoSQL solution and there is a place for it in the framework, and I think if you used it you would see it's a great option for a blog to a large-scale e-commerce site.

MySQL seems really old and clunky to me now, saving empty data/columns for consistency; just seems like an old school way of thinking, and I'm old school so I know what I'm talking about (joking) just look at all of the gray in my beard lol. Again these are just my thoughts from someone who is actively using a MongoDB daily.

Ultimately that'll be a decision that @TaylorOtwell will make, if he sees value in adding it to the framework.

@Presto Lets agree to disagree :)

+1 (for db MarkLogic)

+1

+1

+1

Document type (nosql) defiantly has its place. Best use cases is generally a mix of rational and document.

For example users table and relationships work better with rational. But instead of static pages using nosql excells at storing page content, or recipes etc that doesn't require other data (keep it all together)

Side note: nosql is by far the easiest to scale vertically.

Couch db is awesome. Automatically keeps old records and stores attachments (images, pdfs etc) with ease.