Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

GOSQL vs. NOSQL Expand / Collapse
Author
Message
Posted Saturday, July 10, 2010 2:46 PM


Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, August 14, 2014 9:10 AM
Points: 14, Visits: 388
Comments posted to this topic are about the item GOSQL vs. NOSQL

Veni Vidi Velcro
I came, I saw, I stuck around
Post #950383
Posted Saturday, July 10, 2010 4:20 PM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 10:59 AM
Points: 21,619, Visits: 15,275
I would be in favor of using the right tool for the job. If the project warranted using something like NoSQL and it could be shown that it would work better, then sure - use it. But the evidence would have to be convincing.



Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server


SQL RNNR

Posting Performance Based Questions - Gail Shaw
Posting Data Etiquette - Jeff Moden
Hidden RBAR - Jeff Moden
VLFs and the Tran Log - Kimberly Tripp
Post #950398
Posted Saturday, July 10, 2010 4:43 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, August 12, 2014 4:08 PM
Points: 8, Visits: 484
Link to gigaorm not working. I'm looking forward to some more discussions about why SQL is not always the right tool - even when working with SQL DBs.
Post #950404
Posted Saturday, July 10, 2010 6:21 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, November 26, 2012 7:59 PM
Points: 169, Visits: 62
Working link is http://gigaom.com/2010/06/24/structure-2010-the-future-of-sql-in-the-cloud/


Post #950407
Posted Saturday, July 10, 2010 8:21 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, August 12, 2014 4:08 PM
Points: 8, Visits: 484
I've been taken on the carpet before, but I still don't understand why everyone is so enamored of the current SQL (90 or whatever) syntax for doing analysis of data stored in various table (or otherwise "Rectangular Objects").

We have views for some slicing, extremely complex procedures for rendering business rules or whatever. Vendors have introduced OLAP approaches but these are not universal. All of these SQL interfaces are based on a fairly ancient syntax.

I'd like to completely separate the business rules (and of course the presentation) from the database. If the business rules need to exist in the DB (why: performance, modularization), then make them completely separate from the purely transformational ones.

How do we deal with the fuzzy logic of the current search engines using SQL? LIKE? CONTAINS? poor substitutes for real regex's.

Can we make queries that are optimized based on 'knowing' that the target result set is readily available?

