Regarding the RAM thing, all the recipes will be in the database but when the engine loads, it will create a graph in memory of all the recipes. They'll actually be linked by similarity, recipe A will have an array of pointers to other recipes that someone who likes recipe A might also like. Though this design may be rethought if it doesn't work out. The data in RAM is read-only and will be "updated" with fresh DB data once every day or so. The reason I need to keep the data in RAM is I need to be able to very quickly walk this graph and a relational DB doesn't really fit for this. I've done some testing and if I store about 100,000 recipes in memory, it's only a few hundred megs of RAM. This is nothing for a web server, and even if I need more, this facility could be moved over to a dedicated server that the main website just queues up requests on. Regarding Mono, I'm not sure it's a wreck. It's come a long way and several sites use it in production. However, I'm keeping my code runnable on both .NET/Windows and Mono/Apache because I haven't yet reached any definitive conclusions on what it will be run on. My code is 100% managed, there are no "native DLLs" as you mention. I've actually ported my site over to Mono as a proof of concept and it took one evening, not 6 mon. I don't really think your rant on MS/.NET is really warranted here. To each is own, if you're a Java guy then that's fantastic. I'm not much into it and prefer C#, especially since I have 10 years of experience with it and zero with Java. I'm well aware of the requirements of .NET, Mono, Apache, etc. Thanks for your feedback. Mike On Thu, Jun 17, 2010 at 5:57 AM, Martin Gainty <mgainty@xxxxxxxxxxx> wrote: > keeping anything in RAM means your data will be lost forever when the > session is lost..(then again if the data is garbage to begin with then > throwing away garbage is no problem) > if your data is NOT garbage then you're going to want to persist the data > ..look at oracle/mysql and yes even SQL-server if you have to use ODBC > instead of JDBC > > Mono is a wreck..i've written to the mormon i****s at novell multiple times > to try to get a build that works and yet to hear > any <semi>competent/coherent response from any of them > be prepared to dedicate yourself to a minimum of 6 months of effort.. just > to get mono working > > C# only works on MS .NOTYET frameworks..Microsofts proprietary container > called the GAC accepts MSIL assemblies created by a .NOTYET language such as > C#/VB.Yet > but wait a minute you're only half way there..to make the assembly run on > anything other than .NET framework you'll need to compile into a standalone > native dll..another step in the process > > apache is opensource and C# is not.. so if your objective is to > shoehorn your .NOTYET native dlls into apache you will need to craft a > mod_DOTNOTYET module..this in itself is not trivial as you'll have to cast > away any MS/DOTNOTYET specific datatypes/methods/namespaces/MS_garbage and > put everything into > primitive datatype string format..implementing simple methods > without using complex collections/ or complex-structures and namespaces AND > XSDs that apache can resolve > > finally deploying to linux,solaris,aix,hpux or bsd which I believe is your > final goal will be out of reach until you have successfully: > 1)untangled the hopelessly entangled and non-operational mono environment > into a working building environment to provide an operational .NET framework > on the nix box > 2)shoehorn your native dlls to into a mod_DOTNETYET module configuration > to be accpeted by Apache..BTW this is not trivial..if apache sees any > .NOTYET specific structs > it will gpf the server > > FUNDING: perhaps writing recipes to feed the contractors working for BP will > make available millions of dollars you will need to fund this effort? > > FYI: accomplishing this in either an native Apache or J2EE environment could > be accomplished in 1/4 time and budget that your proposed architecture will > use > > *your call* > Martin > ______________________________________________ > Verzicht und Vertraulichkeitanmerkung > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte > Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht > dient lediglich dem Austausch von Informationen und entfaltet keine > rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von > E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > > >> Date: Thu, 17 Jun 2010 04:49:14 -0700 >> Subject: [Blatant Alias Abuse] Anyone want to help out with a >> coding problem? >> From: mike@xxxxxxxxxxxxx >> To: pgsql-general@xxxxxxxxxxxxxx >> >> Hi all – I apologize for the misuse of this alias, but I figured I >> have the audience that might be interested in helping me out with a >> rather difficult coding problem. In fact, if I can find someone who’s >> looking for some part-time work and is interested in a bit of extra >> cash, then it’ll be worth it. >> >> First off, a friend and I are starting a little dot-com here in >> Seattle that focuses on recipes and meal planning. We’re building on >> a typical LAMP stack (Linux, Apache, Mono, Postgres – why what did you >> think I meant?) so we need someone with those skills as well as pretty >> serious computer science skills (probably Masters of PhD). >> >> Here’s the problem. Imagine you have a set of one or more recipes. >> Each recipe requires one or more ingredients along with an amount of >> that ingredient. You also have a given user, who has an available set >> of ingredients and amounts in their inventory. The job is to find the >> most efficient set of n recipes you can make with the given >> ingredients, resulting in the fewest number of leftover amounts. >> Sounds like your typical NP-Complete “multiple-knapsack” problem, >> right? I’ll make it a bit more complicated now. This user also has a >> set of “ratings” associated with zero or more recipes (0 stars, user >> hates the recipe, 5 stars, they love it). One of the parameters of >> the function is to take a sliding scale (between 1 and 10) that >> indicates how much their ratings will play into the recipes the >> function chooses. A scale of zero will tell the algorithm to ignore >> their ratings and pick the most efficient set. A value of ten will >> try to use their available ingredients if possible, but worry more >> about picking recipes they’re probable to like. A default setting of >> 5 would pick some sort of even balance. >> >> Here’s the data you have to work with: >> >> - All recipes will be in RAM, no database access required. The >> recipes contain only a guid, a list of required ingredients and >> amounts, and a public average rating. >> - There might be 100,000 recipes for all you know, so a brute-force >> “try every combination” approach is out of the question. Scalability >> is key. >> - I’d prefer an algorithm that results in more accurate results the >> longer it runs, as the available system resources and system load >> could dictate how long to run the algorithm before telling it to stop. >> - The engine is given a user profile (their inventory, all their >> ratings, and how many recipes they want to cook) >> >> Here’s my requirements for a solution: >> >> - Scalable of course. Needs to be fast with lots of recipes, lots of >> ratings, and able to work with multiple users at once. RAM is cheap. >> - Algorithm functions as both a “suggestions” engine (think of the >> Netflix algorithm for movie recommendations) and a “what can I make?” >> algorithm, and can trend towards one side or the other. >> - All code needs to be written in C#. I have a basic outline and all >> data structures prepared, I just need to fill in the main function. >> - Code needs to have unit tests, proving it works. >> >> If this sounds like something you’d want to spend a weekend or two on, >> lemme know. I’m willing to pay a grand or so. I’m also willing to >> donate that grand to the PostgreSQL USA organization. Please reply to >> me privately (mike at kitchenpc dot com) so we don’t clutter up this >> list with an off-topic thread. Thanks!! >> >> Mike >> >> -- >> Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-general > > ________________________________ > The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with > Hotmail. Get busy. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
