April 18, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

A Quick Look at InterSystems' Cache Database, Page 2

  • March 10, 2003
  • By Gary Walker and Lloyd Work
  • Send Email »
  • More Articles »

Installation

Besides being powerful and flexible, Caché also comes with a very small footprint and runtime requirements, making it perfect for embedded applications. In fact, about 80% of Caché users are using it in vertical market applications that came with Caché technology embedded in their products. In fact, Caché happens to be the #1 embedded database technology used in the health care industry. Overall, Caché users number over four million in 88 countries world-wide.

I found Caché's installation to be straightforward and hassle-free. Because of its Caché Server Page (CSP) extensions, it prompted me to stop my Internet Information Server (IIS) from running so it could install support for CSP, but as soon as it was done, IIS was up and going again.

Intersystems claims that the majority of their users do not have a database administrator, and frankly I believe it. Although Caché does not to my knowledge have the ability to be tuned and tweaked like Oracle, I suspect most sites can save enough money to buy a little more hardware from the money they save on a system administrator. Finally, if your application is engineered using a object model (as opposed to a pure relational model), you are likely to run faster in Caché than under the equivalent Oracle relational model due to the implementation efficiencies of having the data model match actual usage.

The Environment

Though not perfect, Caché provides the basic tools you need to get going. It provides a terminal interface (command line oriented), a control panel and configuration manager (to avoid having to edit control files by hand), Explorer (which is a form of object browser), SQL Manager (for a traditional relational database interface), Studio (which is the Integrated development environment), Documentation (local searchable Web engine), and at least one Windows and taskbar applet to give you quick access to all of these pieces.

Nothing was as slick as the best commercial offerings for such utilities, but they were not slouches either, with clean interfaces, wizards, and so on. Studio is all new, but it has some rough edges (I found the wizard for adding database properties one at a time was cumbersome). It's a long way from having the code create tables and alter table statements by hand, though.

The Scripting Languages

There is no shortage of ways to manipulate your Caché database. Native bindings for Java and C++ will appeal to some, but if you program in VB or Delphi, you are not left in the cold because you can use ActiveX to use the object features in a basically native manner. Failing that, you have two choices of scripting languages, Caché ObjectScript and Caché Basic. ObjectScript was the original scripting language, but Basic has been extended the same benefits. You can write scripts (stored procedures) in either language and compile them to the internal p-code form, which then runs at full speed within the database server (in the database virtual machine). Java and C# programmers will find this computation model quite familiar. With either scripting language, you can invoke methods, set properties, and so forth in a very natural manner (if you are an object-oriented or VB script programmer, at least). And, ObjectScript can call Basic and vice-versa (sounds like .NET to me). Studio includes the debugger for these scripting languages.

For example, here is a very simple method in Basic straight from their online documentation.

Method MyMethod() As %Integer [language = basic]
{
    For i = 1 to 10
        person = new Sample.Person()
        person.Name = "John " & i
        person.%Save()
    Next
}

Notice that the method is declared as %Integer; the % indicates that it comes from one of the built-in classes (system). Notice also that %Integer is a class type itself, just as in other pure OOPL's. I should also point out that the above method is a standalone method, not belonging to any class (not allowed by Java and some other OOPLs). So, the scripting language is not a completely pure OOPL (though I'm never sure if this is good or bad). The VBScript programmer will find the BASIC language very natural.

What Do You Mean by Post-Relational Database?

The skinny on creating a object class is actually pretty simple. Create a project (MyApp) and a class (Person) that persists in the database.

Class MyApp.Person extends %Persistent [ClassType = persistent]
{
    Property Name As %String(MAXLEN=50);
    Property Home as Address;
}

But what is Address? Well, it is simply another class.

Class MyApp.Address extends %SerialObject [ClassType = serial]
{
    Property City As %String;
    Property State As %String(MAXLEN=2);
}

%Persistent basically means that you store this in the database (a row)

%SerialObject means that you a defining an embeddable object that is stored with the Person row, so the database does not have to go searching for the Address when it has the row. This is very much like hierarchical and network data models, except that you can still use relational SQL to get to the same data. Thus, the relational model is not broken; you can still run ad-hoc reports and so forth, using standard tools. But, your mainline applications do not pay for this extra processing complication to join one table every time the relational information that forms the object is brought together. Relational databases in fact do not keep the relationship; the relationship is artificially constructed on demand, based on key comparisons each time it is needed. OODB actually keeps the relationship. Caché gives it to you whichever way you prefer.

Unexpected Surprises — (The good kind)

A few things just struck me as, "That's cool."

1) SQL extensions—In a syntax familiar to any C programmer, I can write

Select ID,Name,Contact->Name,Contact->Phone from Vendor
  where Vendor->Region->Name = 'Midwest''
  

Now, I could also write the equivalent join syntax, but the code above just seems more natural and readable to me.

2) Inherited table definitions

Define a contact with properties such as Name and Phone. Then, define Employee as extends contact, and add properties for Hire Date and SSN. Add a couple of contacts, and a couple of employees, and then you have:

select Name from contact

Nicholson, Jack
Eastwood, Clint
Walker, Gary
Work, Lloyd

select Name from employee

Walker, Gary
Work, Lloyd

Cache is smart enough to recognize all four records are contacts, but that we don't employee the famous actors.

3) Multiple Inheritance. People frequently bad-mouth multiple inheritance as unnecessary, confusing, and so forth (and I'll agree if you talk about MI in C++). But, using MI for mix-in classes and the like is quite useful, especially when someone else has done the hard work creating the mix-in classes. So, I cracked a smile when I saw MI mix-in classes for XML.

4) The SOAP interface is very slick and easy to use—almost scary.





Page 2 of 3



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel