August 20, 2010 at 5:49 pm
I have a friend (a programmer) who's boss wants to build a non-relational database to handle PayPal type of financial transactions, and he asked for my 2 cents...
I don't know all the details other than that the relationships will be enforced within code (not within db)...
With my experience being only with relational dbs, this just sounds like bad idea.
Anyone have any experience with non-relational databases?
Financial db = non-relational db, a good idea?
August 20, 2010 at 10:35 pm
From the little info provided - I don't think I'd be able to say good or not good. That said - if your friend doesn't want relational, then I'd at least suggest not using a relational database as the basis. Trying to use a hammer as a screwdriver will eventually lead to a lot of holes in the wall.
In other words using a relational engine to store non-relational data usually ends up with poor performance, ugly locking, and often a sizeable investment in a software you're not using (SQL Server in this case). There are lots of ther types of data stores: find the one that fits and roll with it.
In the words of Mr Myagi:
Karate yes - Ok. Karate no - OK. Karate maybe - squish like a grape.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
August 21, 2010 at 4:34 pm
brucla (8/20/2010)
I have a friend (a programmer) who's boss wants to build a non-relational database to handle PayPal type of financial transactions, and he asked for my 2 cents...I don't know all the details other than that the relationships will be enforced within code (not within db)...
With my experience being only with relational dbs, this just sounds like bad idea.
Anyone have any experience with non-relational databases?
Financial db = non-relational db, a good idea?
I'm old enough to have worked with non-relational databases, DBMS. This happened before RDBMS existed at all.
I can tell by experience that you can build a solid non-relational database to support any kind of application. Total was a "network" DBMS we used to run databases for financial organizations including banks.
Having said that... why would somebody not want to use a relational database?
Moreover, build a non-relational database on top of a RDBMS engine like SQL Server makes no sense at all. I second Matt's comment on this.
Just my two cents.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.August 23, 2010 at 9:41 am
Just a quick note, if you're handling relationships in code, you're building a relational database. Just not declaring RI in the database.
Deciding on relational or non-relational seems to be a bit silly. If you have rules, why not enforce them in both places? You can do it in code, but you are duplicating work and assuming that every application will implement these the same and correctly? Why not save app code and let an RDBMS handle things in some places?
August 23, 2010 at 10:31 am
Thank you so much for your insights.
I totally agree with everything you guys have said so far.
I think they wanted to have an architecture where any object (or table) can potentially have one more more relationships with any other objects. Their reasoning, as far as I know, is to create a flexible architecture that can be used for mutiple applications. To your point, Steve, it seems like it's even less flexible to have the application code handle relationships.
Maybe there's some database architecture that make something like that efficiently possible that I'm not aware of???
Glad to know my thoughts were in line with people with more expertise 😀
August 23, 2010 at 10:47 am
I guess it can be less flexible, but it's more reliable. What flexibility do you need?
August 23, 2010 at 11:54 am
I'm assuming they mean "scalability" as well as "future feature additions"???
Unfortunately, I'm very very short on details. The discussion with my friend was more of us being curious/surprised about using a non-relational db...
However, this really kindled my curiosity and led me to stumble upon NoSQL.
(I've been so wrapped up in MS SQL and ORACLE, NoSQL never crossed my path until today! :w00t:)
From my light reading so far, it seems like NoSQL has been mostly used to manage non-financial data.
clip from http://www.dbms2.com/2010/03/02/cassandra-nosql-scalable-oltp/
the designers of the world’s most scalable websites — e-commerce sites perhaps excepted — seem pretty unanimous in thinking it’s best to bake some database/integrity management into the applications, rather than offload it all to an RDBMS. Why? Because the transactions are so simple that hand-coding all that isn’t prohibitive. And of course because of their extreme performance and scalability needs.
What are some possible reasons for e-commerce companies not adopting NoSQL?
It sounds to me, NoSQL should be a slam dunk for e-commerce as well (if implemented corretly, of course).
Does NoSQL natively have deficiencies managing financial type of data? (transactions, locking...)
I'm not sure if this officially has changed this topic to GOSQL VS NoSQL...
August 23, 2010 at 12:00 pm
A few links for you:
http://blog.nahurst.com/visual-guide-to-nosql-systems
http://adamblog.heroku.com/past/2009/7/6/sql_databases_dont_scale/
I think consistency can be the big issue. You can't necessarily make decisions if you can't be sure of your data being correct on any node. In many non e-comm situations, including things like Amazon displaying non-Account/cart stuff, I think this would work fine.
August 23, 2010 at 12:12 pm
Thank you so much for your insights.
I totally agree with everything you guys have said so far.
I think they wanted to have an architecture where any object (or table) can potentially have one more more relationships with any other objects. Their reasoning, as far as I know, is to create a flexible architecture that can be used for mutiple applications.
But that's what relational databases do! Relationships are based on common values across tables and can be quite dynamic.
I've worked on several non-relational databases and they usually have a particular niche where they perform very well. Where they usually have a problem is their ability to be consumed by generic tools. SQL-based databases can be accessed by a huge number of report writers, data aggregation and analysis tools, development tools, and have a well-understood access methodology. The no-sql bunch usually locks you in to the toolset provided by the vendor or, in the rare cases where a SQL interface is provided, the translation necessary to make it function also makes it S-L-O-W.
So, if you have a definite niche that fits the tool well and you have little need to do generic reporting or analysis on the raw data, have fun with the no-sql engines.
August 23, 2010 at 12:28 pm
Thanks for the links.
I'm sure it'll give me some answers and hopefully more questions. 🙂
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply