Weblogs Forum - Getting Away from "Kinds of Storage"

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Getting Away from "Kinds of Storage"

7 replies on 1 page. Most recent reply: Oct 11, 2008 6:42 PM by James Watson

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 7 replies on 1 page

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Getting Away from "Kinds of Storage" (View in Weblogs)

Posted: Oct 10, 2008 10:19 AM

Summary
I think the Smalltalk model was way ahead of its time. My vision is to move completely away from the idea of different kinds of storage.

You have something running, and it's just "there" on your machine, and sometimes you are using it but often you're not using it. The idea of the machine being "on" or "off" becomes unimportant. That things might or might not be stored on rotating media becomes unimportant. "Loading" and "storing" from other kinds of media become unimportant (think how much easier it will be to explain the computer to a novice when you don't have to mention disks).

Of course, "fixing" your machine by rebooting must first become a thing of the past.

This will probably also require a shift in how we think about databases. Relational Database Management Systems (RDBMS) came into being by shifting the perspective from the application (which kept the data locked within it) to the data (which then allowed many apps to use the data however they wanted).

I think this is what we're looking for in The Next Data Representation (hmm, sounds like the topic for an open-spaces conference). Making data into objects does seem like it's moving back into the hierarchical data model, with its application-specific restrictions. And yet the RDBMS seems to always require adaptation to fix the impedance match with objects. LINQ is brilliant, but it's really about bringing the manipulation of the database into the mainstream language (where it has always belonged, IMHO) and not about fixing the impedance mismatch between objects and RDBMSes.

We either need to expand/change the data model, or expand/change the object model.

Mike Ivanov

Posts: 23
Nickname: mikeivanov
Registered: Jul, 2007

Re: Getting Away from "Kinds of Storage"

Posted: Oct 10, 2008 12:25 PM

Hi Bruce,

You see, the problem with language specific data storages is that they are... well, language specific. I much like a hybrid approach seen in products like InterSystems' CACHÉ. It's not an exactly ODBMS nor RDBMS, but rather something in between. Even though the implementation sucks, the idea is just great. Basically, it provides what we actually need: some kind of a record manager (not quite yet) easily and naturally adaptable to different languages. The record manager's simplicity is the key: it has to be dumb enough to let the object side shine.

Mike

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

How come storage does matter?

Posted: Oct 10, 2008 3:08 PM

It's complicated (maybe also because we just had barbecue, and a lot of wine to accompany the meat?)

I met the situation that business logic was implemented split in the database (using stored procedures, queries, views and the like) and in the application code, sometimes mixed with UI code. Without exception, in such cases maintenance was a nightmare. My conclusion is that business logic should be localized. What this means: even if the database provides tenfold increased performance, unless absolutely necessary, do all business logic in code. Even when you have to keep some logic in the database, wrap it nicely in code, so the maintenance/client programmer does not suspect you are actually _not implementing_ that part of the business logic in code.

On the other hand, if we look at the object structure in an app from a services point of view, it is easy to convince ourselves that most OO apps are just a bunch of several, maybe hunreds or thhousands of instances of programs, a program being a class and an instance being an object, which run together and communicate by messages.

In such a world IMO it is obvious that each object/class should implement/use its own serialization/persistence mechanism, without asking other objects about how to do it, and without other objects/classes really caring.

If so, data structure at the low database level becomes meaningless, as it should be dumb from one end to the other. Instead, the important layer becomes the in-mem, deserialized model, but running objects should not care about the persistent/serialized representation of objects they send messages to.

Going back one more step, if messages are sent among objects using a services infrastructure which is language- and platform-agnostig, the data layer is completely out of this discussion.

So here's the question again: how come storage does matter?

Dave Quick

Posts: 22
Nickname: davequick
Registered: Sep, 2006

Re: Getting Away from "Kinds of Storage"

Posted: Oct 10, 2008 7:26 PM

Abstracting away the necessity of knowing what kind of device your data resides on would certainly be very convenient. Of course, it only works if you never have to worry about the device's availability, capacity, or how long it would take to access your data when you needed it. Do you have any thoughts on what kind of abstraction layer would be required to support this?

Which database approaches we choose seems like a separate issue, unless we decide that storage and databases are always the same thing.

Are we sure that it's the RDBMS that requires adaptation to fix the impedance mismatch? Maybe it's the programming language that requires adaptation? Instead of assuming that languages should be object oriented, what if we had a relational oriented programming language? Defining what would such a language look like and how would it differ from an OOP language might be an interesting discussion topic.

Mike Ivanov

Posts: 23
Nickname: mikeivanov
Registered: Jul, 2007

Re: Getting Away from "Kinds of Storage"

Posted: Oct 10, 2008 11:32 PM

> Do you have any thoughts on what kind
> of abstraction layer would be required
> to support this?

Dave, to some extent this could be (and it actually was!) done on the OS level. Anybody who still remembers what IBM AS/400 was should be familiar with the Single Level Store concept (http://en.wikipedia.org/wiki/Single_level_store)

On the other hand, almost the same level of transparency can be achieved with just transactions and a good persistence manager tracking attribute changes in managed objects. This approach worked quite well in ZODB and to some degree in Hibernate, although it's a totally different level of abstraction

So it does not really matter 'where', it's all about 'how'.

The main problem with the language-oriented approach is data tied to class definitions. You see, the thing is _data_ is tied to classes defined in a _programming_ language. Should you change a class definition and the data definition is changed. That's OK, but how to adapt the old data to these changes if the only way you access the data is through instances of the (already changed) class? It was a really sore point in ZODB.

Rational languages is an interesting idea, although I suspect it won't work simply because it takes decades for a language to gain momentum big enough to become a mainstream thing. Probably some kind of a language extension has a chance?

Dave Quick

Posts: 22
Nickname: davequick
Registered: Sep, 2006

Re: Getting Away from "Kinds of Storage"

Posted: Oct 11, 2008 2:45 AM

Yes, I know, but I was more interested in how you do this across geographically distributed heterogeneous systems, as that seems like the interesting problem.

I guess the next question is how often do programmers get to define or redefine persistant data required by more than one application these days and are they the right people to do such things? Or, is that the function of a DBA?

Doesn't the productivity a language offers have a large effect on the time required for a language to gain influential mind share? For recent examples; Java, C#, Ruby, and Python all became popular in a relatively short time.

Brian Panulla

Posts: 6
Nickname: bpanulla
Registered: Aug, 2005

Re: Getting Away from "Kinds of Storage"

Posted: Oct 11, 2008 1:35 PM

Maybe it's the company I keep lately, but there's been a lot of discussion about RDF and OWL (Web Ontology Language) and it's extensions forming the basis of next-generation distributed information storage. OWL can theoretically break down artificial information silos that databases by definition create, particularly with public data.

Why do we all have our own Country and State tables in all of our databases? Shouldn't there be a single (ideally replicated/federated) version for us all to use?

There are even query languages like SPARQL that mirror the metaphors we use to interact with today's databases.

Of course, how this impacts proprietary information and the needs for information assurance within an organization is left as an exercise to the reader. :)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Getting Away from "Kinds of Storage"

Posted: Oct 11, 2008 6:42 PM

> > Do you have any thoughts on what kind
> > of abstraction layer would be required
> > to support this?
>
> Dave, to some extent this could be (and it actually was!)
> done on the OS level. Anybody who still remembers what IBM
> AS/400 was should be familiar with the Single Level Store
> concept (http://en.wikipedia.org/wiki/Single_level_store)

Was? I write Java (and COBOL and CL if necessary) to run on AS400 (more precisely OS400) currently and it doesn't seem to me that single level store is ever mentioned in any literature that I have read. That would suggest to me that it was not successful.

Flat View: This topic has 7 replies on 1 page

Previous Topic

Next Topic