Database program. Provue Panorama offer

User avatar
Jaysen
Posts: 6308
Joined: Mon Dec 17, 2007 4:00 am
Platform: Mac + Windows
Location: East-Be-Jesus-Nowhere SC, USA

Thu Dec 11, 2008 9:25 pm Post

RDBMS (relational data base management systems) doesn't have a real UI. They are processes that provide abstracted interfaces. Think Oracle, MySql, MS SQL Server, Posgress. The systems you are discussing are more UI than relational data base. The ones that have real relational capabilities are going to cost you. To me a $500 tag on a RDBMS is peanuts. I expect are real commercial RDBMS to have a couple of digits to the left of the comma.

That said, many of the systems available today simulate RDBMS in the UI. This is done with clever programming and utilizing the idle cycles of your processor (you really think you are using all 2,600,000,000 execution cycles available each second?).

So all you really have is a fancy GUI.

All that to say that every one of these systems running on a modern processor is capable of meeting all the needs of "normal" people. I say this to exclude folks like AmberV and bobueland (check out his blog. If his posts there don't get you scratching your head you must look like that guy over there -->) who are likely to really pound the snot out of a DB for computational storage (all you other db pounders I am sorry that I can't remember your name).

On the whole spread sheet front … you don't want to get me started. Let's just say that a spread sheet is a fancy GUI with some exposed API and formating routines. Oh, and it is built on a very thin dbm. every computation you can do in a spread sheet is possible in any RDBMS and most "fake" RDBMS. You just have to know how to do it. Making it pretty … most folks can't even do that with a spread sheet, but it is still not part of the RDBMS or DBM raw function. It is all UI.

What is the point of my ranting? Not sure I remember. Oh yeah. [bold]As an end user all you are buying is a pretty interface with some implemented functionality.[/bold] The look and feel should be considered as important as function for end user apps. This is coming from a guy who prefers a command line to a GUI.

