Are there any PHP ORM projects which supports MySQL and NoSQL databases such as MongoDB?
I am currently using RedBean to do MySQL ORM, however I woud like to introduce MongoDB to the applicatoin and perhaps even replace some of the MySQL with MongoDB in the future.
An ORM that can allow me to easily transition between both would be nice. However, I tend to not like ORM that requires too much configuration (i.e. YAML, XML etc). RedBean is very nice in that it allows one to easily get things working without too much configuration.
Yes, doctrine supports various RDBMS and NoSQL storages as well
Docrine 2 contains both an ORM and ODM for NoSQL databases (MongoDB and CouchDB are supported), and its theoretically possible to hook up Doctrine to anything else.
We're working on some adapter-based ORM called UniMapper in our company.
It provides a uniform API for accessing stuff from different kinds of databases, protocols, and 3rd party APIs. You can even associate between entities from different storages. And it should be even faster than Doctrine. Try it give us some feedback :-).
MongoDB will be supported very soon, but you can write extension on your own, it's very easy.
However the quick start is not complete, you can ask me or somebody from our team.
Related
Maintaining database views in mysql is sometimes cumbersome. When you change a referred table you have to alter the table and there is no clean way to do that in migrations (DB::unprepared()). I guess using query scopes in models is more maintainable. Isn't it? Does it has negative effect on the performance.
I don't know how big your project is and I don't have many elements to judge this situation perfectly.
However, working with views means depending on the underlying database system. Obviously it has its pros and cons, but I would prefer to decouple my software components.
What if you change, in the future, switching from MySQL to MongoDB?
Maybe, you could use a cache system, like Redis or Memcached (and Laravel already has a ready-to-use service for it).
As I told you before, I am making this suggestion basically because I think about the software scalability and components decoupling.
Here you can learn about the basic use of the Cache Service: http://laravel.com/docs/5.1/cache
Also, if you have some confidence with design patterns, you can implement a really elegant solution using some stacked repositories alongside the decorator pattern.
You can find some interesting articles about the topic here:
http://culttt.com/2014/02/03/laravel-4-cache-service/
http://culttt.com/2014/04/23/decorator-pattern/
Yes, they're about Laravel 4 but the concept can be easily adopted in a Laravel 5.* project.
Hope it was useful!
EDIT: as I told in the following comments, if you don't want to start with something like Redis or Memcached, you can always use the filesystem-based Cache.
Is the Doctrine Migrations project compatible with Doctrine MongoDB?
It isn't clear to me from searching and looking at the Doctrine Migrations project whether it is compatible with ODM solutions (e.g. MongoDB) as well as ORM solutions.
If it is, can anyone suggest examples or articles on how to use the two together?
If it isn't, are there reasonable alternatives?
Question Background:
I understand, marginally, the different approaches to migrating a document's data from one version of the document to another and the pros and cons of each.
I am leaning towards possibly implementing a hybrid approach of gradual schema changes and migration scripts as suggested here. Leveraging the functionality within Doctrine's MongoDB library written about by Jonathan Wage in his post: Doctrine MongoDB ODM Schema Migrations.
Even with that, I need to find some way of creating a migration script or performing the data migration, and Doctrine Migrations seemed like a good first choice.
As an aside, another user warns against using the approach Jonathan Wage presents above for migrating data and instead running commands (JavaScript?) directly against the database.
Despite doctrine-migrations is not compabible with MongoDB ODM (it only supports DBAL) you can bet for the alternative mongo-based migration components made by 3rd party teams.
It was firstly developed here https://github.com/antimattr/mongodb-migrations
but after it has been abandoned the project continues here https://github.com/doesntmattr/mongodb-migrations
Ufortunately, it isn't compatible with ODM. It supports ORM only.
I am starting a new (and first) project with Symfony2, but I didn't choise Database engine yet. And it could be MySQL or NoSQL engines like MongoDB or others, or also it could be changed along the proyect cycle.
So, I would like to start working without limitation of choising Doctrine, Doctrine for Mongo or others. And allowing posibility of changing only model layer without big impact on controllers, and classes.
Recomendations? Comments? Best Practices?
Hope this tutorial will help you to get some knowledge. However try to learn the main concepts before doing any major development.
I was wondering if there were any good pre-built ways to implement an EAV design pattern in Zend Framework?
I am trying to decide if I should create my own implementation or use one that has already been built.
Use Doctrine with MongoDB Document Mapper http://www.doctrine-project.org/
Zend Framework 2.0 has automated install for Doctrine with Composer, so it means Zend People also offer this as an Option apart from the built-in Zend_Db.
Using EAV on a document-oriented NoSQL database system like MongoDB or CouchDB is way much better than implementing a Hack over Traditional Relational Databases like MySql ( something that Magento did ). NoSQL Databases are better at implementing Sparse Matrix type Data.
Check out Zend Framework EAV on Google Code.
Digitalus CMS uses the EAV pattern, and is based on MySQL. It is true that Mongo or Couch might be more appropriate, but MySQL is often an easier choice because you don't have to install anything. I have tried using SimpleDB, but the local MySQL version is 4x faster. SQLite also works very well.
There are a lot of opponents to this approach, and their claims are largely founded. Any time I need to be able to query data I use a standard relational approach, but EAV shines when you are working with very loosely structured data like the content on a web page.
Digitalus uses an approach where there is the base CMS item model that handles all of the EAV logic. This model also handles a write-through cache so the system ultimately serves content as fast as a flat file system.
All the purists are probably technically correct, but fast and easy have a place in my toolbox.
I am a noob to PHP can anyone explain me whats Pear DB library with a practical use?
Thanks
http://pear.php.net - PEAR is a framework and distribution system for reusable PHP components.
EDIT(to the first answer):
Except DB abstraction packeges PEAR library contains huge amount of useful classes for work with XML, CURL etc. Full list of maintained packeges is available here.
BTW, PEAR stands for PHP Extension and Application Repository
The What:
Pear DB is abstraction layer. Its one of many framework components available from PEAR. What the heck is that? Its a layer/interface between PHP and the db provider (MySQL, MSSQL,Protege) . So, it handles calls to multiple types of db providers in pretty much the same way to your PHP application. Your application layer doesn't have to concern itself with the details of calling individual providers.
Pros:
Portability. Allows you to write your db interface code once and have it work with multiple providers.
Encapsulation. Makes many db calls a bit simpler to make.
Cons:
Performance. It will generally be a bit slower than calling php db commands directly.
Nutshell:
Its good to use it when you can.
Its just a database abstraction library. ALlows you to connect to different kinds of databases (MySQL, PostgreSQL) using a consistent API.