Quote:> One of the better things about Cache is that you can choose where you do
> things and, in the unlikely event that you find anything better, you have
> export facilities for ODL and DDL.
And do what? Once you're tied to Cach, in order to move somewhere else
you would have to build some kind of bridge between the object model and
the new engine -- through CORBA or DCOM, perhaps -- and what about the
SQL? What do you do on Linux, where there is no [OS-provided,
disregarding things like OpenLink] ODBC? Don't you write directly to
some kind of OCI/CLI-type API?
My point is, while RDBMSs today are different, they're not so different
that -- bar extensive use of stored procedures, triggers, and other
proprietary extensions to SQL (Transact-SQL, PL/SQL) that I tend to stay
away from -- moving is a major problem. With Cach, it seems that there
is nowhere to go. This is not really a criticism of Cach, rather me
griping about proprietary, closed systems, I guess.
Quote:> In terms of where to put logic - it's up to you.
> You can use the RDBMS features and embed the logic in the db. You can use
> the scripting language which will allow you to put the logic at whichever
> tier you want (even better - truly distributed data and logic). If you
> really want to then you can use Micro$oft VB (or anything else - including
> Java) for the front or front + logic. You say what you want , the system is
> flexible enough to allow you to have it.
I will be using Zope <http://www.zope.org/> on Linux.
Unless Cach can mimic DB-Library or CT-Library or provides an ODBC-
compliant call-level API, I'll be condemned to writing my own Zope
driver, which does not tempt me. Tell me, is this part of Cach well
documented? I'm blatantly assuming that it has a native API for SQL
I installed the Windows evaluation version and I'm planning to test it
thoroughly. Unfortunately, the Cach ODBC driver does not work on
Win2000k RC1, which I'm running -- it crashes. I have to run the damn
thing on the NT-based Zope server and access it through Zope's ODBC
Quote:> If you want objects then Cache does is fully object oriented and, unlike the
> others, does not try to bolt this on top of relational. Object structure fit
> naturally into the underlying multi-dimensional structure.
This is all well and good.
How do you work with Cach special data types? Say you have a table (or
whatever term Cach uses for collections of objects) and each object has
an array-type member. How do you access this stuff? Let's say I want to
find all companies which are located in the cities Paris and New York.
In a relational, normalized database it might be something like
select distinct name
where city in ('Paris', 'New York')
What would be the analogous Cach query?
> As to Cost you would be best talking to Intersystems. Like most companies
> the cost depends on a number of things and may not be related to published
> price lists. One thing to take into account when looking at costs is that
> the hardware requirements to run an app or dB under Cache are of an order of
> magnitude smaller than any of the so called mainstream databases.
> As an example we used to happily run an intensive 96 user system on an old
> VAX. When things got swapped around we placed an Oracle app on the same
> machine - it crawled at 10 users. (We have learnt since then and removed all
> traces of Oracle from our systems..
> My best advice is to talk to Intersystems, they are very good at working in
> partnership with customers (and potential customers) to see where the best
> fits are.
I'll shoot off an email to InterSystems, meanwhile can't you give me
even a hint? Is the pricing on par with other RDBMSs, would you say?
Quote:> Let me know how you get on.
> Usual disclaimers re personal views not those of my employers etc.
Alexander Staubo http://www.mop.no/~alex/
"`This must be Thursday,' said Arthur to himself, sinking low over
his beer, `I never could get the hang of Thursdays.'"
--Douglas Adams, _The Hitchhiker's Guide to the Galaxy_