On Saturday 30 October 2004 13:07, you wrote: > > > -----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) > > > You can not do it using UDF's :( I missunderstood it at first... But any OpenSource database can be a point to execute this SQL directive, but in the engine itself (as you said).
Again, I'm sorry for miss-understanding correctly, Ido -- Not everything that can be counted counts, and not everything that counts can be counted. -- Albert Einstein ================================================================= 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]
