Navicat Review

[ital2]

In my tries with SQLite, I played around a little bit with the "Navicat Data Modeler" which is not cheap; in fact I played around with the free "Essentials" version which is not a lite version but a demo one, in fact, you don't get any data in nor any data out, or perhaps then with the 14-day trial.

Playing around with it was lots of fun, but some points I didn't like at all, so I tried to have their point of view about them on their forum. The sign-up for their forum does not take several minutes, but several days (!), and then I wrote:


Navicat Data Modeler is graphically very pleasing and functional, but I miss some functionality which would greatly enhance my productivity with it:

There are no visual comments indicators for fields (see Microsoft Excel such for indicators). This makes a lot of unnecessary clicking (see next point) and mouse-overs, in order to detect possible comments.

Reading comments by mouse-over needs the respective table to be really selected, just the pre-selection does not display anything. Or you call it pre-activation and activation, respectively, or something else, anyway: the "pre" thing will color a frame around the table by mouse-over, but will NOT display any comments; for that you must really activate the table by clicking. This is counter-intuitive since you cannot freely move the mouse over the whole canvas, in order to read a comment here, then another there, in another table, and again in another one. It's all a lot of unnecessary clicking, and then even searching for possible comments (see previous point).

Link-lines (foreign keys) are not field-to-field (column-to-column), but just table-to-table.

The field (column) fields are too big, so the tables become too big, too, and take too much room (screen real estate). I've seen flowcharts where these symbols were less big, so you get many more table symbols on the screen of a given size.

The grouping of tables does not work correctly in all instances; more often than not some tables will not follow when moving around. Also, I would prefer named layers for table groups, with one table being able to belong to several named layers (!), and with a multi-selection layers list, i.e. the user could display just one layer, two or several of them concurrently. Ideally, outgoing or incoming link-lines to/from tables not visible currently would end in sort of an end point with the name of the table which currently isn't displayed, and ideally even with the target/source field name.

Navicat Data Modeler is ideal for constructing databases with 100 tables and more, but it's precisely with such big projects the realization of the above wishes would help enormously.


Which gave:

Error
You are not authorized to create this post.

This is different from:

Error
The string you entered for the image verification did not match what was displayed.

Of course, I tried on several occasions, on several days...

For the above, it's important to know that their "Modeler" does of course not add comments to SQLite, even if that would be terrific to have (for example by an SQLite database in Navicat which would load the comments for display, and could even write them into the SQLite code, into some comment lines block for example), but I discovered the joy of having field comments by playing around, selecting "MySQL" instead of "SQLite".

That being said, I also tried their "Navicat for SQLite" and discovered BIG bugs, by trying to insert a column into an existing table, instead of inserting the column, Navicat wrote the data from another column into the rowid column and so destroyed the whole table, no "undo". Inserting columns into an existing SQLite database is not that easy, as I then learned from forums, but both SQLite Maestro (trial) and SQLite Expert "Personal" (free and highly recommended) correctly do the necessary intermediate steps (and in no time) in order to execute this task faultlessly.

If this 1000$-plus-VAT program (updates for 3 months included) "Navicat Premium" does do similar mishaps in other databases or when translating databases from one format into another, that'll be fun!

Fact is, building a database from a graphical representation is real fun, but only when you can organize that work according to what I say above.

Current "Essential Premium" is 160$ plus VAT (had been 40$ when the "Navicat for..." subsets were 10$, they are now 40$ each), but if you're willing to live with a quite ugly, old version instead:

Extensive search had me find the only (?) surviving download link for the last version of Navicat Lite 10.0.3:
http://www.chip.de/downloads/c1_downloads_hs_getfile_v1_70358375.html?t=1492872478&v=3600&s=e4dfd9f627b57e81fa40c05dc3d1cb76 (download dialog for NavicatLite-10.0.3.exe will appear in about 5 seconds)

Edit May 8, 2017: Title Change

[ital2]

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.macupdate.com/app/mac/43140/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!"

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".

[ital2]

In the last paragraph, I forgot to repeat the demand for the tables and their lettering taking less space, which is an easy and important thing at the same time. But when it returned to mind, it occurred to me that resizing would be a good start, but just that.

