Isidor,
On Thu, Apr 22, 2010 at 10:45:40AM +0200, Isidor Zeuner wrote:
Hello Stefan, ..
Your below code for calculating the "Maxium out degree" basically re-implements in MAL (and interpreted language) what does already exist a=
s
((hopefully higly optimized) MAL primitive that is implemented in C (and hence compiled code: a histogram.
In other words, to get the most out of MonetDB, one should not see and us=
e
MAL as an imperative programming language to iteratively process data ite=
ms
one at a time, but rather as a declarative query language to process larg=
e
amount of data in one go (you may also think of it as something like "SIMD").
..
Well, it looks like you just got me interested in diving deeper into MAL :)
If you do so, please be aware that MAL is intended and designed as a MonetDB-specific interface between the MonetDB columnar kernel (back-end) and the any front-end that provides the user- and application-level logical data model and respective query language, such as, e.g., our SQL front-end provides the (n-ary) relational data model with SQL as its query language.
However, to get more out of this than mere researching curiosity, I am viewing it in context of a long-term deployment strategy, where I have to care about standardization. So I have a couple of questions:
I get the impression that MAL is currently a unique tool in the global software landscape, so once an application is developed using MAL, migrating to another database engine would be rather expensive. Has it been considered to get MAL more standardized? Or are there other, standardized languages serving a related purpose, for which it is considered to evolve MAL in the direction of that language of a (sub|super)-set thereof?
As mentioned above, MAL is MonetDB specific. Although it might look like (are even be close to) a computational complete programming language, its main purpose is a textual representation of MonetDB's closed binary (read: two-column) relational algebra.
I would recommend to base your applications on the logical data model they use and the respective query language, e.g., relational tables and SQL. These are standadized and hence (supposed to be) portable. (Or XML & XQuery as opposed to MIL in the case of MonetDB4/XQuery.)
Using MAL directly is only to be considered if the available highler-level data models, query languages and API's do not provide sufficient functionality for your applications. Even in that case, you might want to consider choosing or designing a suitable logcal data model and query language and translate that to MAL in a generic fashion as we already do with SQL (& XML/XQuery).
A possibly easier approach to dive into MAL and still be able to build upon it in a standardized environment would be to stay with SQL for interfacing, and to use MAL for developing application-specific optimizations on the intermediate MAL code. What is the best way to get started on that? Do you have any design documents specific to the SQL-MAL compilation layer?
Indeed that is also an option to be considered. Some "design" documentation of translating n-ary relational schemas and related algebra to MonetDB's binary (two-column) tables (BAT) and their (closed) algebra are to be found in many of the scientific publications related to MonetDB, in particular these two might be a good starting point: http://repository.cwi.nl/search/fullrecord.php?publnr=11183 http://repository.cwi.nl/search/fullrecord.php?publnr=14832 More publications are listed here: http://monetdb.cwi.nl/Development/Research/Articles/index.html
More information is on the MonetDB web site.
For most details the code is the documentation outside our heads ;-)
Stefan
Many thanks.
Best regards,
Isidor
MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users