Re: The Guy Who Invented Arrays



  • Also, we need a separate thread just to keep up on the doing of our favorite Oracle consultant.  The latest is to be found on http://www.dbdebunk.com/page/page/606457.htm

    Haha! I remember that one; I sent it in. Here's the amusing thing about it, just in case some don't get it.

    Originally, in the Bad Old Days of mainframes, we had these things called hierarchial databases, which used pointers to link related items of data together. Needless to say, as soon as you started doing anything at all complex, your code for getting through this mess of pointers turned into a nighmare. (Think about the last time you had some complex data structure stored as six or eight layers of nested hashtables in Perl.)

    So one day a guy named Codd came along and said, "there's got to be a better way." And he came up with one, and called it "relational database management."

    Then a while later a company called Oracle creates a product that is in fact an efficient, effective implementation of an RDBMS. People look at this, say "wow!", migrate away from all their hierarchial databases, and have no more pointer problems. Hierarchial databases wither and die, because nobody will buy them any more.

    And then Oracle, having killed hierarchial databases and their PITA pointer manuipulations, introduces....



  • Yeah, too bad the lack of transitive closures meant that RDBMSes were shit for storing hierarchical data.



  • 60's tech

    This is the reason that "object databases" have not caught on. They are just referential databases rebadged. Relational databases are better. Referential databases are a step back.

    Note the comaprson with XML. Raw XML is hierarchical. XML with XPath and pointers is referential. It still hasn't caught up with the relational model, which has been around for years. That's why using XML to store bulk data sucks compared to doing it the Right Way and putting together an SQL database.



  • And now nosql is all the rage again


  • FoxDev

    Haven't you heard? It's webscale!


  • :belt_onion:

    No, that's not just any NoSQL - that's MongoDB


  • BINNED


  • Discourse touched me in a no-no place

    ...ONEONEONEELEVEN

    ­


  • Considered Harmful

    @Onyx see this is how medical shows kill people and threads. You shocked it right as it was getting better, doc.


  • Considered Harmful

    On topic, my advice is (coincidentally coincident with my general advice which is) "make it irrelevant". Your RDB is going to differ from the ANSI standard in important ways - fine! Use that, but use it in a way that depends strongly only on the capability it provides, vs the implementation of that capability. So you can use Oracle OR Mongo madness but don't let the details spread past that layer, just make an @implSpec indicating what property you're depending on to provide the characterization indicated in your @apiSpec.


  • Discourse touched me in a no-no place

    @Gribnit Sometimes you should let the capability of the database tech you're using spread to higher levels. For example, if your DB engine supports full text searching (and it makes sense to use it) then by all means provide the search in ways that the higher levels can see. Having a DB that can do that and then saying "no, I want to complement that (badly) in my own code to preserve layer separation" is just stupid.

    Bet it has been done...


  • Considered Harmful

    @dkf said in Re: The Guy Who Invented Arrays:

    @Gribnit Sometimes you should let the capability of the database tech you're using spread to higher levels. For example, if your DB engine supports full text searching (and it makes sense to use it) then by all means provide the search in ways that the higher levels can see. Having a DB that can do that and then saying "no, I want to complement that (badly) in my own code to preserve layer separation" is just stupid.

    Bet it has been done...

    Sure, you let the capability spread freely, but not the direct dependency - use FTS from the DB but unless % means wildcard for your own reasons, don't let/make client code put them in.


Log in to reply