Re: Simple Question?

Michael Segel (Mikey@NOSPAM.KingofMyDomain.MAPSON.Segel.com) wrote: : the question: "How will UDO help me better manage my portfolio, (A/LM), : or my Derivitives?" Every minute, for every stock, you get a row like; Stock Time Volume Ask Offer Last_Sale Now, the kinds of questions I want to ask are: "Show me the stocks who's six month momentum moving average is outside the twenty-four month range?" Now consider Average. If you use the SQL AVG(), then you get an arithmetic mean. On days where none of the stock was bought or sold, you get zero values. On days with very low volume, you get 'outliers'. On holidays, you get completely irrelevant data. The idea is that you want to use 'robust analytic' functions to handle the aggregation - a Mean() aggregate that copes with outliers. This kind of analytic can be integrated into the server. Now consider the data in the timeseries. Some days are holidays. And holidays aren't consistent. If you try to compare market indices (say, how much did they shift) then you need to note that market A (New York) was open but market B (Tokyo) was closed. Including this 'calendar' information into the TimeSeries allows you to do calculations with SQL that you would be required to do with C++ 'in the middle'. Third, consider a Bond. Bonds have issuer, principal, rate, interval and the maturity date. The value of a Bond is calculated based on the number of 'market days' or 'working days' between now and the maturity date divided by the interval. And guess what: different Bonds (Bundesbank Reserve, US Corporate paper and junk bonds each compute value according to slightly different schemes). By using the function overloading you can write a single query to return appropriately calculated values. - The central advantage of UDO is that all of this complexity can be encapsulated behind a set of interfaces that extend the SQL language. - To be efficient, you can't use the ROW per Tick model. You need to use the extensible storage management stuff to interact with this kind of data efficiently. But the more important thing is to ask what this does to the way that you write these applications. Suddenly, the trader/analyst can ask questions like "Show me any press releases containing the name of the CEO?" or "For this insurance company show me the geographic distribution of their policy holders?" etc. : The reason I ask this is that I am confused as to the *direct* bennifit : of this : technology. Read: Stonebraker, M _ORDBMS_:_The_Next_Great_Wave_ Check out the INFORMIX Tech Notes pieces. Have a think about how you might use this yourself. : On a similar note, someone talked about a *video* datablade. Yet from : the post, I don't see : how this is an advantage over other solutions. (Maybe someone could : explain that as well.) Let's talk Images. More precisely, let's talk images of faces. So we know how to create a 'feature vector' for the images. The feature vector is a minimal abstraction; hair color, length of ear, distance between eyes, width of mouth etc. This allows you to identify 'approximate' matches relatively quickly (indeed, in UDO, you can create an Index to get to these quickly). Then you want to run an algorithm over all of the 'approximations' you've found to check exhaustively. If the alternative is to extract all of them from the DBMS and run the comparison in a client program, you're going to have a long wait. Now consider what happens when I add more predicates to the query. "Matching faces in Utah". "Matching faces in Utah who have 'aggravated assault' concept in their rap sheet.". "MFIUW'AA' and born between 1970 and 1975". The advantages of having it in the DBMS are: a. Data Integrity (changes to images transactional). b. Performance (no need to move BLOB to MW, parallelize QP) c. Flexibility (integrate spatial, image and text in single DBMS). UDO can be thought of as nothing more than a RDBMS with the idea of a 'domain' (Ted Codd's domain) done right.