Thanks Benjamin. I can now connect on what you explained about schema. Schema less is in terms of a Node and i [wrongly] assumed it for the Graph.
Now coming to application architecture problem. as we know that we cannot freeze our architecture due to ever changing requirements, what we can do to make it more flexible. i can understand its a different problem altogether, but can we come up with a " best-practice" graph structure which can handle these kind of scenarios. following which will give you a more flexible graph structure which will be resilient to new changes. Shireesh. On Mon, Jul 14, 2014 at 10:02 AM, Benjamin Makus <[email protected]> wrote: > That is a problem in your applications architecture. If you use MySQL and > have a on-to-many relation between A and B, and now you need to store an > entity C between A and B, you've got to alter the schema and run an update > on all entries. > (if you can tell us a solution that works in SQL, than there's a 99% > chance that it works, too, in Neo4j) > > Schemaless means, that each node (and relation) can store whatever you > want it to. Node 1 can have { a: true, b: "B" } and node 2 can have { a: > 42, b: ["A", "B"], c: false }. So there's no schema, that means: you can't > say all a-properties are of type boolean, and you can't say every node has > 3 properties. > > Btw: If you've got a need, to add a new node between some existing nodes, > then Neo4j won't care. You can do whatever you want to: > Node 1 is related to Node 2 > and after the update you can have: Node 1 is related to Node 2 and Node 1 > is related to Node 3, which is related to Node 2. No problem. > > Again: There's no schema that says, that Node 1 can only have 1 relation, > it can have as many you like and it can relate to every other node, no > matter what this node is in your application. > > For Neo4j, all your data are just nodes, nothing more. They've got no type > and arbitrary content. If your application says that Node 1 is a Car and > Node 2 is a CryptoKey, you can still tell the database to relate them. > > Am Montag, 14. Juli 2014 13:59:44 UTC+2 schrieb Shireesh: > >> >> I am still confused with *schema-less nature.* >> >> As as can see it, still Neo4j gives us tightly coupled architecture. >> >> Imagine the Graph grows big as the project progresses and one day we >> got a new requirement which makes us to introduce new node between existing >> structure. >> Now this will have a cascading effect all over the graph. all the >> existing traversals needs to be reworked to include the new node and >> relationship. >> >> Which will have impact on all the components as the whole Graph is >> connected. >> >> Am i missing anything ? >> >> Thanks, >> Shireesh. >> >> >> On Monday, 4 June 2012 09:20:54 UTC-5, Charles Bedon wrote: >>> >>> Hello >>> >>> For me the best advantage of using a NOSQL approach is its schema-less >>> nature. It's also a disadvantage if you consider that it's now your >>> responsibility to ensure the model integrity, but it gives you a lot of >>> freedom if you have to mess with it at runtime (I mean, if the application >>> requires it). >>> >>> ------------------------------------- >>> Charles Edward Bedón Cortázar >>> Network Management, Data Analysis and Free Software >>> http://www.neotropic.co | Follow Neotropic on Twitter >>> <http://twitter.com/neotropic_co> >>> Open Source Network Inventory for the masses! >>> http://kuwaiba.sourceforge.net | Follow Kuwaiba on Twitter >>> <http://twitter.com/kuwaiba> >>> Linux Registered User #386666 >>> >>> >>> ---- Am Mon, 04 Jun 2012 08:40:45 -0500 *Johnny Weng Luu >>> <[email protected]>* schrieb ---- >>> >>> It's hard to imagine data with no relations. >>> >>> Sooner or later I think you would like to have relations between >>> different data entities. >>> >>> Everything is connected. >>> >>> Johnny >>> >>> On Monday, June 4, 2012 2:20:19 PM UTC+2, Radhakrishna Kalyan wrote: >>> >>> Hi >>> >>> This was my first question to Peter on his presentation in Karlskrona in >>> 2011 Dev-Con. >>> >>> As it always mentioned and I too realized that NoSql does not say not to >>> use relational database, but suggests to replace relational database with >>> Neo4J where one see relations(Complex/Non-Complex) among data. >>> I hope you agree. >>> >>> I do agree that neo4j is not a silver bullet for every case. >>> >>> I see it like this: >>> I will* NOT *use Neo4J in an application if: >>> >>> 1) The application have only tables with no relations among them. i.e No >>> foreign key relation among tables. >>> 2) If the application is a legacy application like Mainframes and DB2 >>> containing stored procedures etc. where migrating to a new DB is a major >>> issue. >>> 3) If the application code contains hard coded SQL queries to fetch the >>> data from the database which makes it hard to migrate. >>> >>> These are the few cases I found when I was looking to migrate my own >>> application built on Swing and SqlLite as backend. I used Sql queries with >>> in my code. >>> >>> I would have been saved if I would have used JPA. Because thanks to >>> Spring-Data-Neo4J where there is a support for cross storage. >>> It means that the application can persist to Neo4J and any relational db >>> using the same entity. >>> Please consider looking to Spring-Data-Neo4J. >>> >>> Please comment if there is any misconception in my opinion. >>> >>> Kalyan >>> >>> >>> >>> >>> On Mon, Jun 4, 2012 at 11:40 AM, Michel Domenjoud <[email protected]> >>> wrote: >>> >>> Hello, >>> I'm currently working on graph databases as an R&D subject, and I'm >>> looking for good references about graph databases pros and cons. >>> I already watched and read a lot of good articles about graph databases, >>> about their position in the NoSQL ecosystem, and also some benchmarks and >>> performance comparison towards relational databases. So, I have a lot of >>> pros arguments to uses graph databases : good fit for higly connected data, >>> powerful for traversals, etc. but also some examples that show use cases >>> usually adressed with relational databases (CMS, e-commerce...) >>> >>> Now I'm really convinced that graph databases and especially Neo4j fits >>> a lot of use cases, and as I was trying to convince some collegues about >>> Neo4j benefits, I realized that I lack some cons about graph databases vs. >>> relational databases and I was almost arguing Neo4j as a silver bullet, >>> which can't be true. >>> >>> So here is my question : does anybody have some references, precise >>> arguments or use cases that don't fit in graph databases but fit really >>> better in relational databases? >>> I already have some, but I intentionally don't put anything for the >>> moment in order to start an open debate :) >>> >>> Thanks by advance for your answers! >>> >>> >>> >>> >>> -- >>> Thanks and Regards >>> N Radhakrishna Kalyan >>> >>> >>> -- > You received this message because you are subscribed to a topic in the > Google Groups "Neo4j" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/neo4j/mts6H9Py-2I/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- *eThanks & eRegards,Shireesh Adla.* *09246081931* -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
