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 12345»»»

It Happens Expand / Collapse
Author
Message
Posted Tuesday, September 24, 2013 8:39 PM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 11:24 AM
Points: 32,781, Visits: 14,942
Comments posted to this topic are about the item It Happens






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1498107
Posted Wednesday, September 25, 2013 1:51 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 3:49 PM
Points: 2,866, Visits: 1,708
It's a harsh fact of life and a quick look down the list of fixes in the older versions of SQL Server reveal some quite nasty bugs.

There is inherrent complexity in having fine grained multi-concurrent data systems. NoSQL is a very broad church so generalisations about NoSQL are risky. What I would say is that the NoSQL solutions are young and there will be bugs that we've forgotten we used to have in RDBMS's.

The companies behind the NoSQL products are energetic, enthusiastic and keen to improve their products. That is something to be welcomed.



LinkedIn Profile
Newbie on www.simple-talk.com
Post #1498170
Posted Wednesday, September 25, 2013 2:39 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Thursday, April 17, 2014 6:05 AM
Points: 1,528, Visits: 5,172
I always like Maurice Wilkes' quote about this:

"I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs."

That was back in the late 40s, I believe, so this has been going on for a while! It doesn't help that SQL, as a language, isn't really well designed for debugging--it's one of the few languages I've used where I find it faster to just rewrite a line of code that isn't working rather than try to figure out why it isn't.
Post #1498194
Posted Wednesday, September 25, 2013 3:34 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Yesterday @ 3:03 AM
Points: 61, Visits: 384
SQL has strong roots in relational algebra, this makes it harder to implement but easier to verify. If you use concepts like 'eventual consistency' it is much harder to find out wether everything still acts according too the rules in every possible case. Transactions and isolation levels are also based on a clear set of rules, with the same effect: hard to do it right, but not too hard to check if it's done right.

NoSQL generally means non-relational. Google returns to SQL for access to large data, for several reasons. I don't think SQL and the relational model are the only option when it comes to databases. However, when a model is based on some theoretical foundation, it is easier to prove that certain constraints will always be satisfiied. Does anyone has already encountered a candidate that rivals the relational model in this aspect?
Post #1498214
Posted Wednesday, September 25, 2013 3:35 AM


SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Wednesday, April 16, 2014 8:20 AM
Points: 4,862, Visits: 2,243
paul.knibbs (9/25/2013)
...It doesn't help that SQL, as a language, isn't really well designed for debugging--it's one of the few languages I've used where I find it faster to just rewrite a line of code that isn't working rather than try to figure out why it isn't.


Debugging support has been designed into languages in mainstream use for some time now, however, there are plenty of examples of languages where this has had to be shoe horned in. Given that the majority of current popular languages have been designed in an era where Internet development was coming to the fore it is not surprising that these languages have embraced networked development from the off. The trouble is that I have yet to see a mainstream language with a clean implementation for mutlithreaded programming.

How does this relate to the editorial? Without high level abstracts to support such abilities code will be more prone to errors. Memory management is a fine example of this (especially as it highlights something where most languages can take control of but not all languages should).


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1498215
Posted Wednesday, September 25, 2013 4:52 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, October 09, 2013 3:49 AM
Points: 24, Visits: 76
"embrace the idea that code can be wrong" -- Nathan Marz

Surely this is the wrong approach, as it just gives people an excuse to be lazy.

Code should NEVER be wrong.

It is not difficult to write code that works correctly.

You just need to follow two simple rules:

1) Be crystal clear about the valid set of inputs, and throw an appropriate exception if the input is not in the valid set.

2) If you are not sure whether the logic is correct, break your code into smaller functions/procedures until it is 100% clear that it will work correctly in all cases.

Bugs only arise when people do not follow these simple rules.

Simon
Post #1498250
Posted Wednesday, September 25, 2013 5:55 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, November 25, 2013 11:59 AM
Points: 10, Visits: 72
Steve, did you make all those typos in your "It Happens" paragraphs just to make the point that we could still somehow figure out what you were saying? You're so clever!
Post #1498277
Posted Wednesday, September 25, 2013 6:26 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Friday, April 04, 2014 8:42 AM
Points: 598, Visits: 1,504
It is not difficult to write code that works correctly.


You can write good code, but chances are you don't write perfect code, all the time. Just because it works, doesn't mean it's correct or right for all situations. Try writing a huge complex business application that runs on three different RDBMS, the desktop and the web, with features to satisfy hundreds of different companies with thousands of users with data collected from millions of people.

(There's a corollary to this about data: "All data is bad, some data is worse.")
Post #1498293
Posted Wednesday, September 25, 2013 6:33 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, October 09, 2013 3:49 AM
Points: 24, Visits: 76
paul.knibbs (9/25/2013)
I always like Maurice Wilkes' quote about this:

"I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs."

That was back in the late 40s, I believe, so this has been going on for a while! It doesn't help that SQL, as a language, isn't really well designed for debugging--it's one of the few languages I've used where I find it faster to just rewrite a line of code that isn't working rather than try to figure out why it isn't.


That's a lot less depressing than realizing that a large part of your life from now on will be spent in debugging and correcting mistakes in other people's programs.

I have worked on quite a range of projects. Some systems are clearly written by people who care about the quality of their code, and other systems are clearly written by people who are only interested in adding a new technology to their CV before moving on to the next step on their intended career path and don't really care about the trouble they are causing for the people who will have to sort out the mess when they are gone.

Simon
Post #1498298
Posted Wednesday, September 25, 2013 6:40 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: 2 days ago @ 5:55 AM
Points: 1,887, Visits: 1,862
"I hope that's not too gloomy a view of software."

I wrote my first program on punch cards in the late 1970's. Today I do .NET development, SQL development, and SQL Administration. In my experience, I don't think the view that our programs will have bugs or may not work entirely as intended is too gloomy. I don't think that's an excuse to be lazy either. I just think it shows the maturity that's required to realize we're not perfect.

It's delusional to arrogantly deploy a solution and then walk away thinking it's perfect and will never need to be touched again.

As soon as we have perfect humans we can then start expecting perfect programs. It may be a long wait...

Until then, I think the best approach is test-driven-development with continuous integration. Continually adding and improving test cases is not lazy. It's a lot of work and there are many places that skip test cases thinking they don't need them. That's lazy.

Test-driven-development with continuous integration acknowledges our imperfections while still trying our best to deliver the highest quality possible.
Post #1498300
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse