Comparison with a Conventional Database

To cut a long story short it is much easier to develop and maintain a solution in Datawasp than it is in any other database manager.  So much easier in fact that the development process in Datawasp bares little relationship to that in a conventional database.

Conventional databases are 'relational' this means they are created using a language called SQL.  Relational SQL databases are very powerful.  If you want a database for a thousand or more people then that is the way to go   The downside, however, is that SQL is very complicated.  It takes a trained and experienced Data Base Administrator  (DBA) to create a database using SQL.  If you want any changes you will need to get the DBA back and sometimes a DBA will be needed simply to keep the thing running at all.

This is why databases are only used for large scale applications and often then are clunky and do not keep up with the changing needs of their users.

Datawasp is not 'relational' and does not use SQL.  Instead you create the data structure visually on the screen like a spreadsheet and you use spreadsheet style calculations.  It requires no more training than a spreadsheet to do this.

Unlike a database it is designed to encourage gradual improvement of your solution over time.  For sure, complicated things can be developed  but there is no advantage to creating a complicated structure up front.  You might as well start with something simple that you know you need then add to it as you find more things you want to do and get a feel for how the solution is actually used.
The development of a conventional database is very separate from its use.  In the simplest case a special design mode must be invoked to develop a database solution , more often a dedicated application has to be used.  Additionally, the data structure is designed separately from the interface using separate tools.  Creation of the interface involves either programming or learning a bespoke visual editor, often both are required. The interface and data structure have to be 'bound' to each other using more SQL statements. 

Datawasp has none of this.  There is no distinction between data structure and interface, to add a column to a table you click 'Add Column' enter the column details and click OK. The column appears in the table and you can start entering data. If you change your mind about the column you edit its properties or delete it altogether.  Sub tables and calculations are just column types and are created in the same way.

Keys, joins, triggers and virtual tables

For those who understand relational tables and SQL I will explain how these relational features are catered for in Datawasp.

Datawasp is a hierarchical object store.  Much of what is achieved in relational databases using keys and triggers is known in object oriented terminology as 'Composition' and 'Aggregation' and comes for free in Datawasp without any action from the designer.

'Composition' means simply that any object can have children which can have their own children etc.. When a parent is moved around it takes its children with it. When the parent is deleted it takes its children with it etc...

'Aggregation' is where one object is 'referred' to by another. This differs from Composition in that when the referrer is moved or deleted the referee is unaffected.

Both composition and aggregation are hard wired into the Datawasp data types so the user does not need keys or triggers to implement them.

Another feature of relational tables are joins, for example, an SQL query which returns a pseudo table.  In general the need for joins is reduced in Datawasp because data tables do not have to be normalized so human readable tables to not have to be synthesized from scattered components.

However it is often useful to create a pseudo table when the composite structure does not suit a particular need.  In Datawasp tables can be synthesized using standard algebraic syntax instead of SQL.  Existing object lists of the same type can be combined and filtered to produce new lists which can be displayed in the interface and columns can be added to bring in other data.

A purist might point out that this does not cover everything that can be achieved using keys, triggers and joins but in reality this covers 98% of what is implemented in practice and in return the whole process of database design and maintenance is dramatically simplified to the point where a non specialist can easily do it for themselves.