March 15, 2011 at 11:30 am
It just occurred to me that NoSQL may, in fact, be the answer. The problem is that few people advocating it understand the question.
March 17, 2011 at 2:42 pm
I think a huge it depends is in order for NoSQL v RDBMS. One thing to consider is if the data consistency or data recoverability in your application is important. So far, I have used a few applications with nosql as the backend and am annoyed from time to time by the lack of data consistency at times.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
March 17, 2011 at 2:46 pm
CirquedeSQLeil (3/17/2011)
I think a huge it depends is in order for NoSQL v RDBMS. One thing to consider is if the data consistency or data recoverability in your application is important. So far, I have used a few applications with nosql as the backend and am annoyed from time to time by the lack of data consistency at times.
What type of inconsistency issues? Dirty reads, lack of atomic transactions?
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 17, 2011 at 2:51 pm
Eric M Russell (3/17/2011)
CirquedeSQLeil (3/17/2011)
I think a huge it depends is in order for NoSQL v RDBMS. One thing to consider is if the data consistency or data recoverability in your application is important. So far, I have used a few applications with nosql as the backend and am annoyed from time to time by the lack of data consistency at times.What type of inconsistency issues? Dirty reads, lack of atomic transactions?
I have seen both dirty reads and the lack of atomic transactions. Couple that with the slowness of the return results - which may be app related or nosql related.
For the kind of app that these are - it's little issue but certainly would be of great concern in an enterprise type app.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
March 20, 2011 at 5:35 am
NO SQL is the answer. Industry badly needs a new database model to replace the ageing and inadequate SQL model that we have been stuck with for 30 years.
SQL's longer term replacement(s) probably haven't yet arrived but the products currently marketed as "NOSQL" are arguably just an inevitable response to the fundamental problems of SQL.
NOSQL does not have to mean non-relational though. What could really spell the final death of SQL would be a full-featured, industrial strength RDBMS with backing from the right vendors to make it a credible and better alternative to SQL. I would welcome that and I think millions of other SQL customers would too.
March 21, 2011 at 8:21 am
David Portas (3/20/2011)
NO SQL is the answer. Industry badly needs a new database model to replace the ageing and inadequate SQL model that we have been stuck with for 30 years.SQL's longer term replacement(s) probably haven't yet arrived but the products currently marketed as "NOSQL" are arguably just an inevitable response to the fundamental problems of SQL.
NOSQL does not have to mean non-relational though. What could really spell the final death of SQL would be a full-featured, industrial strength RDBMS with backing from the right vendors to make it a credible and better alternative to SQL. I would welcome that and I think millions of other SQL customers would too.
Aging and inadequate are not descriptive enough terms; could you elaborate more on what you perceive as the "fundamental problems of SQL"?
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 21, 2011 at 9:07 am
Eric M Russell (3/21/2011)
Aging and inadequate are not descriptive enough terms; could you elaborate more on what you perceive as the "fundamental problems of SQL"?
The problems of SQL and its failure to support the relational model have been very extensively documented by E.F.Codd, Chris Date and many others: duplicate rows, nulls, lack of data integrity support. See Codd's book "The relational model for database management" or Chris Date's "SQL and Relational Theory".
March 21, 2011 at 9:36 am
I'd argue that SQL needs a replacement, or that RDBMSes are fundamentally flawed. They have fueled and supported a tremendous data explosion and amazing amount of business.
That being said, they are well suited for solving a domain of problems. However we have sometimes applied them to all domains, with problematic results. The NoSQL database systems solve different domains of issues, and do that very well for some of them.
I think that we need to evolve our databases somewhat, and I'd like to see some different evolutions of SQL Server that address different domains, perhaps as separate editions.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
March 21, 2011 at 9:48 am
David Portas (3/21/2011)
Eric M Russell (3/21/2011)
Aging and inadequate are not descriptive enough terms; could you elaborate more on what you perceive as the "fundamental problems of SQL"?The problems of SQL and its failure to support the relational model have been very extensively documented by E.F.Codd, Chris Date and many others: duplicate rows, nulls, lack of data integrity support. See Codd's book "The relational model for database management" or Chris Date's "SQL and Relational Theory".
There are no duplicates, unintended NULLs, or lack of data integrity in the databases that I design using SQL Server. Those are data modeling subjects (primary and foreign keys, check and nullability constraints, normalization, etc.). Even when those issues do crop up, it's the result of inadequate data modeling or SQL coding, not the result of something fundamental lacking in the SQL query language itself.
I think that the industry looks at poorly designed and implemented ISV databases and assume these things represent the pinnacle of what conventional RSMS have to offer, when in fact they are often poor examples developed by hacks.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 21, 2011 at 9:57 am
Steve Jones - SSC Editor (3/21/2011)
I'd argue that SQL needs a replacement, or that RDBMSes are fundamentally flawed.
A DBMS based on SQL is not an RDBMS. It is SQL, not RDBMS, that is flawed.
Outside the specialist SQL professional community it seems to be very widely recognised that SQL is an ailing technology that is failing to meet up to modern needs. I hear this complaint from developers and other IT professionals frequently. Regretably, the SQL professional community seems to be much slower to wake up to this. If there is to be any progress then I believe that the SQL community ought to be supporting the case for a better implementation of the relational model to replace SQL. If they do not then I very much fear there will be no-one to advocate the relational model at all and the relational baby may just get thrown out with the SQL bathwater.
Trying to defend SQL is basically a lost cause. Let's instead stand up for the relational model and recognise that we can and should do much better than the pale immitation of it called SQL.
Eric M Russell (3/21/2011)
There are no duplicates, unintended NULLs, or lack of data integrity in the databases that I design using SQL Server. Those are data modeling subjects (primary and foreign keys, check and nullability constraints, normalization, etc.). Even when those issues do crop up, it's the result of inadequate data modeling or SQL coding, not the result of something fundamental lacking in the SQL query language itself.
So you are acknowledging that those problems exist in SQL. In fact you go to a lot of trouble to avoid them. Sometimes there are no workarounds and sometimes the effort is just too great or the problems aren't recognised untill too late. A few minutes spent reviewing past experiences or Googling for frequently asked questions online should confirm just what vast amounts of effort are wasted trying to get SQL to work as a RDBMS should.
March 21, 2011 at 10:13 am
David Portas (3/21/2011)
Eric M Russell (3/21/2011)
Aging and inadequate are not descriptive enough terms; could you elaborate more on what you perceive as the "fundamental problems of SQL"?The problems of SQL and its failure to support the relational model have been very extensively documented by E.F.Codd, Chris Date and many others: duplicate rows, nulls, lack of data integrity support. See Codd's book "The relational model for database management" or Chris Date's "SQL and Relational Theory".
I may be wrong here, but I don't see the NO SQL movement caring much at all about the relational model. I picture NO SQL as using one, big, flat table to dump a huge amount of data in. After all, disk space is plentiful and cheap, and so is processing power - so who needs multiple tables or relations between them? Am I misguided about that?
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
March 21, 2011 at 10:31 am
I am joining this discussion a bit late but please let me put my two cents in.
In my experience, the problem is not that SQL is an inadequate tool for handling RDBMS -- the problem IMO is that RDBMS is inadequate for many business tasks. You can build an SQL-based system(s) for a small manufacturing company and it will be all swell, except for bills of material: bill of material is one of those problems that just do not yield themselves to relational model. (At least not easily.)
We need SQL extensions that would allow us to handle this type of problems.
March 21, 2011 at 11:37 am
Revenant (3/21/2011)
In my experience, the problem is not that SQL is an inadequate tool for handling RDBMS -- the problem IMO is that RDBMS is inadequate for many business tasks. You can build an SQL-based system(s) for a small manufacturing company and it will be all swell, except for bills of material: bill of material is one of those problems that just do not yield themselves to relational model. (At least not easily.)
The problem you describe is generally harder than it needs to be in SQL for at least three reasons: SQL's appalling "recursive query" syntax; SQL's lack of support for a simple transitive closure operator; insufficient physical data independence in most SQL products (this partly due to difficulties inherent in implementing the SQL model). These are not problems with the relational model, which ought to support bills of materials applications quite well. This is in fact one example of where SQL, not the relational model, has failed to meet a basic need of many applications.
We need SQL extensions that would allow us to handle this type of problems.
"Extending" SQL is ultimately a blind road. There are too many problems with SQL. If we fixed all of them then we'd have a new DBMS that would look fundamentally different from and be incompatible with the SQL we know today. There wouldn't be much point in pretending the new model was still SQL. You might preserve some of the SQL syntax in the transition but why would you even want to do that? SQL is such a peculiar language with so many odd and redundant bits of syntax that a better approach would be to make a clean sweep and create new languages that are designed right from the beginning.
March 21, 2011 at 12:14 pm
So you are acknowledging that those problems exist in SQL. In fact you go to a lot of trouble to avoid them. Sometimes there are no workarounds and sometimes the effort is just too great or the problems aren't recognised untill too late. A few minutes spent reviewing past experiences or Googling for frequently asked questions online should confirm just what vast amounts of effort are wasted trying to get SQL to work as a RDBMS should.
David Portas
No, I think I made it clear where the fault lay with failed relational databases. A database that is normalized and contains primary keys, referential keys, and check constraint that match the business requirements works well with SQL. SQL is a declarative language, and SQL databases have a declarative data model. It obviously doesn't work well for non-structured data or fuzzy business requirements, but that's a niche or peripheral case usage for a database.
I'm not interested in an academic point of view about SQL; it's their job to constantly argue anything. As a professional database developer, an actual practitioner, what do YOU perceive as being practical and fundamental limitations the SQL language or conventional RDMS like SQL Server or Oracle? Give us specific examples as a point of reference for a discussion.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 21, 2011 at 12:23 pm
Eric M Russell (3/21/2011)
I'm not interested in an academic point of view about SQL; it's their job to constantly argue anything. As a professional database developer, an actual practitioner, what do YOU perceive as being practical and fundamental limitations the SQL language or conventional RDMS like SQL Server or Oracle? Give us specific examples as a point of reference for a discussion.
Also, given the editorial that this is commenting on, it would be helpful if you (David, not Eric) pointed out where the database products that make up the NoSQL segment of the market handle these limitations better than a SQL-based RDBMS.
Viewing 15 posts - 16 through 30 (of 45 total)
You must be logged in to reply to this topic. Login to reply