I'm actually trying to learn new things...
I used SQL for a long time, using MySQL and recently discovered document-oriented databases.
I came across graph-databases & Neo4j and want to try it through NodeJS but I really don't get the point.
Should I use Neo4j coupled with another DB? Like storing my data into MySQL & relationships in Neo4j?
Or may I use Neo4j to store data (like posts)?
Neo4j is often used as the primary database, see https://github.com/thingdom/node-neo4j for a node.js driver. Also, depending on your use case, you can use it with MySQL in different scenarios for complex queries that take a long time in MySQL like recommendations and other path queries, see http://docs.neo4j.org/chunked/snapshot/data-modeling-examples.html for some interesting starting examples.
/peter
Related
As a new developer, I am always confused about using NodeJS and MongoDB. So I hope I will get an actual answer. Thanks...
MongoDB and NodeJS are two different technologies. MonogDB is a database system which gives you a chance to efficiently store documents in a database and to perform operations like data updates, or to search documents by some criterias.
NodeJS's responsibilty is especially to execute your application.
Nodejs is a Javascript engine that you can write any application you want with (by programming in the Javascript language). It runs your Javascript code. Most commonly, it is used to build servers that can respond to web requests, though it can be used for lots of other types of code too.
MongoDB is a database engine. Code within some application or server uses MongoDB to save, query or update data in a database. There are many web servers built with nodejs that will then use MongoDB for storing data.
MongoDB offers an API library that runs within a Nodejs application to give you programmatic access to MongoDB so you can create databases and then add, query, update or delete data from the MongoDB database. MongoDB also has API libraries for other programming environments such as Python, Java, etc...
These two technologies are for different parts of a typical web server system. You don't substitute one for the other. Instead, you can use them together.
When should we use Nodejs?
Any project needs a programming environment and a runtime library that offers you basic programming tools/support and can compile and/or interpret your code. Nodejs is such as tool for the Javascript programming language. There are other similar tools for other languages such as Python, Java, PHP, C#, C++, Go, etc...
So, if you want to write some kind of stand-alone program or server in Javascript, then you can use nodejs for it.
When should we use MongoDB?
If your application needs the ability to persistently store data in a way that you can efficiently query or update it later, then you would typically use some form of database. There are dozens of popular databases. MongoDB is one such database. MariaDB, MySql, CouchDB, DynamoDB (on AWS), Postgres are examples of other databases. Different databases have different strengths (things they are best at) and different ways of using them so it's a whole different question to choose the right/best database for what you're doing.
Here is a Blog link that will tell you when you should use NodeJS.
Here is another link to understand when you should use mongoDB.
Well, NodeJS and MongoDB are two different process. Here I tried to explain as simpler as possible:
NodeJS
Shortly we can say, NodeJS is a JavaScript runtime environment. It's actually helps JavaScript to run outside of server. It's used in server side development.
MongoDB
But, MongoDB is NoSQL database which is document oriented. It represents data as of JSON documents. It's used for store data.
Summary
The summary is MongoDB is a database where we can store data and NodeJS helps us to to connect our client site to database by it's server site.
Example:
Suppose you are building a website and you need a database to store the data or information so here you can use MongoDB but to be connected with MongoDB you need a connector, so here you can use NodeJS which will help your website to run outside of server.
Nodejs: Node.js is an interpreter or runtime/ running environment for JavaScript. built on Chrome's V8 JavaScript engine. responsibility is especially to execute your application.
MongoDB: is a No-SQL database for storing data. when you need high availability of data with automatic, fast, and instant data recovery.
Is there any disadvantage to execute native SQL query using either {dataSource.connector.execute(sql, params, cb) or dataSource.connector.query(sql, params, cb)} than using connected models?
I have recently tested the same scenario with sample data with both Native SQL and connected models. When I used Native SQL I noticed that MYSQL connection get lost when I increase the load. But The same operations performance with Loopback's connected models and filters, It can sustain almost 4 times the load compared to Native SQL Connector.
Loopback also don't recommend using Native SQL Connector:
This feature has not been fully tested and is not officially
supported: the API may change in future releases. In general, it is
always better to perform database actions through connected models.
Directly executing SQL may lead to unexpected results, corrupted data,
and other issues. - Loopback
So My exact question is Has anybody noticed any Disadvantage or performance panalty Using of Using Native SQL instead of Loopback's connected models?
Simply put running raw queries(Native sql) may be faster than having using ORMs(models) as they perform validations , build queries from parameters and filters you provide etc. where as running raw queries simply issue the query to the connected sql server over network without going through all those extra layers , but those difference maybe barely noticeable. Now industry standard is that you should use ORMs(models) to access you data as they protect you from a lot of threats like sql injection and simple human errors as it performs comprehensive validations based on the schema. So simply put ORMs are safer than Raw queries. But its a matter of choice what you want to do. I honestly fall somewhere in the middle where i use ORM provided models whenever possible but i have found some instances where running Raw queries brings far more simplicity like when you have to perform joins on more than 2 tables as well as manipulate the data using queries than use ORM. This last bit is just my way of doing things which in many peoples opinion may be wrong. I suggest use ORMs ie. in your case Strong Loop connectors as much as possible.
Can anyone point to me of any examples in which i can use an RDBMS to maintain data but use a NOSQL database to pushout data. My goal is to add/update/delete to the RDBMS but store entities with all of thier related data in the NOSQL database. Then, I would like to push the data out from NOSQL. Does this sound like a bad idea? My goal is to have nodejs present this data in a hierarchal format of all of its related data.
As others have said it sounds like you want to store all youre data in 2 different engines, and I can not see the big idea in that unless we are migrating to a new system.
If you are afraid of the nosql consistency and your data do fit in youre rdbms I can't see the point in using the nosql when you can have node connect to your rdbms and fetch the data stright from that.
have a look at driver for postgresql it is a driver for postgresql. I haven't tried it, but it look's like its fairly developed and tested.
I'm getting more into Node.js and am enjoying it. I'm moving more into web application development.
I have wrapped my head around Node.js and currently using Backbone for the front end. I'm making a few applications that uses Backbone to communicate with the server using a RESTful API. In Node.js, I will be using the Express framework.
I'm reaching a point where I need a simple database on the server. I'm used to PostgreSQL and MySQL with Django, but what I'm needing here is some simple data storage etc. I know about CouchDB, MongoDB and Redis, but I'm just not sure which one to use?
Is any one of them better suited for Node.js? Is any one of them better for beginners, moving from relational databases? I'm just needing some guidance on which to choose, I've come this far, but when it's coming to these sort of databases, I'm just not sure...
Is any one of them better suited for
Node JS?
Better suited especially for node.js probably no, but each of them is better suited for certain scenarios based on your application needs or use cases.
Redis is an advanced key-value store and probably the fastest one among the three NoSQL solutions. Besides basic key data manipulation it supports rich data structures such as lists, sets, hashes or pub/sub functionality which can be really handy, namely in statistics or other real-time madness. It however lacks some sort of querying language.
CouchDB is document oriented store which is very durable, offers MVCC, REST interface, great replication system and map-reduce querying. It can be used for wide area of scenarios and substitute your RDBMS, however if you are used to ad hoc SQL queries then you may have certain problems with it's map-reduce views.
MongoDB is also document oriented store like CouchDB and it supports ad hoc querying besides map-reduce which is probably one of the crucial features why people searching for DRBMS substitution choose MongoDB over the other NoSQL solutions.
Is any one of them better for
beginners, moving from relational
databases?
Since you are coming from the RDBMS world and you are probably used to SQL then, I think, you should go with the Mongodb because, unlike Redis or CouchDB, it supports ad hoc queries and the querying mechanism is similar to SQL. However there may be areas, depending on your application scenarios, where Redis or CouchDB may be better suited to do the job.
I currently developed an app that connects to SQL Server 2005 database, so my DAL objects where generated using information from that DB.
It will also be possible to connect to an Oracle and MySQL db, all with the same table structures (aside from the normal differences in fields, such as varbinary(max) in SQL Server and BLOB in Oracle, and so on). For this purpose, I already defined multiple connection strings and multiple SubSonic providers for the different DB's the app will run on.
My question is, if I generated my objects using a SQL Server database, should the generated objects work transparently with the other DB's or do I need to generate a different DAL for each database engine I use? Should I be aware of any possible bugs I may encounter while performing these operations?
Thanks in advance for any advice on this issue.
I'm using SubSonic 2.2 by the way....
From what I've been able to test so far, I can't see an easy way to achieve what I'm trying to do.
The ideal situation for me would have been to generate SubSonic objects using SQL Server for example, and just be able to switch dynamically to MySQL by just creating at runtime the correct Provider for it along with its connection string. I got to a point where my app would correctly connect from SQL Server to a MySQL DB, but there's a point where the app fails since SubSonic internally generates queries of the form
SELECT * FROM dbo.MyTable
which MySQL doesn't support obviously. I also noticed queries that enclosed table names with brackets ([]), so it seems that there are a number of factors that would limit the use of one Provider along multiple DB engines.
I guess my only other option is to sort it out with multiple generated providers, although I must admit it does not make me comfortable knowing that I'll have N copies of basically the same classes along my project.
I would really love to hear from anyone else if they've had similar experiences. I'll be sure to post my results once I get everything sorted out and working for my project.
Has any of this changed in 3.0? This would definitely be a worthy reason for me to upgrade if life is any easier on this matter...