[Haskell-cafe] A Query Language for Haskell Terms

Alex Jacobson alex at alexjacobson.com
Wed Jun 27 14:16:12 EDT 2007


Titto,

The usual tradeoff is between efficiency and queryability.  It is really 
easy to optimize graph traversal.  It is really hard to get performance 
out of the Logic model.  The traditional sweet spot has been the 
relational model, but it breaks down at very large scale.  A lot of very 
large scale web sites implement some form of relational database 
sharding which basically means partitioning the database and doing a bit 
of graph traversal to decide on the database and then relational within 
that database and then merging the results.

-Alex-

Pasqualino 'Titto' Assini wrote:
> On Wednesday 27 June 2007 09:32:16 Alex Jacobson wrote:
>   
>> Titto,
>>
>> Have you looked at HAppS.DBMS.IxSet?  Right now it provides a generic
>> way to query indexed sets.
>>
>> If you want to take a shot at making the queries serializable, I don't
>> think it would be that difficult (but I have not tried so YMMV).
>>     
>
> Hi Alex, thanks for remininding me about that. It is a very nice back-end and 
> as you say, it should not be too hard to design a SQL-like query language  on 
> top of it. 
>
>
> I am still wondering, however, what meta-model is more appropriate to 
> represent the info hold in a Web app.
>
> Unfortunately there seem to be at least 3 different ones (without considering 
> mixed approaches like F-Logic):
>  
>
> 1) Graph
>
> This is really the native Haskell way of representing information: the model 
> is defined using classes or data types and types are connected by direct 
> uni-directional links.
>
> So for example the Sale/Item model (from the HAppS DBMS Examples) might be 
> written like:
>
> data Item = Item {stock::Int,description::String,price::Cents}  
>             deriving (Ord,Eq,Read,Show)
>
> data Sale = Sale {date::CalendarTime
> 			     ,soldItem::Item                 -- NOTE: uni-directional link to Item
>                              ,qty::Int
>                              ,salePrice::Cents} 
>             deriving (Ord,Eq,Read,Show)
>
> or in more abstract form using classes:
>
> class Item i where
>          description :: i -> String
>          price :: i -> Cents
>
> class Sale s where
>          soldItem :: Item i => s -> i
>
> This is also very much the Web-way: information is a graph of resource linked 
> via uni-directional links.
>
> Information is queried by path traversal (REST-style):
>
> Assuming that the root "/" represents the collection of all sales then:
>
> HTTP GET /elemAt[2345]/soldItem/description.json 
>
> might return the JSON representation of the description of the item sold as 
> part of sale 2345.
>
>
> 2) Relational
>
> Information is represented as tables, that can be joined up via keys, as 
> implemented  in HAppS DBMS or in any relational database.
>
> The model becomes:
>
> data Item = Item {itemId::Id  -- NOTE: primary key 
>                              ,stock::Int,description::String,price::Cents} 
>             deriving (Ord,Eq,Read,Show)
>
> data Sale = Sale {date::CalendarTime,
>                               soldItemId::Id     -- NOTE: foreign key 
>                               ,qty::Int,salePrice::Cents} 
>             deriving (Ord,Eq,Read,Show)
>
> Plus the appropriate indexes definitions.
>
> Information can be queried via a SQL-like language.
>
>
> 3) Logic
>
> This is the "Semantic Web" way: information is broken down into assertions, 
> that in their simplest form are just triples: subject predicate object, the 
> model then becomes something like:
>
> Item hasDescription String
> Item hasPrice Cents
> Sale hasItem Item
>
> It can be populated piecemeal with assertions like:
>
> item0 hasDescription "indesit cooker 34BA"
> item0 hasPrice 3.5
> Sale0 hasSoldItem item0
>
> It can be queried using a logic-oriented query language (e.g SPARQL):
> sale2345 hasItem ?item
> ?item hasDescription ?description
>
>
>
> Moving from Graph to Relational to Logic the meta-model becomes simpler and 
> more flexible. The flip-side is that the model (and the queries) become more 
> verbose.  It is not clear where is the sweet spot.
>  
>
> What people think?  
>
>
> Best,
>
>     titto    
>
>
>
>
>
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20070627/13a2f33a/attachment.htm


More information about the Haskell-Cafe mailing list