36 years of relational databases

Discussion in 'NZ Computing' started by Lawrence D'Oliveiro, Jul 23, 2006.

  1. I didn't realize, it was 36 years ago last month that E F Codd published his
    seminal paper introducing the concept of relational databases:
    <http://www.acm.org/classics/nov95/toc.html>.

    Seems so simple nowadays, it's hard to imagine how revolutionary it was back
    then. Though he does call them "data banks" ...
    Lawrence D'Oliveiro, Jul 23, 2006
    #1
    1. Advertising

  2. Lawrence D'Oliveiro

    Shane Guest

    Lawrence D'Oliveiro wrote:

    > I didn't realize, it was 36 years ago last month that E F Codd published
    > his seminal paper introducing the concept of relational databases:
    > <http://www.acm.org/classics/nov95/toc.html>.
    >
    > Seems so simple nowadays, it's hard to imagine how revolutionary it was
    > back then. Though he does call them "data banks" ...


    Ive just started the Introduction to Databases paper at tech. One of the
    tutors did his degree (and masters?) at the same place Codd did (Exeter
    College Oxford?)

    The next generation after Relational databases is supposed to be OO
    databases (of which Jade at one point was making a ton of money from) but
    they seem to have fizzed



    --
    Rule 6: There is no rule 6

    Blog: http://shanes.dyndns.org
    Shane, Jul 23, 2006
    #2
    1. Advertising

  3. "Shane" <-a-geek.net> wrote in message
    news:e9vf4g$shh$...
    > Lawrence D'Oliveiro wrote:
    >
    >> I didn't realize, it was 36 years ago last month that E F Codd published
    >> his seminal paper introducing the concept of relational databases:
    >> <http://www.acm.org/classics/nov95/toc.html>.
    >>
    >> Seems so simple nowadays, it's hard to imagine how revolutionary it was
    >> back then. Though he does call them "data banks" ...

    >
    > Ive just started the Introduction to Databases paper at tech. One of the
    > tutors did his degree (and masters?) at the same place Codd did (Exeter
    > College Oxford?)
    >
    > The next generation after Relational databases is supposed to be OO
    > databases (of which Jade at one point was making a ton of money from) but
    > they seem to have fizzed
    >


    I always thought Jade was a system generator, based on business rules, a la
    LINC, which was Simpson's idea ported into the mainframe world and sold
    through Burroughs, then Unisys. When Unisys bought LINC, Jade was created to
    reach another level of computing.

    --

    Mauricio Freitas
    www.geekzone.co.nz, www.geekzone.co.nz/freitasm,
    www.geekzone.co.nz/geekzoneblog.asp
    Software for Pocket PC: www.geekzone.co.nz/store
    Microsoft MVP Mobile Devices
    Mauricio Freitas [MVP], Jul 23, 2006
    #3
  4. In message <e9vf4g$shh$>, Shane wrote:

    > The next generation after Relational databases is supposed to be OO
    > databases (of which Jade at one point was making a ton of money from) but
    > they seem to have fizzed


    There are still people trying to push that idea. It never succeeded because
    it could never demonstrate any superiority to the relational model. To this
    day, the relational model remains the one with the strongest theoretical
    grounding, and that reflects in its practical usefulness.
    Lawrence D'Oliveiro, Jul 23, 2006
    #4
  5. Lawrence D'Oliveiro

    Bok Guest

    Mauricio Freitas [MVP] wrote:
    > "Shane" <-a-geek.net> wrote in message


    >> The next generation after Relational databases is supposed to be OO
    >> databases (of which Jade at one point was making a ton of money from) but
    >> they seem to have fizzed
    >>

    >
    > I always thought Jade was a system generator, based on business rules, a la
    > LINC, which was Simpson's idea ported into the mainframe world and sold
    > through Burroughs, then Unisys. When Unisys bought LINC, Jade was created to
    > reach another level of computing.


    JADE is significantly different to LINC and is not a system generator.
    JADE is both an OO development environment and the execution platform.
    It has an integrated OO database and language. With LINC developers used
    a 4GL like language to define entities such as Events and Components and
    business rules in a procedural fashion. This specification was then
    used to generate source and a database definition for a target OLTP
    (Online Transaction Processing System).

    There is no such generation process in JADE. It's actually closer to
    platforms such as J2EE or .NET with an integrated OODBMS than it is to LINC.

    See: http://www.jadeworld.com/jade/index.htm for an overview.
    Bok, Jul 23, 2006
    #5
  6. Lawrence D'Oliveiro

    Bok Guest

    Shane wrote:
    > Lawrence D'Oliveiro wrote:
    >
    >> I didn't realize, it was 36 years ago last month that E F Codd published
    >> his seminal paper introducing the concept of relational databases:
    >> <http://www.acm.org/classics/nov95/toc.html>.
    >>
    >> Seems so simple nowadays, it's hard to imagine how revolutionary it was
    >> back then. Though he does call them "data banks" ...

    >
    > Ive just started the Introduction to Databases paper at tech. One of the
    > tutors did his degree (and masters?) at the same place Codd did (Exeter
    > College Oxford?)
    >
    > The next generation after Relational databases is supposed to be OO
    > databases (of which Jade at one point was making a ton of money from) but
    > they seem to have fizzed


    OODBM's are not exactly a next generation of DBMS. The majority of
    OODBMs were developed to provide persistence for objects in a given OO
    programming language.

    Various data models with richer semantics than the Relational Data Model
    (sometimes called Semantic Data models) have been proposed but none have
    achieved widespread acceptance.

    Neither JADE Software corporation or JADE the product has fizzed by an
    means. Check out http://www.jadeworld.com/ for current activity.
    Bok, Jul 23, 2006
    #6
  7. In message <44c35388$>, Bok wrote:

    > OODBM's are not exactly a next generation of DBMS. The majority of
    > OODBMs were developed to provide persistence for objects in a given OO
    > programming language.


    Which itself is a bad idea. The whole weakness with OO--bundling code and
    data members into the same object--now gets carried across to persistent
    storage. So if you ever need to refactor your object structure, suddenly
    you can't read previously-persisted data, without adding a layer of
    backward-compatibility hacks.

    Better to keep external data representation completely separate from
    internal code structure. That way you can refactor the latter without
    impacting the former.

    > Various data models with richer semantics than the Relational Data Model
    > (sometimes called Semantic Data models) have been proposed but none have
    > achieved widespread acceptance.


    The trouble with all of them, I guess, is that they gave up major parts of
    the simplicity of the relational data model, without a concomitant increase
    in functionality.
    Lawrence D'Oliveiro, Jul 23, 2006
    #7
  8. Lawrence D'Oliveiro

    Steve Guest

    On Sun, 23 Jul 2006 20:23:09 +1200, Lawrence D'Oliveiro wrote:

    > I didn't realize, it was 36 years ago last month that E F Codd published his
    > seminal paper introducing the concept of relational databases:
    > <http://www.acm.org/classics/nov95/toc.html>.
    >
    > Seems so simple nowadays, it's hard to imagine how revolutionary it was back
    > then. Though he does call them "data banks" ...


    And all the MySQL kids are saying 'who', 'what's normalization', and
    similar... ):

    Steve.
    Only 17 years behind Codd!
    Steve, Jul 24, 2006
    #8
  9. Lawrence D'Oliveiro

    Allistar Guest

    Lawrence D'Oliveiro wrote:

    > In message <44c35388$>, Bok wrote:
    >
    >> OODBM's are not exactly a next generation of DBMS. The majority of
    >> OODBMs were developed to provide persistence for objects in a given OO
    >> programming language.

    >
    > Which itself is a bad idea. The whole weakness with OO--bundling code and
    > data members into the same object--now gets carried across to persistent
    > storage. So if you ever need to refactor your object structure, suddenly
    > you can't read previously-persisted data, without adding a layer of
    > backward-compatibility hacks.
    >
    > Better to keep external data representation completely separate from
    > internal code structure. That way you can refactor the latter without
    > impacting the former.


    Having transient data structures represented in exactly the same way as
    persistent data structures is a huge benefit. That benefit greatly
    outweighs any refactoring issues that may arise with an OODBMS.

    >> Various data models with richer semantics than the Relational Data Model
    >> (sometimes called Semantic Data models) have been proposed but none have
    >> achieved widespread acceptance.

    >
    > The trouble with all of them, I guess, is that they gave up major parts of
    > the simplicity of the relational data model, without a concomitant
    > increase in functionality.


    While the internal storage of objects is more complicated than it is with
    records in a relational engine, the developing of code to interact with the
    object model is much simpler than with records and tables.

    With Jade (for example) there is no need for a middle layer to handle
    database connectivity - the database engine, language and IDE are all one.
    When you write code, you are already "in" the database. No need for a
    separate DB engine.

    Allistar.
    Allistar, Jul 24, 2006
    #9
  10. Lawrence D'Oliveiro

    Steve Guest

    On Mon, 24 Jul 2006 14:04:41 +1200, Allistar wrote:

    > Lawrence D'Oliveiro wrote:
    >
    >> In message <44c35388$>, Bok wrote:
    >>
    >>> OODBM's are not exactly a next generation of DBMS. The majority of
    >>> OODBMs were developed to provide persistence for objects in a given OO
    >>> programming language.

    >>
    >> Which itself is a bad idea. The whole weakness with OO--bundling code and
    >> data members into the same object--now gets carried across to persistent
    >> storage. So if you ever need to refactor your object structure, suddenly
    >> you can't read previously-persisted data, without adding a layer of
    >> backward-compatibility hacks.
    >>
    >> Better to keep external data representation completely separate from
    >> internal code structure. That way you can refactor the latter without
    >> impacting the former.

    >
    > Having transient data structures represented in exactly the same way as
    > persistent data structures is a huge benefit. That benefit greatly
    > outweighs any refactoring issues that may arise with an OODBMS.
    >
    >>> Various data models with richer semantics than the Relational Data Model
    >>> (sometimes called Semantic Data models) have been proposed but none have
    >>> achieved widespread acceptance.

    >>
    >> The trouble with all of them, I guess, is that they gave up major parts of
    >> the simplicity of the relational data model, without a concomitant
    >> increase in functionality.

    >
    > While the internal storage of objects is more complicated than it is with
    > records in a relational engine, the developing of code to interact with the
    > object model is much simpler than with records and tables.
    >
    > With Jade (for example) there is no need for a middle layer to handle
    > database connectivity - the database engine, language and IDE are all one.
    > When you write code, you are already "in" the database. No need for a
    > separate DB engine.
    >
    > Allistar.


    If it was so much better, why have most of the workforce been laid off?
    Mind you, I'm not complaining... we've got a nice stadium out of it!

    When you write code, you need a completely different skillset from those
    needed to efficiently extract data. OO won't change that, ever. So where's
    the advantage of samless integration? I'd rather have a nice clean
    boundary, thankyou.

    Steve
    Steve, Jul 24, 2006
    #10
  11. In message <>, Steve wrote:

    > On Sun, 23 Jul 2006 20:23:09 +1200, Lawrence D'Oliveiro wrote:
    >
    >> I didn't realize, it was 36 years ago last month that E F Codd published
    >> his seminal paper introducing the concept of relational databases:
    >> <http://www.acm.org/classics/nov95/toc.html>.
    >>
    >> Seems so simple nowadays, it's hard to imagine how revolutionary it was
    >> back then. Though he does call them "data banks" ...

    >
    > And all the MySQL kids are saying 'who', 'what's normalization', and
    > similar... ):


    I guess I'm a "MySQL kid"--never did the database course at University,
    though I did borrow a friend's textbook and photocopied the chapter on
    normalization. So I know what normalization is, why repeating fields are a
    bad idea, and who both Codd and Date are.
    Lawrence D'Oliveiro, Jul 24, 2006
    #11
  12. Lawrence D'Oliveiro

    Steve Guest

    On Mon, 24 Jul 2006 17:14:02 +1200, Lawrence D'Oliveiro wrote:

    > In message <>, Steve wrote:
    >
    >> On Sun, 23 Jul 2006 20:23:09 +1200, Lawrence D'Oliveiro wrote:
    >>
    >>> I didn't realize, it was 36 years ago last month that E F Codd published
    >>> his seminal paper introducing the concept of relational databases:
    >>> <http://www.acm.org/classics/nov95/toc.html>.
    >>>
    >>> Seems so simple nowadays, it's hard to imagine how revolutionary it was
    >>> back then. Though he does call them "data banks" ...

    >>
    >> And all the MySQL kids are saying 'who', 'what's normalization', and
    >> similar... ):

    >
    > I guess I'm a "MySQL kid"--never did the database course at University,
    > though I did borrow a friend's textbook and photocopied the chapter on
    > normalization. So I know what normalization is, why repeating fields are a
    > bad idea, and who both Codd and Date are.


    Don't ask me... I trained as a geologist!
    Steve, Jul 24, 2006
    #12
  13. In message <>, Steve wrote:

    > Don't ask me... I trained as a geologist!


    Nothing unusual about that. The Dean of the Computer Science department at
    the University where I worked was an archaeologist by training. At my first
    job at a software company, I was the only one with a computer science
    degree--my colleagues, from memory, had degrees in psychology, management
    studies and history.
    Lawrence D'Oliveiro, Jul 24, 2006
    #13
  14. Lawrence D'Oliveiro

    Allistar Guest

    Steve wrote:

    > On Mon, 24 Jul 2006 14:04:41 +1200, Allistar wrote:
    >
    >> Lawrence D'Oliveiro wrote:
    >>
    >>> In message <44c35388$>, Bok wrote:
    >>>
    >>>> OODBM's are not exactly a next generation of DBMS. The majority of
    >>>> OODBMs were developed to provide persistence for objects in a given OO
    >>>> programming language.
    >>>
    >>> Which itself is a bad idea. The whole weakness with OO--bundling code
    >>> and data members into the same object--now gets carried across to
    >>> persistent storage. So if you ever need to refactor your object
    >>> structure, suddenly you can't read previously-persisted data, without
    >>> adding a layer of backward-compatibility hacks.
    >>>
    >>> Better to keep external data representation completely separate from
    >>> internal code structure. That way you can refactor the latter without
    >>> impacting the former.

    >>
    >> Having transient data structures represented in exactly the same way as
    >> persistent data structures is a huge benefit. That benefit greatly
    >> outweighs any refactoring issues that may arise with an OODBMS.
    >>
    >>>> Various data models with richer semantics than the Relational Data
    >>>> Model (sometimes called Semantic Data models) have been proposed but
    >>>> none have achieved widespread acceptance.
    >>>
    >>> The trouble with all of them, I guess, is that they gave up major parts
    >>> of the simplicity of the relational data model, without a concomitant
    >>> increase in functionality.

    >>
    >> While the internal storage of objects is more complicated than it is with
    >> records in a relational engine, the developing of code to interact with
    >> the object model is much simpler than with records and tables.
    >>
    >> With Jade (for example) there is no need for a middle layer to handle
    >> database connectivity - the database engine, language and IDE are all
    >> one. When you write code, you are already "in" the database. No need for
    >> a separate DB engine.
    >>
    >> Allistar.

    >
    > If it was so much better, why have most of the workforce been laid off?
    > Mind you, I'm not complaining... we've got a nice stadium out of it!


    The stadium was always there, surely. Only the name has changed.

    OODBMS is a fairly new paradigm. There's a whole middle/upper management
    mindset to overcome. "Does it run on Oracle".

    > When you write code, you need a completely different skillset from those
    > needed to efficiently extract data. OO won't change that, ever.


    To say that shows you've never used a platform like Jade.

    > So where's
    > the advantage of samless integration? I'd rather have a nice clean
    > boundary, thankyou.


    The seemless integration is in the fact that you don't need to worry about
    the database layer. Creating an object is the same whether it's transient
    or persistent - there's no need to convert internal structures to external
    representations and vice-versa.

    > Steve


    Allistar.
    Allistar, Jul 24, 2006
    #14
  15. In message <>, Allistar wrote:

    > OODBMS is a fairly new paradigm.


    No it's not. It's been around about a decade and a half.

    > There's a whole middle/upper management mindset to overcome. "Does it run
    > on Oracle".


    And yet other database products (e.g. open-source ones) have managed to make
    lots of headway against that--and with much smaller PR budgets, too. Could
    it just be that object-oriented databases just aren't that wonderful?

    > The seemless integration is in the fact that you don't need to worry about
    > the database layer. Creating an object is the same whether it's transient
    > or persistent - there's no need to convert internal structures to external
    > representations and vice-versa.


    There is if you've refactored your object hierarchy and need to convert
    between old persistent data and the new in-memory format.
    Lawrence D'Oliveiro, Jul 24, 2006
    #15
  16. Lawrence D'Oliveiro

    Allistar Guest

    Lawrence D'Oliveiro wrote:

    > In message <>, Allistar wrote:
    >
    >> OODBMS is a fairly new paradigm.

    >
    > No it's not. It's been around about a decade and a half.


    And relational databases have been around 36 years, so in the grand scheme
    of things OODBMS's are new to the block. part of the problem with uptake of
    this new technology is that the old technology "does the job", even though
    there are benefits with the new.

    >> There's a whole middle/upper management mindset to overcome. "Does it run
    >> on Oracle".

    >
    > And yet other database products (e.g. open-source ones) have managed to
    > make lots of headway against that--and with much smaller PR budgets, too.
    > Could it just be that object-oriented databases just aren't that
    > wonderful?


    It's partly because the industry in general is just so used to relational
    databases. It's what is taught in most tertiary institutions and so is what
    most people are comfortable and familiar with.

    >> The seemless integration is in the fact that you don't need to worry
    >> about the database layer. Creating an object is the same whether it's
    >> transient or persistent - there's no need to convert internal structures
    >> to external representations and vice-versa.

    >
    > There is if you've refactored your object hierarchy and need to convert
    > between old persistent data and the new in-memory format.


    Indeed - surely the same problem exists in the relational world. If tables
    are split or consolidated then conversion will still need to be done -
    although in this case it would admittedly be easier.

    Allistar.

    Allistar.
    Allistar, Jul 24, 2006
    #16
  17. In message <>, Allistar wrote:

    > Lawrence D'Oliveiro wrote:
    >
    >> In message <>, Allistar wrote:
    >>
    >>> OODBMS is a fairly new paradigm.

    >>
    >> No it's not. It's been around about a decade and a half.

    >
    > And relational databases have been around 36 years...


    And yet it took them less than a decade and a half--in fact, less than a
    decade--to demonstrate their superiority over other database models. By
    they time they were a decade and a half old, they had already become the
    dominant paradigm.

    >>> There's a whole middle/upper management mindset to overcome. "Does it
    >>> run on Oracle".

    >>
    >> And yet other database products (e.g. open-source ones) have managed to
    >> make lots of headway against that--and with much smaller PR budgets, too.
    >> Could it just be that object-oriented databases just aren't that
    >> wonderful?

    >
    > It's partly because the industry in general is just so used to relational
    > databases. It's what is taught in most tertiary institutions and so is
    > what most people are comfortable and familiar with.


    It wasn't always that way (see above). They earned their way into dominance.

    >>> The seemless integration is in the fact that you don't need to worry
    >>> about the database layer. Creating an object is the same whether it's
    >>> transient or persistent - there's no need to convert internal structures
    >>> to external representations and vice-versa.

    >>
    >> There is if you've refactored your object hierarchy and need to convert
    >> between old persistent data and the new in-memory format.

    >
    > Indeed - surely the same problem exists in the relational world. If tables
    > are split or consolidated then conversion will still need to be done -
    > although in this case it would admittedly be easier.


    Precisely. That's just one of the benefits of a solid theoretical
    foundation--fewer surprises when you try to do new things, because the
    theory has already taken account of them.
    Lawrence D'Oliveiro, Jul 24, 2006
    #17
  18. Lawrence D'Oliveiro

    Ron McNulty Guest

    Yup, that certainly was a seminal paper.

    Seems like OO databases are always "just around the corner". I turned down a
    contract 8 years ago that was going to use an OO database (distributed too).
    The project failed.

    A major stumbling block is a lack of standards (is Jade the only commercial
    one out there?), which has lead to a paucity of reporting tools. We all know
    that SQL is a relational database standard, but where is the equivalent OO
    standard?

    A database is a major interface point in an enterprise. Lots of disparate
    tools access it. It is not going to shift to a new paradigm until there is
    an overwhelming reason to do so. At the moment, tools like Hibernate give
    you most of the OO advantages, without locking you into one provider.

    Regards

    Ron

    "Lawrence D'Oliveiro" <_zealand> wrote in message
    news:e9vbk7$nqf$...
    >I didn't realize, it was 36 years ago last month that E F Codd published
    >his
    > seminal paper introducing the concept of relational databases:
    > <http://www.acm.org/classics/nov95/toc.html>.
    >
    > Seems so simple nowadays, it's hard to imagine how revolutionary it was
    > back
    > then. Though he does call them "data banks" ...
    Ron McNulty, Jul 24, 2006
    #18
  19. Lawrence D'Oliveiro

    Bok Guest

    Lawrence D'Oliveiro wrote:
    > In message <44c35388$>, Bok wrote:
    >
    >> OODBM's are not exactly a next generation of DBMS. The majority of
    >> OODBMs were developed to provide persistence for objects in a given OO
    >> programming language.

    >
    > Which itself is a bad idea. The whole weakness with OO--bundling code and
    > data members into the same object--now gets carried across to persistent
    > storage.

    It depends on how its implemented. Most OODBMS I am aware of, including
    JADE, do not bundle code and data into the same object. Only those
    providing persistence for prototyping OOPLs are likely to do that. Code,
    whether its an instance or class method is normally stored separately
    from objects. Some OODBMs, can store methods in the database or they can
    be implemented in external libraries (.dll or .so). Funnily enough many
    Relational DBMSs do pretty much the same thing with stored procedures.

    > So if you ever need to refactor your object structure, suddenly
    > you can't read previously-persisted data, without adding a layer of
    > backward-compatibility hacks.


    That is not true of properly designed OO persistence engine. The issue
    you are referring to is referred to as 'schema evolution' and the major
    OODBMs to provide means to handle changes in structure and behaviour.
    Some OODBMS support class versioning allowing access to instance of
    multiple versions of a class concurrently with the option to lazy
    upgrade instance to the new version.

    In the current release of JADE (6.1) you can instantiate an evolved
    schema in a production system online. The application can run against
    the current schema definition (code and data) with no restrictions,
    while objects are converted to the latest schema definition.

    > Better to keep external data representation completely separate from
    > internal code structure. That way you can refactor the latter without
    > impacting the former.


    In 3-tier application architectures where the data tier is based on
    Relational technology the data tier business rules are implemented using
    stored procedures.
    Although you can use views to provide some degree of data independence,
    a change to the model generally entails changes to the stored procs.
    This is not a lot different to changing methods associated with model
    objects in an OODBMs. The advantage with many OODBMs, in particular JADE
    is that developers can use a single language to develop application and
    'data tier' layers. JADE supports reconfiguring methods to run on any
    tier simply by changing an option and recompiling.
    Bok, Jul 24, 2006
    #19
  20. Lawrence D'Oliveiro

    Bok Guest

    Ron McNulty wrote:
    > Yup, that certainly was a seminal paper.
    >
    > Seems like OO databases are always "just around the corner". I turned down a
    > contract 8 years ago that was going to use an OO database (distributed too).
    > The project failed.
    >
    > A major stumbling block is a lack of standards (is Jade the only commercial
    > one out there?), which has lead to a paucity of reporting tools. We all know
    > that SQL is a relational database standard, but where is the equivalent OO
    > standard?


    You are correct Ron, that is one of the main weaknesses with OODBMs.
    There are proposed standards for Object Query languages (e.g. OQL) but
    no widespread adoption. With JADE 6.1 you can have the best of both
    worlds, an OODBms for application persistence and an RDBMS for querying
    and reporting. The JADE RPS (Relational Population Service) provides a
    mechanism to populate an external Relational Database for Business
    Intelligence (BI) applications in near real time.
    Bok, Jul 24, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?c3FsbGVhcm5lcg==?=

    Joining one to many relational table

    =?Utf-8?B?c3FsbGVhcm5lcg==?=, Jun 4, 2005, in forum: MCSD
    Replies:
    2
    Views:
    444
    =?Utf-8?B?c3FsbGVhcm5lcg==?=
    Jun 4, 2005
  2. =?Utf-8?B?c3FsbGVhcm5lcg==?=

    Joining one to many relational table

    =?Utf-8?B?c3FsbGVhcm5lcg==?=, Jun 4, 2005, in forum: MCSE
    Replies:
    9
    Views:
    488
    FrisbeeĀ®
    Jun 7, 2005
  3. sqllearner
    Replies:
    2
    Views:
    393
    Changgyu Oh
    Jun 9, 2005
  4. sqllearner
    Replies:
    0
    Views:
    247
    sqllearner
    Jun 4, 2005
  5. Lawrence D'Oliveiro

    Relational vs MapReduce

    Lawrence D'Oliveiro, Apr 14, 2009, in forum: NZ Computing
    Replies:
    0
    Views:
    340
    Lawrence D'Oliveiro
    Apr 14, 2009
Loading...

Share This Page