> -----Original Message----- > From: ik [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 30, 2004 12:16 PM > To: Tzahi Fadida > Cc: [EMAIL PROTECTED] > Subject: Re: Open Source Database Programming Recommendation. > > > On Saturday 30 October 2004 03:17, Tzahi Fadida wrote: > > Hi all, > > I need to implement some new algorithms for JOIN operations > > , Ranking, etc... > > I was wondering if anyone can recommend an Open Source Relational > > Database > > that would be the easier to work with Programming wise. > > A widely used DB is preferable so the algorithms will get > more publicity. > > By easier I mean, for a one person to understand the jungle > of code that > > must be there and also it would be nice to get design plans > that would > > allow more orientation. > > Another nice advantage would be success stories and examples. > > > > I would have to touch the query processing engine and > > the optimizer component to make better query execution plans for > > the algorithms and even the size of blocks the DB uses for > the relations. > > I would also have to touch the run-time engine since the DB > still doesn't > > know some of the operators in the new algorithms and I need > to break > > away from the traditional n-way to diactic way plans. > > > > I don't care about transaction considerations at this time > since the > > algorithms are all read only from the data. > > > > > You can use Firebird-SQL. It contains an ability to add > "plugins" to the engine itself, and you can access new > functions/declarations using a query itself in one hand, but > to live the original engine in-tact. BTW that "thing" is > known as UDL. And there are many guides in the site and on > http://www.ibphoenix.com/ on how to write them ... > > http://www.firebirdsql.org/ > I am not sure it allows messing with buffers, and where exactly to load relations and what size of blocks. The algorithms includes new operators that are not based on previous ones. Already today we can implement these algorithms on the user levels on special DBs for that purpose but not on the engine level. i.e. the JOIN2 operator should live next to the JOIN operator performance wise and it should have its own/separate plans. >From first glance it seems difficult to find documentation on the plugin feature.(googling)
================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
