In the light of GDPR and similar data protection laws this could lead to significant compliance issues. Users can be given Creator, Editor, Commenter or Read only access but once they have access to a ‘base’ then they can see ANY of the data within it. Tabular, Grid, Kanban, Chart, Form and Gantt views can be created. For the end user, the result is a very pleasing interface to use with apps mainly working with panels which slide in and out. The difference is that you need to be an Admin user to access any design tools. Ninox takes a different approach in that the design view and live view cohabit (like Airtable). My only issue is the cumbersome way Sub-forms are handled. Like Knack, the developer can build rich UIs including the ability to trigger emails and other events and workflows. Like Knack, the UI is separate for developers and users with the paradigm based around Forms (creating a form also creates the Table behind). Particular strengths are the ability to produce pages with multiple tables and other ‘views’ which enable a rich user experience. Recent additions of Personal and Locked views help a little here.īuilder: The Builder is where you create your Objects (tables) and then the pages, reports (cross tabs, charts, maps etc) which the user sees.Įnd User: The end user gets a relatively modern, responsive UI which is well ‘locked down’. In my experience, the Spreadsheet UI design leads inexperienced users to approach their databases like they would a spreadsheet and this can lead to some poor database designs. This means that there is risk of users changing things they shouldn’t. I have been using these four database/app building platforms for some time now and thought it would be useful to do a comparison of their features, strengths and weaknesses…īeautiful – BUT you are working in a Spreadsheet like UI which is both the design and end user environment. It would seem that there is, in fact, a slight performance hit in the simple case, but I don't have any insight into any possible memory management hits.In this revised article (now including Ninox), I am going to compare the features of Airtable, Knack, Zoho Creator and Ninox – three of these are platforms I’ve chosen to work with for clients following an extensive evaluation of the no/low code database market (I no longer provide Zoho Creator services). I ran a test with very simple criteria on a very simple table with 25,000 records, only 50 of which meet the criteria, and it appears the brackets are a little slower than the where clause: Would not only use less memory, since the entire table is never stored into an array, and might also be faster. For a large table with only a few records meeting the criteria, this seems at best a waste of memory management, however temporary it might be, and possibly also an unnecessary performance hit to generate the entire records array only to then reduce it by criteria. It seems like the select would return the entire table in an array, and then the criteria would be applied. " criteria would get applied while the select is doing its query, but the criteria would get applied only after the select is completed? Obviously, both of these produce identical results, but I wondered if there are any performance or memory management implications. I only recently saw in the forum the use of a square bracket criteria expression on a select statment instead of a where clause, which I had never thought of doing before. Proposition: It is preferred to use "select mytable where criteria" over "select mytable".
0 Comments
Leave a Reply. |