Domain: hyperion.com
Stories and comments across the archive that link to hyperion.com.
Comments · 9
-
One issue
One of the biggest barriers to Vista adoption is that people don't know what it's incompatible with and trying every feature of every app is terribly time consuming. I know the list I quoted is out of date. If Microsoft would just publish the real information, or at least retask some of these astroturfers to create a current list on this wiki - which btw is what you find when you google vista incompatible - uptake would probably be a lot better.
I can't believe I just did that. Ew.
So you have any info on how soon Hyperion will be supported? For once I really want to know.
-
Re:Plug-in is inline with Google's existing vision
Yes, but Hyperion did it first. Hyperion's program (and probably Google's, also, but I can't be sure) is not limited to hybrids. It's just that only hybrids can meet the requirements of the program: 45mpg and CA emissions. Now that ultra-low sulfur diesel fuel is starting, I would expect some diesels to become eligible. And Hyperion's CEO drives a Prius. (Yes, I am a Hyperion employee, thanks for asking.)
-
Hyperion Solutions did this ages ago
it's called "Drive Clean to Drive Change"
-
Hyperion has a green car incentive program
The company I work for has an incentive program for employees to buy green cars: http://www.hyperion.com/driveclean/
-
A bit much?
-
Re:Object-relation databasesObject-relation databases
There is no such animal. There is such a thing as object/relational technology. Some common examples of this are hibernate and EJB. These are not alternatives to relational databases. Rather, they serve to persist objects to and from relational databases. They are built on top of relational databases. They do not replace relational databases.
Alternatives to relational databases are LDAP databases such as openLDAP, OLAP databases such as Hyperion, and XML databases like exist. None of these technologies will replace the relational database. It's more about using the right tool for the job. Relational databases work best with operational data. OLAP works best for planning and forecasting. Think of LDAP as a distributed hierarchical database.
Various relational database products have proprietary extensions that may confuse you into thinking that they are alternatives to relational databases. For example, there are extensions to SQL Server that make them seem to act more like OLAP or XML databases.
-
expert here
I'm going to preface this by saying I'm an expert in this field, so my comments may be biased.
OLAP concepts have been around for quite some time, although as a mainstream product only since the early '90s. Today the two major players in the market are Microsoft and Hyperion Solutions, with Cognos a distant third. (To be fair, there are plenty of other players, these are just the three largest). I personally have worked extensively with both Essbase and Analysis Services, and can honestly say that both have very strong points, but generally speaking I have found Hyperion's Essbase to be superior as a whole to Microsoft's Analysis Services.
The original thread commented on how little mainstream press OLAP has received, which I wholeheartedly agree with. However, it is worth noting that many, if not most, large businesses have OLAP implementations (I can't find a source, but if I remember correctly, 499 of the Fortune 500 companies have an implementation.). Considering the market is about $3.5 billion, the products are definately being used extensively. Granted that is a drop in the bucket of the total relational marketplace, but it is hardly insignificant.
Personally, I strongly believe the lack of knowledge outside of the Finance departments of the world about the concepts is directly tied to the lack of exposure the concepts receive at the collegiate level, which continues to focus on relational databases as the primary storage of enterprise data (I am not implying that OLAP database can replace relational databases, they are truely a complimentary product tailored for specific use). The lack of a standardized API & querying languages is definately a problem for the industry, one which the large players have tried to address, with limited success. On the flip side, the industry has pushed (rightly or wrongly) toward selling the total package, with both the backend database and a suite of front end data entry & reporting tools all in one. This makes for an easy sell to many customers, but doesn't encourage much innovation from the outside (IMHO, the front ends to OLAP products are the weakest link, and really do need the most development).
Ironically, one of the best online resources I've found is IBM's web site. They repackage Hyperion's Essbase as DB2/OLAP, so their Redbooks on the concepts are slanted toward Essbase, but they have the most extensive source of free information on the concepts I've seen from a commercial vendor. -
Re:What's the scope?if you don't mind crappy performance and like doing everything by hand, then holos might be a bargain. i don't mean to flame, but if you knew how many customers buy holos based on its elevated rhetoric and replaced it as soon as they could afford to...
my sources say that seagate doesn't even do its own olap on holos. and the holos front end tools allow you to use essbase as a back end through the essbase api. explain that.
on the other hand, if you'd rather program a 4gl than use an api, i can sympathize with a choice of holos.
by the way, if you want java beans, try painted word. if you want java component based web, try alphablox.
-
Re:It stands for...there are two kinds of voodoo. chicken dancing voodoo and patent office voodoo. if everybody could do this, there would be 10 olap servers on the market. as it stands, there are about 4 worth mentioning.
olap engines also figure out things like, practically speaking, how would i tune the profitability of international container shipping using activity based costing methods?