Today's graphics cards can serve several big screens, but not everybody wants to place them on their desk in numbers, and even if they are available, with some 200 tables, it can become difficult.

Also, yesterday, I envisioned filtering (by caption colors) only for on-off toggle, but when you have got a good screen setup, there are some alternatives to that.

Imagine the tables of the not-selected colors be greyed out on request, instead of being hidden, with all connectors being displayed all the time. Also, there should be two switches for display (or "full display"), primal color which means belonging to some functional group (as described above), and then also a secondary color (a dot, a border or such; as for Windows windows, why not do a little box in the right top corner of each table, with a default status and, by clicking/rightclicking, several possible not-default statuses, indicated by different colors?) for todo/status: for "is deemed complete/ready" vs "is incomplete", and "speed problem, must be changed", and it should be possible to combine these complementary switches.

Of course, there should be a toggle "full hiding" vs "just greying out" for hiding.

Then, even any greyed-out table would become full-shape and responsive by mouse-over (this means it would overlay neighboring tables somewhat, which then would be temporarily greyed-out, even if in the current set-up, they are not greyed-out, so visually there would be no clutter whatsoever), and would get greyed-out again when the mouse leaves it.

What about readability of the tables' lettering? The caption should always be readable, but what about field/column names and attributes when there is not enough space on the canvas, and the table is greyed-out anyway, for example because it's viewed as "complete", for the moment being at least? An automatic receding should be implemented for such field names, and the table with it.

Here again, whenever there is a mouse-over, the table would regain its original size, with all its lettering perfectly readably. And what about the important fields/columns, the ones which are key for a foreign key, or are foreign key? (Note: Above for the link-drag-and-drop, you will have probably thought that I mixed up source and target, but I consider such a link as unidirectional between key, which is source, and a foreign key, which is target, since the data flow is in that direction, not in the reverse one. But I suppose most people will not see the data flow in a link but the direction of the data-fetch-wish, so for them, source and target are the other way round.) Even when the currently-not-important field names are just a point high, so as to indicate there is some field indeed, it's perfectly possible to leave the link sources/targets in their original, readable size.

As you can see from the intent of the visuals above, it would also be very helpful if you could distinguish field names of fields which have to be worked upon, by some bolding or such (toggle or even several colors, as for the tables/table captions, in case by context menu), so as they are distinct from other fields which do not need any more attention for the time being.

In later stages of development where speed considerations become primordial, why not move fields from one table onto another by drag-and-drop, too, the tool doing the necessary sql commands behind the scenes? (This implies that such a tool should fully work on production databases with real data in them, too.)

It should be noted that such plastic visuals where currently-active elements are enlarged and in lucid colors while adjacent elements are greyed-out can be applied to many use cases, way beyond database design, and they ensure that even on quite regular (large but not monstrous) screens efficient management of a high number of distinct elements and their interaction becomes possible and perfectly feasible.


NO EDIT, had just added some edit which I now put into the next post.

[mouser]

Just wanted to say thank you for taking the time to post your review 

[ital2]

Thank you so much again, mouser, hadn't discovered your message in time, just your post.


Originally an EDIT above:

Thank you, mouser!

And:

What I meant above but had not expressed is that of course, bolded or otherwise "important/todo/must-be-taken-care-of"-formatted field names/entries in the greyed-out tables (I mean greyed-out on purpose of course, not the temporarily greyed-out vicinity when some table is enlarged and made prominent for temporary "activation" (reading or reading/writing) purposes by mouse-over) should be readable, just like link sources/target, not be minimized as the rest of them, so that with progressing work on the database, first these table representations will grow, then will recede again, up to a point where only link sources/targets will be left, beneath the table captions, so you see some bulge of problems which have to be addressed, then, by disappearence of this bulge, the progress and (provisional) finish of your work.

Also, there could be a toggle for "show all tables in full" vs "only show distinguished field entries" (distinguished in the sense described above: link sources/targets, and manually for "has to be taken care of" and such, or even core columns overall); remember, a "take care of the table" in general (adding further columns and such) would be indicated by a box in the caption; it would even be possible to grey out the captions for "done" tables, while tables which must be worked upon (by additions of problem solving) could be in color - when "greyed-out", in faint/washed-out coloring.

