-
is that like letting users interact with a deeper layer of an app (i.e. its database) than before? That's be well cool
-
Annotated link http://www.diigo.com/bookmark/http%3A%2F%2Fknowledge.wharton.upenn.edu%2Farticle.cfm%3Farticleid%3D2487
- Author: Adriana
- Published: Jun 9th, 2010
- Category: Reading & Bookmarks
- Comments: 2
Colin Hayhurst
on Jun 11th, 2010
@ 9:26 am:
What makes FluidDB interesting is that it is a solution to an important problem the founder set out to solve: That is to create a database which does not suffer from the fragmentation of data that results from APIs and applications using APIs.
They are trumpeting a very simple query language, much simpler than SQL. However what they do not point out is that FluidDB will not be able to handle the normal complexities of traditional database applications. Well not in the opinion of a database guru I know and respect.
As he has pointed out architecturally it’s an EAV (entity, attribute, value) database: see http://en.wikipedia.org/wiki/Entity-attribute-value_model. It has no schema capabilities (ie. you can’t predefine the structure of a complex thing such as ‘customer’ or ‘order’.
For example, you could use it to record:
The sky, is coloured, Blue
The sky, is coloured, Black
but you couldn’t use it to record:
(The sky, is coloured, Blue), during, Daytime
(The sky, is coloured, Black), during, Nighttime
John, says, (The sky, is coloured, Black)
Having said all that about it’s limitations I think it is very interesting for three reasons:
1) It’s fine for simple database applications
2) It’s public
3) It’s in the cloud
Terry Jones
on Jun 11th, 2010
@ 20:09 pm:
Hi Colin
Yes, that’s all correct. I did mention in http://blogs.fluidinfo.com/fluidDB/2009/09/10/the-myriad-benefits-of-a-simple-query-language/ that a simple query language is limited in the way your database guru friend also tells you. FluidDB is not designed to replace traditional SQL databases, and there will be many times where using it would not make sense. It’s perhaps better to think about it as a universal engine for metadata: if you have some information about something and want a sensible place to store it, FluidDB gives you one – no questions asked, you don’t have to be anticipated, and you don’t have to ask permission. An added value from this is that your data is then (potentially) located alongside other information about the same thing – so unexpected things can happen, as it seems you fully appreciate.
Thanks for taking the time to read up on FluidDB and to comment! I’ll be happy to reply further if you have questions. I can also be emailed via terry fluidinfo com.
Terry Jones