I'd love to be able to use a hierarchical naming scheme (db.project.appliction.table) but it ain't available in SQL Server (schemas aren't it.) I'd like to be able to specify via a 'use ##' a node within this hierarchy.

Aren't there any languages that can compete with SQL across all platforms? I don't think individual ORM solutions work.

Sorry if these questions just show my ignorance.
Post #950415
Posted Sunday, July 11, 2010 1:19 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Yesterday @ 12:00 AM
Points: 446, Visits: 3,325
rp-sqlsc (7/10/2010)
I've been taken on the carpet before, but I still don't understand why everyone is so enamored of the current SQL (90 or whatever) syntax for doing analysis of data stored in various table (or otherwise "Rectangular Objects").

Firstly a lot of customers and professionals have a huge investment in SQL. Perhaps understandably there is a certain reluctance to change. The data management field is more conservative and less used to change than say the application developer community where the turnover of new languages, techniques and ideas happens much faster.

Also the SQL DBMS market is sewn up between three mega-vendors who certainly have a vested interest in building on their investments rather than giving it up for something new.

Among customers, application developers and CIO's there is plenty of awareness that SQL is broken and isn't fulfilling many modern database needs. However, as I've observed on SSC before, it seems that database professionals working with SQL are reluctant to talk about the topic. It sometimes seems that when SQL professionals respond to criticisms of SQL it is usually to defend those aspects of SQL rather than look for better alternatives.

Aren't there any languages that can compete with SQL across all platforms?

There ought to be more. There are lots of interesting developments in alternative data management paradigms. What seems to be missing is an industrial strength relational alternative to SQL. Most of the NoSQL initiatives are based on non-relational models, which is unfortunate because it makes it unlikely that they will ever replace SQL (SQL is non-relational but is still much closer to the relational model than to graph databases for example). This is where I think the "traditional" (read "SQL") data management profession could do more - by supporting initiatives to develop relational alternatives to SQL.

Sorry if these questions just show my ignorance.

Not at all. These are important questions that aren't talked about enough in forums such as this one.


David
Post #950425
Posted Sunday, July 11, 2010 1:30 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, August 14, 2014 11:35 PM
Points: 316, Visits: 1,140
I don't believe the relational model will be under threat until someone comes up with some other data model with equally sound theory behind it. The fact that a large number of "developers" don't adhere to the model properly and therefore end up with broken databases (as seen in every company I've worked at over the last 5 years that purchased a third party ERM solution) doesn't mean there's anything wrong with the model.

"Business logic" is also a loaded term, mostly due to the fact that nobody seems clear on what it really means. Often I hear that putting business logic into the middle tier means no stored procedures or other logic in the database. I think this is a misunderstanding. The database, and the relational model itself, are there to ensure the integrity of your data. As such, logical operations which affect the integrity of the data belong in the database. This doesn't mean there's no logic in the middle tier. It just means you have to think about what counts as data integrity vs what counts as functional business logic. If your data model doesn't include referential integrity, domain constraints and so on, you haven't built a relational database and can make no claim about them.

The other argument I've heard is that moving things into the middle tier lets you change your database vendor more easily. I think this is a failing argument for two reasons: first of all, application architectures change much, much faster than databases. Second, the whole idea fails to recognise a core principle of OOP: separation of interface from implementation. Putting direct data access into the application tiers means interacting with the implementation of the data model directly. Far better would be to go through an API... like a set of stored procedures. Changing database vendors may mean rewriting the procedure logic unless you wrote everything in ANSI SQL, but even if you did, wouldn't you want to do a rewite anyway? An efficient SQL Server query might not be an efficient Oracle query.

The more I hear about this debate the more it seems that the people who don't like relational/sql are the people who don't know what it is, or misuse it, or have had to work with poorly constructed "relational" systems and don't realise that the problem is that they're not really working with a relational system to begin with.


allmhuran.com - download the SSMSDeploy addin for SSMS 2008
Blog on sqlservercentral
Post #950426
Posted Sunday, July 11, 2010 4:18 AM


Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: 2 days ago @ 7:43 AM
Points: 797, Visits: 1,568
Well, I guess it's time I posted another of my silly questions. What do people mean when they say SQL is broken? What is the reference point? What are the criteria?



One of the symptoms of an approaching nervous breakdown is the belief that one's work is terribly important.
Bertrand Russell
Post #950435
Posted Sunday, July 11, 2010 11:45 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 9:09 AM
Points: 36,941, Visits: 31,443
GPO (7/11/2010)
Well, I guess it's time I posted another of my silly questions. What do people mean when they say SQL is broken? What is the reference point? What are the criteria?


There are a lot of folks that believe that SQL Server violates several of E.F. Codd's "12 Rules of RDBMS" (there are acutally 13 "original" rules if you count the infamous "Rule 0" and they were later expanded to 18) and that SQL Server is "broken" because it's not actually an RDBMS according to those rules. Google CODD 12 RULES and see.

My stand on Codd's 12 Rules is that too many people have read too much into them and their true meaning has been smeared by interpretation by those who are compelled to provide such (sometimes grossly misinformed, IMHO) interpretations. Unfortunately, Codd is no longer in the land of the living so we'll never be able to actually ask him for clarification.

My other point of view is that, even if it turns out to be true that SQL Server is "broken" according to the 12 rules, my contention would have to be "So what and why does anyone think it matters?"


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #950569
Posted Sunday, July 11, 2010 11:59 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 9:09 AM
Points: 36,941, Visits: 31,443
but rather whether non-relational alternatives (paid-for and free) should be embraced when they are better suited to certain applications.


Actually, I'm good with that because a "database" and all it's workings work much better when they are designed and used for something specific. It's virtually a given that anything that is "general purpose" in nature will take longer to run and will be more difficult to maintain than a "directed solution".

However, if you get into trouble with such a thing, who actually "supports" it? And, if it's "proprietary", do such companies provide an interface to the data directly or can you only get there via their proprietary solution software?

Soooooooo... that brings me back to square one which I share with the author... "Good old SQL".


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #950577
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse