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

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

    @cbae:  Yep, very correct.

    But I would add that sometimes things are just way too normalized.  For example, if you have a table CompanyInfo and another CompanyAddress, and by the design of your system they will always be one-to-one, those should probably be combined into the same table.

    I see this often at my current job where a backend database was designed with an explicit goal of being in third normal form.  The original DBAs have left, and the current DBAs have a desire to flatten the schema in cases like those.  It not only makes the data model simpler, but provides better join performance at practically no cost to reporting performance.

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

    , fanbaby wrote

    Maybe this is relevant to this fine thread.

    The best point I got out of that article was "I was a hipster before you were even born."  PostgreSQL had certain features in 2005 that have a taste of some features that MongoDB had later.  But if you think this makes MongoDB worthless, then I assume you agree that Smalltalk makes C# worthless.

    This article highlights one of the main problems with the OnlySQL crowd.  They think because they only do things one way, that NoSQL only does things one way.  But NoSQL is saying "we are NOT going to do everything this one way you guys call SQL".  There are many flavors of NoSQL out there:  tuple/KV stores, document stores, object databases, graph databases, and others.  They don't all subscribe to "the MongoDB way" and this is so important to understand.  We need to stop thinking that there has to be one solution for everything and start looking for the right solution for right now.

    I also grow weary of the idea that NoSQL databases aren't ACID compliant and are not transactional.  It's true that some aren't.  But some are and have always been so.  MongoDB isn't the only NoSQL database, and if you think that it is, you are doing yourself a huge disservice in learning about very powerful and well-designed tools that are available for your needs.

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

    @spivonious:  I hate Oracle.  With a passion.

    Ok, maybe not so passionate, but seriously why in the year 2014 do so many companies insist on using a database that doesn't even allow you to use table/column names that are greater than 30 characters in length?

    And worse, the recommended Oracle naming convention is using UNDERSCORES_INSTEAD_OF_PASCAL_CASE (oops, that's 34 characters, would've fit if it were Pascal case).  In an Oracle DB I reluctantly work with, we have so many abbreviations that we can't even tell what's what most of the time.

  • Has your passion for I.T. ever got you in trouble?

    @TexasToast:  Yes, I am so ashamed.  Thanks to you, I now recognize that I am a lowly person.  I will turn myself into the police and rot in jail for the atrocities against humanity I have committed.

  • Has your passion for I.T. ever got you in trouble?

    I didn't really get in trouble, but one time the local news was running an online poll to decide which high school (American) football team would be the next "game of the week".  My roommate's old school was in the running.

    By the time I was done with it, a few minutes later, that team shot up from the middle to having 99+% of the votes.  They indeed became game of the week, but the news channel said the next week, "And please only vote once."  Haha.

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

    @magicalclick:  I'm not really sure.  I've only ever used db4o in embedded mode, so roles weren't an issue.

    And for that matter, I wouldn't recommend db4o as a solution.  Go with something that now has a bigger user base and more documentation.

    db4o had a lot going for it when it was bought by Versant, and they maintained it well.  But Versant got bought by another company and may have changed hands again since then.  db4o hasn't had any updates in two years.  I emailed Versant support and asked if it was still going to be supported, and they said that since the buy-out, they haven't put a plan in place for db4o.

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

    @RealBboy360:  I think it would be great if Microsoft came out with a way to make their database server conform to the needs.

    The question of Relational vs. Object/Document feels similar to me as the question of standard vs. clustered index, or row-oriented vs. column-oriented.  You can't have both and each has its advantages in certain cases.  Microsoft might do very well if perhaps when defining the tables, you could tell SQL Server to act as a document store rooted at a certain table, so that your on-disk structure is optimized for that scenario.

    From a user perspective, you would still get the standard capabilities of SQL if you need them.  Or, I imagine you could access items in a more OO fashion (since their relationships are guaranteed to be defined in such a way that the document storage mechanism works).

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

    , magicalclick wrote

    I think back in the days I played with Cache, which failed miserably on me. I did a one-to-many relationships both way to imitate many-to-many relationship. The end result is it failed without an error, just gave me seemly correct and yet incorrect result.

    I've never used Cache but I understand this general problem.

    In the relational world you would use a junction table to provide this many-to-many relationship.  This works around the fact that relational records can only hold single values and not arrays.

    In the object world, you have more options.  You can store an array inside of an object.  This is great for one-to-many relationships!

    What I see often is that the many-to-many is modeled as arrays from each object to the other (a bipartite graph).  But this may not be the best thing, as you can get into the problem you mentioned, since each relationship from one to the other is modeled on both objects.  So breaking the relationship on one of the two objects could leave the other orphaned.

    One alternative is to just implement the equivalent of junction tables in the object model.  When you come to think about it, all that a junction table does is describe the set of relationships in a bipartite graph.  I don't know that this is the best alternative.  But, if you think about it, this problem isn't because the OO model lacks something the relational model has, but because it offers more than the relational model does.

    (And it should be noted, this isn't an OODB or NoSQL problem... it's an OO problem.  If you are mapping from a SQL database to objects in memory, you may have to consider this issue anyway.)

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

    @RealBboy360:  Just like there are ways to workaround the limitations of the relational model, the same exists for NoSQL.  In my case I would setup db4o to only activate objects one level deep, so it only gives me the top-level employee object.  (This is essentially a lazy-loading mechanism.)

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

    By the way, my storage code:

    using (var unitOfWork = _database.UnitOfWork)
    {
        unitOfWork.Store(Data);
        unitOfWork.Commit();
    }

    Other than some configuration code (connection string type stuff), that's it.  No ORM mappings, no SQL, just 3 lines of code.  That has saved our project months in development costs.