views:

37

answers:

1

is it generally acceptable to store relational data in an rdbms like mysql, and place, lets say, arbitrary relationship data in a separate graph database system like neo4j? what about primary keys referenced in one db to another? or, another example: using mongodb for log data when mysql is the primary database platform for the application?

i would consider a scenario like using the sphinx search engine as a full-text backend populated by mysql to be a solid example of this being viable in practice, but would like to hear what others think.

an example implementation would be having entities related to a piece of content stored in mysql, and having deep relationships between entities stored in neo4j.

A: 

Hello,

In my experience, some of the reasons for doing so would be for data warehousing, so that one database gets hit primarily for reporting, while the other database is for the online processing of the live app. Another reason would be two related systems may link up (like linking server in SQL Server).

It might be hard to maintain or link if you have two separate products. Could be wrong as I don't know a lot about those products, but seems to me that the relations within mysql would be eaiser to develop against. However, if you have a special need like graphing, that is a good use of multiple DB's.

I guess it depends on what are you doing with these databases?

Brian
feels like a "right tool for the right job" sort of thing. i guess my concern is using multiple dbs in a single web view. for instance, if i have a recording artist with several weighted relationships to songs (as a contributor, as a producer, as the primary artist) as well as to content like blog posts (is primary focus of article, is mentioned, is related to, see also, etc), i can store it in a graph db and have lightning-fast traversal or i can have a fairly specialized and very large table in mysql. both have benefits and drawbacks, both have data i need to display on a single page.
Carson
Yes, that's right... I like to use one database for all, and normalize the design. Not as fast necessarily... But two DB's for interrelated content would be hard to manage (especially when you factor in ORM's if you are using them).
Brian