Hybrid Databases

  • Comments posted to this topic are about the item Hybrid Databases

  • I think there is a danger in trying to do everything on a single platform (in this case SQL Server) as opposed to employing enterprise level subsystems designed to specifically handle certain processing/functional roles.

    Having said that, this is totally one of those classic "it depends" situations.

    In my opinion, it is not necessarily right to do all that is mentioned in the editorial in SQL Server but great that, when deemed appropriate, one can.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • SQL Server has for the last couple of releases been extending beyond the traditional relational model for storing and retreiving data. For example, we now have support for indexed XML datatypes and Semantic query extensions on top of FullText engine, which extends the variety of data that can be effectively managed within a database. Analysis Services has been around since v7.0, and we could think of OLAP has a type of NoSQL solution. ColumnStore is promising as a "big table" solution (even though 2012 doesn't provide update capability).

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell (9/30/2013)


    SQL Server has for the last couple of releases been extending beyond the traditional relational model for storing and retreiving data. For example, we now have support for indexed XML datatypes and Semantic query extensions on top of FullText engine, which extends the variety of data that can be effectively managed within a database. Analysis Services has been around since v7.0, and we could think of OLAP has a type of NoSQL solution. ColumnStore is promising as a "big table" solution (even though 2012 doesn't provide update capability).

    And I still have as yet to come across a solution that provides SQL Server DB recovery in a decent time frame when the DB is holding binary, varbinary, extensive XML or similar data.

    The use of the FSO model for data import is problematic. SSIS is fraught with problems including it's limited debugging options. BCP is ancient.

    My last company, when I left over five years ago, had a 70GB DB filled with just the pointers to files (image, pdf, and office docs) on disk. The restore, for upgrades, was always a nightmare. The files on disk were past the 2TB size already.

    Storage of binary data in a DB is zero option for me and always will be. If you want to buy into the M$ idea of Sharepoint and similar SW go for it. I don't.



    ----------------
    Jim P.

    A little bit of this and a little byte of that can cause bloatware.

  • I found myself agreeing with what you were saying in the editorial until you mentioned Reporting Services - it's so messed up (unless they've fixed it in 2012), it needs to die or be fixed.

    Specifically the report builder tool that you use over the internet.

    RB v3 that came with 2008R2 is just broken due to a school boy error whereby 1 connection is used for everything and never closed leading to a crashed application. Unless you know the crappy workaround - which even then delays the inevitable crash.

    We built a web app (ASP.NET MVC) and used reporting services for the reporting side. The idea being that users could write their own reports. In this scenario all the sharepoint integration bollocks etc.. they've added in later versions is completely irrelevant.

    And don't even get me started on the fact that in order to get a direct access to the tables (in our case a separate DB built from the real one especially for reporting) instead of using a reporting model you have to know a SQL username and password. WTF! and use a VPN connection.

    ZOMG just give us an MS Access style report designer/query manager that can be used over the internet like the report builder and have the results stored on the server so that it can be responsible for running/rendering the report and all would be fine.

    I could even forgive the absolute nightmare that is changing the reporting services config files to allow custom authentication.

    :crazy: Sorry for the rant, I haven't had my morning cuppa' yet.

  • Jim P. (9/30/2013)


    Eric M Russell (9/30/2013)


    SQL Server has for the last couple of releases been extending beyond the traditional relational model for storing and retreiving data. For example, we now have support for indexed XML datatypes and Semantic query extensions on top of FullText engine, which extends the variety of data that can be effectively managed within a database. Analysis Services has been around since v7.0, and we could think of OLAP has a type of NoSQL solution. ColumnStore is promising as a "big table" solution (even though 2012 doesn't provide update capability).

    And I still have as yet to come across a solution that provides SQL Server DB recovery in a decent time frame when the DB is holding binary, varbinary, extensive XML or similar data.

    The use of the FSO model for data import is problematic. SSIS is fraught with problems including it's limited debugging options. BCP is ancient.

    My last company, when I left over five years ago, had a 70GB DB filled with just the pointers to files (image, pdf, and office docs) on disk. The restore, for upgrades, was always a nightmare. The files on disk were past the 2TB size already.

    Storage of binary data in a DB is zero option for me and always will be. If you want to buy into the M$ idea of Sharepoint and similar SW go for it. I don't.

    I'm not a fan of "dumping" unstructured or BLOB data in-row in a RDMS either. The impression I get is that most users of NoSQL database solutions are basically just application developers who need some way to persist the session state of their web application, typically something like serializing the contents of a shopping cart as XML or JSON and then holding it temporarily until the user gets to the check out page. I'd actually prefer the website keep it's "stuff" in something like MongoDB. So long as the final purchase order gets properly stored in the RDBMS accountting system when the user clicks the 'Submit' button; that's all the business cares about.

    I once worked for a company that provided a check imaging solution for banks. There was a transaction table, which contained a handful of columns like acct number, routing number, amount, etc. which were scanned from the physical check. The check image (a TIFF file) was stored within one of various folders in the file system. There was no "pointer" to the image, there was no path or URL inside the row. The actual path for containing the image was instead assumed based on client setup, and the image name was based on the row's unique transaction_id, which was simply an incremental integer or identity. So the storage of document images required no additional storage in the database.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Full-text searching has always been something of a disappointment for me.

    SSIS is one of those tools that when I come back to it I spend a week swearing at it before I click into its way of working. I spend time fighting the tool rather than using it.

    Service Broker is one of those facilities that was, on paper, very interesting but fell somewhat short and was overly complex.

    It's very noticeable that the people who were evangelising about storing XML in the DB now regard it as a burden and a curse. They're onto JSON/BSON now! I await their next passion like a benevolent Grandfather. The old man's mistress is not the young man's whore etc.

  • If all an application requires from it's "database" is a holding area for serialized XML or JSON objects which it later fetches based on a unique ID, then I'd consider going to the opposite extreme and just persist the objects as memory mapped files. In this scenario, a document based NoSQL solution would seem like an unnecessary hybrid that offers neither the structure of an RDMS or the speed and simplicity of a file system.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply