Also of interest might be GemStone/S, an ODBMS that is still heavily used in at least two large Investment Banks (JP Morgan and UBS), as well as several large shipping companies (OOCL, Coscon, and NYK). Marketing blurb here http://seaside.gemstone.com/docs/OOCL_SuccessStory.pdf
Basically it's an environment that replaces the limitations of SQL with the limitations of Smalltalk. It's interesting that the debate about O/R mapping is still stuck in the same place it was in 1990. After all these years I still think it would be easier to implement relational semantics on top of this sort of environment than vice-versa, but last time I checked Oracle and Microsoft weren't taking my calls. This paper is kind of old, but it describes the implementation of a DBMS inspired by the description of Smalltalk in the famous 1981 issue of Byte magazine. http://portal.acm.org/citation.cfm?id=602300 Making smalltalk a database system To overcome limitations in the modeling power of existing database systems and provide a better tool for database application programming, Servio Logic Corporation is developing a computer system to support a set-theoretic data model in an object-oriented programming environment We recount the problems with existing models and database systems We then show how features of Smalltalk, such such as operational semantics, its type hierarchy, entity identity and the merging of programming and data language, solve many of those problems Nest we consider what Smalltalk lacks as a database system secondary storage management, a declarative semantics, concurrency, past states To address these shortcomings, we needed a formal data model We introduce the GemStone data model, and show how it helps to define path expressions, a declarative semantics and object history in the OPAL language We summarize similar approaches, and give a brief overview of the GemStone system implementation Cheers, Steve On Tue, Jun 21, 2011 at 11:38 AM, Max OrHai <[email protected]> wrote: > There are certainly practical differences between "conventional" relational > databases and hierarchical filesystems, without having to get into > implementation details. I'm sure at least a few people on this list are > familiar with the BeOS filesystem, which acted much more like a relational > DBMS than most filesystems do... over a decade later, we've now got > hacked-on DBMS-like functionality in the form of (e.g.) Spotlight, but most > users are stuck with the little walled-off databases presented by their > media library and email application software. Once again, it's not a > technical issue so much as a matter of perspective. > http://www.theregister.co.uk/2002/03/29/windows_on_a_database_sliced/ > -- Max > > On Mon, Jun 20, 2011 at 11:31 PM, BGB <[email protected]> wrote: >> >> On 6/20/2011 9:19 PM, Julian Leviston wrote: >>> >>> Hi... (see below)... >>> >>> On 21/06/2011, at 3:42 AM, BGB wrote: >>> >>>> On 6/20/2011 3:22 AM, Julian Leviston wrote: >>>>> >>>>> On 20/06/2011, at 8:06 PM, BGB wrote: >>>>> >>>>>> hmm... S-Expression database?... >>>>>> sort of like a hybrid between a database and a persistent store. >>>>>> >>>>>> >>>>>> or such... >>>>> >>>>> I'd like to know if you think there's a difference between a filesystem >>>>> and a database... conceptually... >>>>> >>>>> or such... >>>> >>>> interesting thought... >>>> >>> Note that I asked if you think there's a difference not how they differ. >>> I'd be surprised if there were any people on this list who didn't know how >>> they differed. >>> >>> I don't consider there to be much of a difference between the two, >>> conceptually - they are both concerned with the retrieval and storage of >>> data (I'm using the term 'data' here to mean any form of raw information at >>> all, useful or otherwise, including programs). >>> >> >> (I got sidetracked and forgot to answer earlier...). >> >> >> but, well, I consider them as different, as they serve different roles... >> >> filesystems serve a very narrowly defined role, so possible variation is >> limited before one risks compromising compatibility with existing software >> (both WRT removing features, or adding too many fundamentally new ones). >> compromising this compatibility would also severely compromise the general >> usability of the system. >> >> >> however, one could argue that filesystems are probably a fairly narrowly >> defined subset of databases, so in this sense there is overlap. >> >> for example, humans are mammals, but not all mammals are humans (tigers >> aren't hosting TV shows, there are no cities of bears, elephants aren't >> doing construction work, ...). >> >> so, it seems a similar level of difference... >> >> >> >> _______________________________________________ >> fonc mailing list >> [email protected] >> http://vpri.org/mailman/listinfo/fonc > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
