Like many of you, I have some experience with relational DBs, dcoument-based DBs, object-based DBs etc.
I’ve tried looking in the forum and in the help for documents that will help someone who is new to Panorama X get up to speed quickly. The tutorials were a good starting point but they don’t really address some questions I have. For example:
In a relational database, table joins provide the structure and enforce relational integrity. How is this performed in PanX? Is there an equivalent? What about cascading deletes?
What is the maximum size of a field?
Can PanX be accessed using ODBC/xBDC?
I feel PanX has a lot of potential and am already a subscriber, but it’s a competitive field out there and more information is needed to assess why PanX would be a suitable solution. I’m not talking about buzzwords like “64-bit in-memory” which most people wouldn’t be able to appreciate. For example the morphing ability is a clear winner, which as everyone knows, ETL is a major pain for database users. Would really appreciate if there’s a document out there that says “this feature will save you time/money if you’re used to doing X in another database”. Or even being honest like “This feature that you take for granted in X database is not available in PanX, but here’s a workaround” or something to that effect.
Actually, I suspect almost no one on this forum has experience with these other types of database systems. Panorama is not intended to be a drop-in replacement for SQL systems, the terminology and functionality are quite different, and (perhaps unfortunately), we rarely get questions from SQL users.
Panorama does not have an equivalent of an SQL join operation, and it doesn’t enforce relational integrity. To learn about the options Panorama does have for linking different databases (which in SQL would be called tables), see this help page:
There is no maximum size of a field, other than physical memory.
No, Panorama X databases cannot be accessed using ODBC/xBDC.
I’m going to quibble with you on this point. “In-memory” is the key differentiator between Panorama and virtually every other database system on any platform. By operating only in memory, Panorama eliminates the need for b-tree indexing, allowing features like searching on any formula (including even regular expressions), searching on multiple or even all fields at once, fast morphing (including splitting and joining fields), etc. I believe there are some SQL systems that allow for in-memory usage, but they don’t require it and aren’t optimized for it the way Panorama is.
For a new user like yourself, I suppose 64 bit would be assumed, but it’s an important point for users of previous versions of Panorama. Until 18 months ago, Panorama was only a 32 bit program, which meant that no matter how much memory your system had, a database couldn’t be more than 4 gigabytes (and actually, due to restrictions of Apple’s 32 bit API’s, the real limit was about 1 GB). Now that Panorama X is written using 64 bit code, the only limit is the actual amount of RAM in your computer.
I can guess what this buzzword is, but I’m afraid I’ve never heard of the acronym “ETL”. Sounds like perhaps we need to add it to our marketing repertoire!
This sounds like a good idea, but I’m afraid there is no one at our company that would be qualified to write such a document. We’re experts on using Panorama, but our knowledge of competing database systems is a lot thinner – unfortunately we are not nearly knowledgable enough to write the sort of comprehensive document you are suggesting.