I am just getting started with Panorama X but I am very impressed.
Panorama is the lifelong work of a single highly skilled and passionate developer - the project began before Macs even existed and then it has been mostly a Mac project since then.
It is an extremely capable RAM based database and UI generator. It even has its own scripting language because it was written before Python or Javascript existed - but now it supports standard Scripting languages and shell scripting also.
I held back for a while though because Panorama fell behind in features in the internet age. But recently Panorama has been totally written to modern Mac standards including support for Internet-based database sharing and embedded web apps.
I believe this may now be superior to Claris and superior to many “low code” or “No code” options out there. Its pricing is very reasonable too.
As I said I am just getting started with it but I am extremely impressed so far.
I’ve been using it for a few years and I love it. It’s dead simple to get a very useful single-table database up and running, and I have a handful of those. There does seem to be a learning curve for more advanced usage, like creating relational databases. I keep intending to dive into the training and learn it, but I haven’t done it yet. I’d never need it for any device other than a Mac, so Mac-only is not a shortcoming for me.
rkaplan recommended I check out Panorama in another thread, and I did this weekend. This is pretty close to the tables I wish could exist in DT (surprised there is almost nothing on the web about integrating the two.) I love the focus this developer is bringing here.
The relational support seems laborious and perhaps an afterthought, though. Is the auxiliary database system and those manually described joins the only way to use that? Can some of the automation be used to speed up common joins and spin up small aux tables? Just wondering what’s out there.
@provuejim (aka dev Jim Rea), I’m tagging you in case you’re watching and would like to comment on @cornchip 's post above. Thanks, you have been a welcome presence in the past!
Thank you for that! I do somewhat follow the MPU forum but not super closely because there is so much traffic here and we have our own Panorama forum to keep track of.
The auxiliary database feature is often used with relational databases, but it is really a separate feature that has nothing to do with the capabilities of relational features. Unlike some other systems, Panorama keeps each table in a separate document (file). Often you’ll want to use multiple tables as a set, and the auxiliary feature makes that easy. For example, if you have an invoice database you could set up your price list and customer list as auxiliary databases. Then whenever you opened the Invoice table, the price list and customer list will also open automatically. That’s all the auxiliary feature is.
Linking data from one table to another, i.e. relational links, is a complete separate topic on it’s own. I’m obviously biased but I think this feature is the opposite of “laborious and perhaps an afterthought”. Here is the main documentation page for this feature (Panorama X has very extensive documentation).
Very commonly you’ll set up the relations between different tables in advance. Panorama provides a configuration dialog that makes this quite easy. However, you don’t have to configure the relation in advance. You can set up the relation in code “on-the-fly” if you wish. In fact when you do a join you can use a configuration set up in advance, you can use a pre-set configuration but “tweak” it, or the code can just define the relation right at the point of use.
Because Panorama is RAM based, we were able to dispense with some of the typical restrictions that are necessary for other relational systems. Because Panorama doesn’t use indexes at all (they are not needed because of the RAM speed), your key fields don’t have to be indexes. Also, the key fields don’t have to be set up the same as long as you can define a formula to specify the relationship. For example, suppose in one table you have separate fields for first and last names, and in a second table these are combined in a single Name field. For Panorama this is no problem, it can use these as matching key fields even though the fields don’t exactly match up. You can also easily set it up so that key data will match even if it is a different upper/lower case, or one database contains accented data and one doesn’t. Of course all of this is optional since you may want only exact matches.
Panorama X is designed with automation at its core. Virtually everything in Panorama can be automated, including even creating tables, modifying table structure, and even creating and modifying graphical layout. In fact, Panorama relies on this capability itself, a large portion of Panorama is written in itself (on top of the core which is implemented in AppKit). Virtually every dialog in Panorama is implemented using this capability, including the relational configuration dialog mentioned earlier. Doing it this way made it possible to complete this complex product as a solo developer, and also insures that every single aspect of Panorama can be automated. It was basically build automation first, with the UI added on top of that.
There are a lot of videos on the provue.com home page, but based on your questions I think you might especially appreciate this presentation I did for the Boston CocoaHeads meetup group about a year ago. This is an introduction to Panorama X, but geared for an audience of developers rather than typical users. This presentation is not super technical, no coding, but it covers a lot of the design and technology decisions that went into the product. (Note that the presentation itself was about 40 minutes, the rest of the video was Q&A).