Source : Free On-Line Dictionary of Computing

functional database
     
         A {database} which uses a {functional
        language} as its {query language}.
     
        Databases would seem to be an inappropriate application for
        functional languages since, a {purely functional language}
        would have to return a new copy of the entire database every
        time (part of) it was updated.  To be practically {scalable},
        the update mechanism must clearly be {destructive} rather than
        functional; however it is quite feasible for the {query
        language} to be purely functional so long as the database is
        considered as an argument.
     
        One approach to the update problem would use a {monad} to
        encapsulate database access and ensure it was {single
        threaded}.  Alternative approaches have been suggested by
        Trinder, who suggests non-destructive updating with shared
        data structures, and Sutton who uses a variant of a Phil
        Wadler's {linear type} system.
     
        There are two main classes of functional database languages.
        The first is based upon {Backus}' {FP} language, of which
        {FQL} is probably the best known example.  {Adaplan} is a more
        recent language which falls into this category.
     
        More recently, people have been working on languages which are
        syntactically very similar to modern {functional programming
        language}s, but which also provide all of the features of a
        database language, e.g. bulk data structures which can be
        incrementally updated, type systems which can be incrementally
        updated, and all data persisting in a database.  Examples are
        {PFL} [Poulovassilis&Small, VLDB-91], and {Machiavelli} [Ohori
        et al, ACM SIGMOD Conference, 1998].
     
        {Query optimisation} is very important for database languages
        in general and the {referential transparency} of functional
        languages allows optimisations which would be harder to verify
        in presence of {side-effect}s.
     
        [Trinder, P., "Referentially transparent database languages",
        1989 Glasgow Workshop on Functional programming]
     
        [Breazu-Tannen et al., DBPL-91].
     
        [Poulovassilis, VLDB-94].
     
        (1995-05-09)