BYTW this is one of the things I admire† most about Keith and Kevin (the guy who develops Moneywell http://nothirst.com). Both seem to have a much better connection between the UI and functionality than most large development houses. If only I could get folks to adopt their philosophy … then my job would be easy. <sigh />

† I blame AmberV for distracting me in the original. Never should have mentioned her. I was doomed to failure the second I took her name in vain.
Last edited by Jaysen on Thu Dec 11, 2008 9:55 pm, edited 1 time in total.
Jaysen

I have a wife and 2 kids that I can only attribute to a wiggle, a giggle, and the realization that she was out of my league so I might as well be happy with her as a friend. 26 years marriage later, I can't imagine life without her. -Me 10/7/09

ImageImage

User avatar
AmberV
Posts: 24632
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Ourense, Galiza
Contact:

Thu Dec 11, 2008 9:40 pm Post

Jaysen wrote:BYTW this is one of the things I admin most about Keith and Kevin (the guy who develops Moneywell http://nothirst.com)....


Spoken like a true sysop.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

User avatar
Jaysen
Posts: 6308
Joined: Mon Dec 17, 2007 4:00 am
Platform: Mac + Windows
Location: East-Be-Jesus-Nowhere SC, USA

Thu Dec 11, 2008 9:52 pm Post

AmberV wrote:
Jaysen wrote:BYTW this is one of the things I admin most about Keith and Kevin (the guy who develops Moneywell http://nothirst.com)....


Spoken like a true sysop.

Grammar was not a requirement for this profession. That is why it works so well for me. :oops:
Jaysen

I have a wife and 2 kids that I can only attribute to a wiggle, a giggle, and the realization that she was out of my league so I might as well be happy with her as a friend. 26 years marriage later, I can't imagine life without her. -Me 10/7/09

ImageImage

User avatar
AndreasE
Posts: 737
Joined: Wed Apr 11, 2007 5:33 pm
Location: France
Contact:

Sat Dec 13, 2008 2:07 pm Post

I have now downloaded the demo (almost 200 MB :shock: ) and played around with it for several hours, read in the manuals etc., but in the moment I am rather disappointed. Panorama does a lot of amazing things, but - as far as I can see - not the one fundamental thing a RDB should be capable of: defining relations between tables. In fact, the mere word "relational" appears only 2 (two) times in the main manual of 1954 pages...

So, no replacement for MS-Access, as it seems... :cry:

User avatar
bobembry
Posts: 91
Joined: Thu Mar 29, 2007 9:17 pm
Platform: Mac + iOS
Location: Nashville, TN
Contact:

Sat Dec 13, 2008 6:40 pm Post

AndreasE wrote:I have now downloaded the demo (almost 200 MB :shock: ) and played around with it for several hours, read in the manuals etc., but in the moment I am rather disappointed. Panorama does a lot of amazing things, but - as far as I can see - not the one fundamental thing a RDB should be capable of: defining relations between tables. In fact, the mere word "relational" appears only 2 (two) times in the main manual of 1954 pages...

So, no replacement for MS-Access, as it seems... :cry:


I have a Panorama license, but I don't use it much anymore. At one time the relational topic was beaten to death on one of the Provue mailing lists. Search archive: http://www.provue.com/Support/QNA/

If I remember correctly, the developer suggested defining specific objectives then looking for Panorama methods.

http://www.provue.com/Panorama/index.html mentions that Panorama is fully relational.

Hope this is helpful

Bob
Preparing for Real Life Adventures http://rlaexp.com/memo.html. It's impossible to work on things that aren't on one's mental radar at the necessary point in time.

User avatar
AndreasE
Posts: 737
Joined: Wed Apr 11, 2007 5:33 pm
Location: France
Contact:

Sun Dec 14, 2008 9:09 pm Post

bobembry wrote:http://www.provue.com/Panorama/index.html mentions that Panorama is fully relational.


It mentions that, but it does not explain in which sense. Because in the forum, you find the explicit statement that "Panorama is no relational database that provides referential integrity".

The question is, however, if one really needs an RDB for everyday purposes. I am contemplating about this in the moment, because otherwise, Panorama is a beautiful product - you feel that the developers love their software and use it themselves (we all here know another fine piece of software that fits in this description, only that the plural is not appropriate).

What I'd like to have a database application for is to get an overview over the sales and earnings of my books over the years, for the different editions, translations etc., most preferable in beautiful charts that show me the highlights (OK, these I know) and the lowlights (about these, I can only guess). To achieve this, conventional database wisdom demands a complex structure of related tables like WORKS, PUBLISHERS, EDITIONS, LANGUAGES, ACCOUNTS and so on (a WORK is the text I write, it appears in several EDITIONS at several PUBLISHERS that may belong to different LANGUAGES, for which I get ACCOUNT statements every six months etc.) - a structure that poses difficulties as soon as, for example, two of my works appear in one edition: so, maybe conventional database wisdom is not the end to all questions.

Hmm... Maybe I should ask this the folks at Panorama... :!:

User avatar
bobembry
Posts: 91
Joined: Thu Mar 29, 2007 9:17 pm
Platform: Mac + iOS
Location: Nashville, TN
Contact:

Sun Dec 14, 2008 9:47 pm Post

AndreasE wrote:
bobembry wrote:http://www.provue.com/Panorama/index.html mentions that Panorama is fully relational.


It mentions that, but it does not explain in which sense. Because in the forum, you find the explicit statement that "Panorama is no relational database that provides referential integrity".

The question is, however, if one really needs an RDB for everyday purposes. I am contemplating about this in the moment, because otherwise, Panorama is a beautiful product - you feel that the developers love their software and use it themselves (we all here know another fine piece of software that fits in this description, only that the plural is not appropriate).

What I'd like to have a database application for is to get an overview over the sales and earnings of my books over the years, for the different editions, translations etc., most preferable in beautiful charts that show me the highlights (OK, these I know) and the lowlights (about these, I can only guess). To achieve this, conventional database wisdom demands a complex structure of related tables like WORKS, PUBLISHERS, EDITIONS, LANGUAGES, ACCOUNTS and so on (a WORK is the text I write, it appears in several EDITIONS at several PUBLISHERS that may belong to different LANGUAGES, for which I get ACCOUNT statements every six months etc.) - a structure that poses difficulties as soon as, for example, two of my works appear in one edition: so, maybe conventional database wisdom is not the end to all questions.

Hmm... Maybe I should ask this the folks at Panorama... :!:


Each Panorama document (file) is a flat database, but they can be hooked together with formulas (see Chapter 23 > Linking with another Database in the Panorama Handbook.pdf located in the Documentation Folder). Search for Text Arrays in Chapter 23. Also see Chapter 35 > Moving Data between Files. I think these two capabilities are what they are calling fully relational. You might want to If there are key fields that link your needs (above) together, Panorama will probably do it.

Bob
Preparing for Real Life Adventures http://rlaexp.com/memo.html. It's impossible to work on things that aren't on one's mental radar at the necessary point in time.

Pr
Prion
Posts: 97
Joined: Fri Aug 25, 2006 3:14 pm

Mon Dec 15, 2008 9:05 am Post

Andreas,

I, too, am contemplating Panorama for my database needs. Last week I sent a rather longish email to the company support email address explaining what I would need Panorama to do ultimately and where I thought were obstacles or at least where I had dificulties in understanding how I could make Panorama do what I wanted to achieve ultimately.
One day later I had a reply from the President and developer which turned out to be actually very helpful (try that with Apple or Microsoft). It convinced me that giving the demo a spin would be no waste of time which is what I am doing right now.

From what I have been able to gather the question whether or not Panorama can rightfully be called a relational database or not hinges on definitions of datamodels but not so much the behaviour of the database. You don't define relations but the lookup( function enables very similar results. It seems though that a graphic tree of relations like in Access or Filemaker is not possible.

Your requirements sound very much like you might be interested in the following links where people set up a similar database in Panorama.

http://db.tidbits.com/article/9717
http://db.tidbits.com/article/8018
http://db.tidbits.com/article/8058

Hope this helps
Prion

Ed
Eddie
Posts: 111
Joined: Sat Jan 20, 2007 8:51 pm

Mon Dec 15, 2008 9:21 am Post

AndreasE wrote:Hmm... Maybe I should ask this the folks at Panorama... :!:


I think that sometimes it's a good idea to ask questions directly to the developer. At the very least you'll get an idea of the level of support you'll receive if/when you need it.
Often a reply (or lack of one) becomes a significant factor in my purchasing decision.

It's good to see that Prion got a quick and helpful reply. :)

User avatar
AndreasE
Posts: 737
Joined: Wed Apr 11, 2007 5:33 pm
Location: France
Contact:

Mon Dec 15, 2008 11:14 am Post

:D :D

Thanks for the hints, Prion and bobembry! I am playing around with Panorama for several days now, and I really would like to be able to use this one. Panorama radiates something very sympathetic as an application - while, honestly, whenever I visit the homepage of FileMaker, I have this very strong voice inside, screeching and moaning "oh no! - please - not that!"... :o