When I said, registration to their forum took several days, this means a weekend, plus several workdays. Message was "Your account has been activated but you are currently in the moderation queue to be added to the forum.". I then finally got a message I could post, with the result shown above. There's also "Live Support", which is "Offline" most of the time when I look but then, it seems that they are available indeed between 5 and 7 a.m. in Europe, so this should be between around 17 and 19 o'clock Chinese time.
Some 2 years ago, a user (successfully) asked in their help forum: "Is there a difference between the functionality of the data modeler in the various For [DB] products and the Data Modeler product? If so, is there a feature matrix comparing the two?" That was the question I asked myself, too. All (s)he got for an answer was pur marketing speak, which you can also find on their web page:
"Thank you for your inquiry.
Navicat Data Modeler is designed for customer to create data models. If you want to use Navicat to design database, Navicat Data Modeler is the product that you want.
Navicat Preiumm [this type proves they repeat their advertising instead of answering a good question in earnest, but instead of just copying this crap, they type it anew: bad organization!] is a database administration tool that allows you to simultaneously connect to MySQL, MariaDB, SQL Server, Oracle, PostgreSQL, and SQLite databases from a single application. Inside Navicat Premium, there is a Data Modeling Tool. However, the function is not completely similar as Navicat Data Modeler."
My (perhaps wrong) personal answer to the question is: "Premium" is 1,000$ and does it all while the database-language-specific subsets are around 200$, but without possible translation from one database language into another, even if you own the respective subset for both languages. "Modeler" is, for around 300$, as "Premium" again but without any database contents, this means you can import any (of the allowed database formats that is) database's structure, work on it, and export the changed (or not) structure, in the same language or in another language (example: input SQLite, output MySQL, or any other pairing), but with "Modeler", this would be possible for the structure only, so if you have so-called production databases, this would not be possible and you would need again either the "Navicat for ..." specifics or the "Premium" version if you want to translate.
If I'm correct here, this would mean that the scope of their "Modeler" is quite restrained. Anyway, it's evident that the "Navicat for ..." and the "Modeler" are subsets of the "Premium" version, which means that very probably, bugs in the first or in the second are also in the third one, and vice versa.
When I said I fear that in their "Premium" (do-it-all) product (and their subsets "Navicat for ...", see my observation in their current "Navicat for SQLite"), they didn't go into all the necessary specifics of every language, I had not found this Modeler mini-review
https://www.macupdat...navicat-data-modeler yet: "ming-deng
Dec 08, 2014
I tried navicat data modeler to export SQL statements for table creation for PostgreSQL and for SQL server. The output is unusable. For PostgreSQL it creates "Create Index.." which is not supported by PostgreSQL. For SQL server it generates "Drop constraint w/o name" which is going to fail in the SQL server. Also stupid enough it tries to drop all the indices before dropping a table! When drop a table all indices got drop all together why generate tons of dropping index statements?
The tool has nice GUI [as I had observed, too, and said above] but at this point it seems useless and is full of bugs!" [I cannot say as much but think this observation for Postgres (for the paid or the trial version, since as said above, my free "Essentials" version does not do any export whatsoever, correctly or wrongly, it's just a demo) is of interest. Cannot say, of course, if that bug prevails or has been exterminated in-between.]
They specify their "90 days software maintenance plan" as "complimentary", obviously declaring this pity as a gift aims to silence up any criticism of 90 days not being a standard period for free updates.
As said, the crow's feet and other foreign-key lines are connected anywhere to the table, not to the specific field/column, but you can move them manually to a better connection point; this is not ideal especially when you insert fields/columns afterwards which shifts the position of existing fields. (You can color those lines even though I can't conceive a use case for that.)
You can create foreign keys by drag-drop the target field onto the source; for this, you must select the foreign-key instrument first, but anyway, this is very good functionality of Navicat Modeler. Since any help is online only, and without search functionality, I better praise this excellent point here; you'd risk to discover it belatedly.
When I said that on pre-selection of a table, the contour of the table changes its color, it's more correct to say it grows thicker, as indication for the pre-selection, but as said, mouse-over will not show any comments then.
Let me tell in brief why I think field comments are so important. They can contain musings about the format of the contents for this field, of course, but they also can contain To-Dos and other reminders for your construction work: do this, pay attention to that, etc., even for fields not having been created yet, in other words, you use the comment of field x for a reminder for the future field y; also for this reason it's necessary that you have visual comment indicators. You cannot create some fields before having created other fields it seems, so it is reasonable to create reminders for those other fields to be created afterwards. All this is not possible for SQLite, which is why I came up with the idea that an SQLite frontend could do this on its own.
Since I (unsuccessfully every time) tried on several occasions to post my questions / suggestions in their forum, I had even lost my text, the text above being a second version (which I could not post either) in which I only remembered some of my points, but now I have found the original text again, so here are some new/old observations left out above:
From my original text: "I would like to use the Modeler to quickly jump from any column to any column, in any table (which is on the canvas), in order to develop and refine it all iteratively; in the comments I do not only put hints, but also "ToDo's", "Attention" and other "Work to to", and for such things with regards not to some columns, but to a (whole) table, I even create a column "PROBLEM" or such, in order to get a "generic" comment for the whole table.
Those "EXTRA" columns are immediately visible, but of course, regular comments (their content and also their shere existence, to begin with!) are not, and I would greatly appreciate the possibility to see any comments by just hovering over any column ("field name") anywhere, without having to do that "real selection" of the respective table beforehand, all the more so since in most cases, I then do not do something with that table, but just get the information (recall, aid for my memory) and go to other tables, retrieving comment info there.
In particular, I do not create tables as fully as possible, then create others, but just create some core columns, then some columns in some other tables, and so on, "completing the picture" in this process in an often seemingly "chaotic" way. Thus, with the need to "activate / really-select" any table beforehand, before being able to have a glance at its comments, it's an enormous amount of "clicking around", instead of smooth, intuitive working."
So you have also the idea here that you create immediately-visible columns, like "PROBLEM" (text format of course) where you then put some generic comments, and which afterwards you delete again when those problems are resolved / those tasks have been done; this is also possible with additional columns in existing databases already containing data.
And first of all, it's, as said in my text, intuitive, iterative construction all over the canvas, neither top-down nor bottom-down, but as flexible as it gets, which means it's by constructing in little steps here and there that you discover the best distribution of your columns over the tables, including new tables to be created for that or other tables to be stripped off of some of their columns.
It's evident that for such, very natural, work, you need a big screen and quite tiny tables (as said, those in Navicat are too big even on traditional screens, let alone high-dpi screens), so that you can display many tables on the screen concurrently, and it's also evident that such "chaotic", iterative work will need comments and visual comments indicators, and that the comments should be visible by simple mouse-over, not asking for an unnecessary intermediate step of "really activating" the table in question.
It also becomes evident why layers would be very helpful (what "Navicat Modeler" has got instead of layers is almost unusable and very badly executed, it's background graphics with some "glue" which doesn't function properly: it's a lot of fuss for no real outcome), and with one table being able to belong to more than one layer only: In big databases, there are obviously table groups, but those groups are not, for every one table belonging to them, clearly defined, so it often makes sense, I think, that just 1 or 2 tables from one group also are displayed together with another table group to which their columns "belong" in a way, without being incorporated into those tables, since they are either more generic, more special or belong even more strongly to some other data.
Btw, you can colorize the table captions, which is not bad at all, but then, you cannot filter by these colors - which would have been an almost working alternative to layers; anyway, you can only assign one color to these table captions, not two (which technically would be possible, you often see two-colored tabs and such, one color a triangle in the left "half" and the other color a triangle in the other), let alone three, but for tables belonging to more than one group, you could then have assigned additional colors, for example brown belonging to yellow AND red, and then, if the filter was "brown PLUS yellow", "brown PLUS red", that would have been perfectly working instead.
What I also had tried to tell them in my first try: When you select a field/column, an info-box to the right of the canvas will display some data for the table; this is devoid of any sense, but of course I worded that differently. In fact, I suggested that when you select the caption of the table, you get that table info in the info box, and when you select a field/column, you get extended info for that field/column.
As it is, there is some very basic field info within the "field" field itself, but for all the other, often very important, info, you have to double click, and then you get an "Design Table" window, for the whole table, not for the field in question only (which for both looking up data and for changing data is too much), and a window which then you will have to close by alt-f4, so for just looking up relevant field attributes, this is not intuitive at all and takes a lot of time and effort, while all the time, the info window to the right of the canvas shows irrelevant table data.
It's evident that selecting the table's caption should display table info, selecting a field should display all field attributes, and that a double click into the caption should display the "Design Table" window, for some bulk edits, while double clicking a field should not even display some "Design Field" window, since it would be all there in the info field anyway, where of course there should be allowed inline editing - this is all so simple I am unable to understand why anybody would do this in any other way, considering the info pane is there anyway.
Of course, if you don't display such a permanent info pane, then you must do it otherwise, for example all the field info (and not only the comment) by mouse over, and a "Design Field" window by double-clicking the field. That would be a very viable alternative for not sacrifying the screen estate for the current info pane, but I think a brilliant developer should offer both alternatives: The inline-editable info-field for the first period of work, when the user will enter enormous amounts of data (and the mouse-over-info anyway with all data, by option), and the mouse-over-display of all data, with a clickable "Design Field" (which in fact would be the inline-editable info pane from the previous alternative, but not besides the canvas, but over the canvas, hiding any table there as long as the user enters data; upon "enter" the editable info pane would disappear again - this alternative for the later stages of work when there is much less data entering (by data I mean fields and their attributes, not contents), and much more fine-tuning. (Call this info pane "Properties pane", as Navicat does, or "Inspector", or as you like. Btw, you can hide it in "Modeler", and since currently it doesn't contain any real information, that's what you should do in order to get a larger canvas.)
From the above, it becomes very evident that graphic construction of a complicated database on a big, high-resolution screen and with the right tool (the fact that I don't possess either does not invalidate this), which has got the most important ones of the functionalities described above, is much more straightforward than by mechanically filling up tables one by one with columns, each table separately in its own window hiding the other tables.
P.S. I have left out query building. It's evident that "Navicat Premium" and "Navicat for ..." come with these, as do any other frontend; I didn't look for it in "Modeler" but probably it has got it, too. Also, you need named, stored queries, which are available in Navicat, but not in every other frontend, or then, in some not very practical way. In "AnySQL Maestro/... Maestro" for example, you store these, but clicking on them then doesn't run the query but just opens another pane in which you must click on a "run" button or something.
"Navicat" should do three things:
- implement better organization (see above)
- show real interest in the specifics of the database languages it covers
- introduce into "Modeler" the most important ones of my suggestions above (functional layers or functional color sorting; making comments available without "real selection" needed, with visual indicators; making all field attributes available by mouse over or at the very least by simple click, either in the Properties pane or in a floating, mouse-over pane (not only in the extra, cumbersome "Table Design" window as currently done); then, in a second step, the position of the link lines.
And don't call a demo "Essentials".
