Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Discussions

Bass Bass I need better writers.
  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    , evildictait​or wrote

    Here is an easy fix for MongoDB's inability to do transactions or safely store data.

    Take the thing you want to store. JSON serialize it. Put that in a SQL table (called JSONtable) stored under a GUID index.

    When you want it back, select the object you want by its GUID and then deserialize it.

    Voila and congratulations. Now you have all of the benefit of a schema-less database, plus the transactionality, able-to-deal-with-lots-of-data-ness and likely-to-not-get-corrupted-ness of SQL.

    You're welcome.

    You could do that, but well.. yeah. That would work.

    But doing MapReduce or indexing on arbitrary properties of the JSON object would be kind of um, challenging to say the least. A lot of that can be solved simply by using PostgreSQL. Nevermind that though, f**k SQL. :)

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    , bondsbw wrote

    *snip*

    This by itself is a virtue. :)

    Indeed. SQL is a relic of the 1970s that just won't go away. It was designed in a era before the Internet, before PCs, back when vaguely English-looking ALL CAPS languages like COBOL were all the rage and programmers wore suits.

    And of course, it was designed completely without regard to object-oriented programming and people now suffer with ORMs to this day because of that. Simply awful. It's like they don't realize better options exist.

    I think it's completely amazing that these days I can like store data in a database by like, telling my database, well, store the data. Whoa dude. What a f**king concept! :) Totally revolutionary!!

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    , AndyC wrote

    *snip*

    It's only a virtue if you know what you're doing. So many web devs writing systems that would massively benefit from SQL and having it cripple or corrupt things by using NoSQL because they think being newer os better or cooler (or anything that uses the phrase web scale!)

    That's not a virtue, that's just being ignorant.


    It's only a virtue if you know what you're doing. So many web devs writing systems that would massively benefit from COBOL and having it cripple or corrupt things by using C# because they think being newer os better or cooler.

    That's not a virtue, that's just being ignorant.

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    , ScanIAm wrote

    When the product is written by the same company that made the OS?  Closed source in that case will always have an advantage.

    So the Microsoft Windows team and SQL team are working together to give their DB an advantage over 3rd party DBs on Windows? Interesting. I think some investigators over in the European Union and US Department of Justice could use some more information.

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    , spivonious wrote

    Absolutely. The need for NoSQL came about from Google and Facebook handling terabytes of data. But web programmers seem to be jumping all over MongoDB even for tiny datasets. Part of me wants to think that it's because they're too lazy to learn SQL and want to do everything in JS. A good, well-setup RDBMS can be extremely fast and efficient.

    Yup, I believe that's 99% of the reason to use MongoDB. Most people never run into the scaling issues of SQL because they work with "small" datasets (which I will define something less then Google). So the reason most are using MongoDB is indeed, due to laziness and a desire to avoid SQL. By the way, laziness is one of the principal virtues of a good developer.

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    @spivonious:

    MapReduce.

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    , RealBboy360 wrote

    Yeah, I know some things are better in some situations and nosql is probably more scalable, but could this reverse the trend of everyone going to mongodb or whatever?  The only enterprise part is no fun though.

    MongoDB's primary advantage is that it is schema-less and uses JavaScript and JSON (BSON), which tends to also be the kind of data organization web applications often use tons of.

    It's also really fast and web scale. SQL is not web scale. But seriously, that video is criticizing a really old version of MongoDB that didn't support journaling.

    You can still turn it off of course! Without journaling, MongoDB will write to memory, and only write to disk when it is optimal to do so. If MongoDB or the server it is running from crashes, you will likely lose some data.

    It wouldn't be MongoDB without supporting probabilistic durability and consistency. Because you know there is still a decent chance that your data will be stored even without enabling full durability, and writes especially will be noticeably faster if you disable it. Not every application the planet needs 100% durability all the time, especially when there is a massive unavoidable cost in overall performance for that guarantee.

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    Redis.

  • Heartbleed

    , blowdart wrote

    *snip*

    Not true. It wasn't discovered by code reviewing but by testing of the binaries, black box testing, as you would also do with closed source.

    http://www.latinpost.com/articles/10440/20140411/heartbleed-bug-discovered.htm

    According to Karjalainen, he and Hietamäki were testing some new features for Codenomicon's protocol test suite with a feature called Heartbeat, which sends data between servers to see if it comes back unaltered.

    Fair enough. You can also audit proprietary code directly (well, not the original code, that's not available) using various debugger/disassembler tools.

    Maybe I shouldn't have went that far - open source makes it easier to independently audit someone else's code. And possibly, in various jurisdictions where reverse-engineering is may be illegal or at least a gray area, allows you to do it legally.

  • Heartbleed

    Yeah, but.. the only reason this vulnerability was discovered is because OpenSSL is open source.

    So the whole open source is inherently more secure comes from Linus's law. But there is an "axiom" that must apply first:

    "given enough eyeballs, all bugs are shallow"

    The key is "given enough eyeballs". Short of the really big open source projects, there is only a handful of people who are both qualified to review the code and willing to. Or restructuring this statement, all bugs are not shallow, unless the FOSS project has enough eyeballs. Therefore, it is not a statement on the quality of FOSS in general. Rather it is a statement that the correctness of a software system is dependent on a variable linked positively to the # (and arguably, the "quality") of the eyes looking at it.

    But that doesn't even require FOSS necessarily. Right? Because you know, Microsoft can hire a metric ton of high quality eyes to look over their code. If they do this, under Linus's law their bugs will be shallow. I don't disagree with this. I think Linus's law is pretty reasonable, it's just that people have been reading and extending it incorrectly.

    So what is something that we can claim is a characteristic of FOSS that doesn't exist in proprietary systems when it comes to security and bug fixing?

    At the basic level, open source allows (but does not guarantee) the existence of independent review of other people's original code, even without informing the original author's first. Proprietary software well, does not. It's just fact. Maybe that's what should be been made into a law. I call it Bass's law.