This way, FOCUS, even on groups of tables, is always ensured, without hiding the tasks which have to be accomplished yet, which is all the more important considering the fact that in many cases, those tasks will have some interaction with other things already completed and should thus be borne in mind for that reason already.

Here again, it's evident that such an integrated visual representation can be helpful for lots of other things blatantly organizational or not that much at first sight (problem solving) beyond database design, see flowcharting software (for example Microsoft Visio) or socalled Concept/Topic Maps: It's certainly a worthwile paradigm to see the graphical representation of problems grow, taking all possible consequences/emanations and (external as internal) leverages into consideration (this would imply sub-elements, with extension lines to them, and which would then disappear when resolved (which is not or only rarely the case with database tables), meaning the respective parenting element only would stay visible by default, bearing the short description of the problem and how it was/will be taken care of); and then that graphic bulge see recede again when more and more sub-problems or internal as external interactions have been taken care of, and by thus the overall workouts/solution(s) come nearer.

In other words, a graphical representation that is able to de-blur the intermittent clutter as far as technically possible not only helps enormously in speeding up the outcome, but very probably also in finding the best possible outcome there is, since when you clearly, distinguishly see sub-elements (which implies there should be technical means, as described above, to visually distinguish them to begin with), there are much better chances you'll keep those elements and their importance for other elements in mind when taking other decisions within that framework but which happen to be interconnected in some way. In the use case discussed here, it's certain that with a software like the one described above, and in varying parts realized by available software, database design will not only be easier, but show better results than if you build tables and their interconnections, just alternating between flat views of the tables in question, one by one, and the same will be certainly true for any not-too-basic problem solving.


And I'd like to add:

As said above, all the relevant database languages put comments into their code, while SQLite does not. So for databases other than SQLite the comment is available for encoding individual field/column formatting in the graphic representation like the one I describe here, the developer of such software could put a leading dot in the comment attribute of the field for just a formatting toggle (regular/bold, then bold would be displayed even when other fields are not), or for a leading dot plus some code character for more choices in formatting: regular, bold, bold-blue, bold-red...).

This way, these individual formats would persist between programming sessions, without even introducing a tool-specific database, ini-file or other. Here again, this is not possible for SQLite but then, comments are that much useful that some instrument to preserve comments between sessions should be made available by a good SQLite frontend, even if extensive databases typically aren't developed in and for SQLite.

In any case, the user would not to have fiddle around with the field comment for the formatting but would just click, the tool behind the scenes then switching the code in the comment accordingly, as well as fetching the code from there in order to display the right formatting on load.


EDIT May 8, 2017: More info on software pricing/design here: http://www.donationcoder.com/forum/index.php?topic=43805.new#new (On Software Pricing) and (EDIT May 13, 2017) here: http://www.donationcoder.com/forum/index.php?topic=43835.0 (How NOT to conceive trials (and some new ideas about them))


EDIT May 25, 2017: In the "Trials" thread, you will now also find some info about Navicat's trial policy and why that one is really dumb for software like Navicat.


EDIT June1, 2017: Today, very substantial price rise for almost all Navicat products, between 20 and 30 p.c., which makes their products even less appealing. There should always be much better products, it has very simply been for the "XP" availability reason that I had been interested in their products. For example, the very best MySQL frontend seems to be Devart Studio for MySQ, which also includes a graphical "design" component, and there are several of these available from other makers, it's just that with XP, I cannot trial them for the moment being.

The same is true for database transposition tools where it's not necessary for most users that they "do it all", as Navicat Premium (now 1,300$) pretends to do, but they do it, for those languages you need it for, without fault, which, it seems, is not always the case with Navicat translations. Btw, "Languages: English - more to come" - I'd be highly interested in knowing which developers do not read at least some very basic English; this reminds me of the absolutely crazy Microsoft move to localising their VBA, so that their macros don't travel from one country to the next. Whatever, Navicat better exterminated their bugs and amended their functionality; for 1,300$, you'll get a lot of fine, language-specific database tools, especially if on top of the 1,300, from Navicat, you then have to buy those additional, dedicated tools anyway, in case Navicat's do-it-all doesn't live up to its promises; you know, some people called that the Trump mode, ha ha ha.