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

Not Good Enough For Government Work Expand / Collapse
Author
Message
Posted Monday, July 14, 2014 10:16 PM


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: Monday, November 10, 2014 12:04 PM
Points: 590, Visits: 2,565
Comments posted to this topic are about the item Not Good Enough For Government Work


Best wishes,

Phil Factor
Simple Talk
Post #1592404
Posted Tuesday, July 15, 2014 5:21 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Today @ 5:46 AM
Points: 312, Visits: 3,530
The moral of the story being, if your database vendor doesn't use it for their accounts, don't run your 'bank' on it.

I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
Post #1592514
Posted Tuesday, July 15, 2014 6:33 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, November 5, 2014 7:40 AM
Points: 4, Visits: 62
Like I've always said: a good developer recognizes that he can't be an expert in everything. I once had someone ask me if I was a SQL expert, I laughed and said I've been in the software world for 15 years, and I've never even met one!
Post #1592523
Posted Tuesday, July 15, 2014 6:33 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 1:25 PM
Points: 203, Visits: 394
If you give a mechanic a new tool, does he dump all his other tools? No, but it seems developers tend to view the latest new database widget as the replacement for all the others. Anyone remember object databases?

The more you are prepared, the less you need it.
Post #1592524
Posted Tuesday, July 15, 2014 6:45 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, October 1, 2014 7:50 AM
Points: 52, Visits: 420
Without reading the underlying links, I would guess at issue is the classic conflict between .net/java/whatever developers and database architechs/developers/dbas. Like many others on this forum, I have seen both sides and can understand the "whatever" developers desire to do what they want, to just use the database as a more permanent datastore. However, as you've pointed out, the rules/guidelines/best practices are there for a reason and the events revealed the gross lack of understanding/experience/(fill in blank here) of the architects.

The follow up question, as I am responding off the top of my head, are those really 2 separate issues?

1. Don't know or want to know the best practices for handling data and why DB architecture (schema and code for ACID-ity) is important.
2. Don't have the experience with these kinds of systems and the forethought to consider the soundness of the code, not just that it completes the drawn-up workflow diagram, and test for possible security issues.

Amateurs indeed.
Post #1592527
Posted Tuesday, July 15, 2014 7:07 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Sunday, November 23, 2014 2:48 PM
Points: 1,754, Visits: 4,966
NoSQL databases are a solution to a wide range of niche applications that for the most part didn't exist a decade ago. However, Bitcoin is a revolutionary new business model built on top of what should be a traditional stock trading database, so the concepts of ACID proof transactional processing should still be applied. What's going on is that these NoSQL database vendors are seeking venture capital, so the movement is steeped in kool-aid and guerrilla marketing. A lot of organizations are getting led down the proverbial primrose path.
Post #1592539
Posted Tuesday, July 15, 2014 7:31 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Today @ 12:36 PM
Points: 378, Visits: 2,615
From what I've read, these systems were caching in separate threads and fell victim to "lost transactions." Given the details, I'm not all that sure these guys would have faired any better with a relational database back end with coding and testing like that.

Is it impossible to have acid properties in a system using a non relational database? Using MongoDB? Using any NoSQL?
Post #1592555
Posted Tuesday, July 15, 2014 7:34 AM
SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Today @ 8:11 AM
Points: 175, Visits: 1,877
The key measure for all sorts of buggy and risky problems is whether or not they are insurable. These are process questions for the most part, not coding ones.

Post #1592558
Posted Tuesday, July 15, 2014 7:44 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: Monday, November 10, 2014 12:04 PM
Points: 590, Visits: 2,565
@patrickmcginnis59

Yes, it is certainly possible to have a NoSQL database that handles ACID properly. It just surprises me that some don't. As I understand the Bitcoin exploit, I can't see how it would have happened with multi-user RDBMS. This is, after all, a problem that is intrinsic to any trading or banking system. The links are well-worth reading if you're interested in the details.



Best wishes,

Phil Factor
Simple Talk
Post #1592563
Posted Tuesday, July 15, 2014 7:44 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Sunday, November 23, 2014 2:48 PM
Points: 1,754, Visits: 4,966
At least for as long as I can recall, and probably dating back to Sybase, SQL Server has given the developer some flexibility over isolation level. Starting with SQL Server 2014, we now have the DELAYED_DURABILITY database option.

I havn't read up on this particular new feature yet, but does anyone know if ISOLATION LEVEL READ UNCOMMITTED is now even more problematic when combined with DELAYED_DURABILITY = ALLOWED ?
Post #1592564
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse